AXI各通道握手依赖

在AXI协议中,为了防止死锁,对每个通道的握手信号(VALID, READY)做了以下规定:

  • AXI通道的发送端的VALID信号不能依赖于接收端的READY信号;
  • AXI通道的接收端可以等到VALID信号拉起来后,再拉起VALID信号;

此外,不同通道上的握手信号之间也存在依赖关系。下面三个图为读写传输依赖,单箭头指向的信号可以在箭头起始的信号之前或之后拉起。双箭头指向的信号必须在箭头起始的信号拉起之后才能拉起。

读传输依赖如下图1所示。

  • ARREADY可以在ARVALID之前或之后拉高,但是ARVALID不能等ARREADY拉高才拉高。
  • RREADY可以在RVALID之后或之后拉高,但是RVALID不能等RREADY拉高才拉高。
  • RVALID 必须在ARVALID 和ARREADY 都拉高之后才能拉高

图1 读传输握手依赖

AXI3写传输依赖如下图2所示。

  • AWREADY可以在AWVALID之前或之后拉高,但是AWVALID不能等AWREADY拉高才拉高;
  • AWREADY可以在WVALID之前或之后拉高,但是WVALID不能等AWREADY拉高才拉高;
  • WREADY可以在WVALID之前或之后拉高,但是WVALID不能等WREADY拉高才拉高;
  • WREADY可以在AWVALID之前或之后拉高,但是AWVALID不能等WREADY拉高才拉高;
  • BREADY可以在BVALID之前或之后拉高,但是BVALID不能等BREADY拉高才拉高;
  • BVALID 必须在WVALID 和WREADY 都拉高之后才能拉高

图2 AXI3写传输握手依赖

图3的AXI4和AXI5是在图2 AXI3基础上,多增加了一个约束,也就是:BVALID 必须在AWVALID 和AWREADY 都拉高之后才能拉高。之前AXI3,BVALID只需要等到WVALID和WREADY收集好就可以拉高了,不需要看AWREADY和AWVALID。

图3 AXI4和AXI5 写传输握手依赖

那么为了验证这些AXI通道握手之间的依赖,防止设计中出现不应该存在的依赖而导致死锁,合格的AXI VIP要注意必须支持READY模式:

  • ARREADY一直不拉高,直到AXI VIP收到ARVALID拉高才拉高;
  • AWREADY一直不拉高,直到AXI VIP收到AWVALID拉高才拉高;
  • AWREADY一直不拉高,直到AXI VIP收到AWVALID和WVALID都拉高才拉高;
  • WREADY一直不拉高,直到AXI VIP收到WVALID拉高才拉高;
  • WREADY一直不拉高,直到AXI VIP收到AWVALID和WVALID都拉高才拉高;
  • BREADY一直不拉高,直到AXI VIP收到BVALID拉高才拉高;

说白了其实就是为了防止设计人员在写代码时,错误地依赖收到READY信号后才会发出VALID信号。而也只有VIP支持以上的READY模式才能检查出这个bug,如果VIP的READY只是无规律的toggle,那么这种bug就几乎不可能找出来。

相关推荐
谷公子的藏经阁4 天前
讲个AXI死锁场景
cpu·axi·死锁·deadlock·axi2ahb
ん贤5 天前
一次批量删除引发的死锁,最终我选择不加锁
数据库·安全·go·死锁
egoist202317 天前
[linux仓库]线程池(单例模式)、线程安全与重入、死锁[线程·拾]
linux·单例模式·饿汉模式·懒汉模式·线程安全·死锁·重入问题
橘颂TA1 个月前
【Linux】死锁四条件的底层逻辑:从锁冲突到 STL 组件的线程安全实践(Ⅵ)
linux·运维·服务器·c++·死锁
栗子叶1 个月前
JVM 内存溢出和死锁检测
jvm·调优·死锁
武藤一雄1 个月前
C# 关于多线程如何实现需要注意的问题(持续更新)
windows·后端·microsoft·c#·.net·.netcore·死锁
橘色的喵1 个月前
全局锁策略:通过有序获取与超时保护构建无死锁系统
linux·死锁
Chen不旧1 个月前
Java模拟死锁
java·开发语言·synchronized·reentrantlock·死锁
快乐的学习2 个月前
Synopsys AXI DMAC模块协议总结及实例操作
dma·axi