扫码关注
AXI面试并不是让你背五个通道名字。READY/VALID握手看似简单，但如果组合依赖写错、VALID提前撤销或跨通道关系处理不当，就会出现偶发丢数、吞吐下降甚至系统死锁。
面试先抓这几个点：
一次传输在VALID和READY同时为1的时钟沿才真正完成。
发送方一旦拉高VALID并给出有效payload，在握手完成前通常要保持稳定，不能因为READY为0就随意撤销。
READY可以用来施加backpressure，但不能形成违反协议的组合依赖环。
AXI读写有多个独立通道，地址、数据、响应之间要按协议关系管理，不能凭直觉捆死。
面试官真正想听什么
这类题不适合只背一句结论。更稳妥的回答方式是先说明判断条件，再讲工程动作，最后补上验证手段和常见风险。这样更容易让面试官判断你是否真正做过相关工作。
回答时可以按这几个方面组织
VALID
谁产生发送方
核心要求有数据可发时置1，未握手前保持数据稳定
READY
谁产生接收方
核心要求能接收时置1，用于产生背压
握手完成
条件VALID && READY
结果当前beat在该时钟沿完成传输
常见死锁
原因一端等待对方先拉高，另一端也反向等待
整改遵守通道独立性和协议推荐时序
一个更像工程师的参考回答
我理解AXI握手的核心是：发送方负责VALID，接收方负责READY，只有同一时钟沿两者同时为1时当前传输才完成。发送方不能因为看到READY没起来就不拉VALID，否则如果接收方也设计成看到VALID后才拉READY，就可能互相等待。VALID拉高后，payload在握手前也应该保持稳定。做RTL时我会特别检查组合路径和背压传播，验证连续READY=0、随机READY抖动以及VALID连续拉高的场景，并用assertion或仿真确保没有丢beat和重复传输。
面试官可能继续追问
VALID能不能依赖READY？
READY一定要常高吗？
AXI Stream连续传输怎样做到一拍一个数据？
为什么寄存READY经常能改善时序但可能增加一级延迟？
容易失分的回答
只会说“READY和VALID同时为1就传输”，讲不出死锁来源。
VALID只打一拍，READY没来就把数据撤掉。
仿真只跑READY常高的理想场景。
面试前可以这样准备
自己画三种波形：VALID先到、READY先到、两者同时到。
用一句话解释backpressure。
准备一个skid buffer或寄存切片为什么存在的说明。
核心关键词：AXI、READY VALID、握手协议、背压、FPGA面试
