AHB 局限性

AHB's problem

SoC bus 架构

AXI is used more and more

• 频率200M使用AHB,频率再升高就使用AXI

AHB的问题

• AHB协议本身限制要求较高，比如command和data必须是1Cycle的延迟，error response，HREADYOUT和HREADYIN等机制都很容易导致设计出错，这是从设计层面去考虑AHB存在的问题。
• 我们分析一下AHB的带宽，在理想情况下，AHB的最大带宽为BW=Freq*DW。虽然AHB存在WDATA和RDATA，但是它的控制信号只有一路，并且COMMAND和DATA必须满足1T的延迟，所以WDATA和RDATA是无法同时工作的。等于数据信号的利用率最多只有50%。可以认为它近似于一个半双工的BUS。
• 上述还不是最坏的情况，因为我们考虑数据是一拍回复，那当数据不是一拍回复，并且当我们需要改变传输方向的时候呢？比如我们先读后写。在读数据回来之前我们是不准写的，这个前面讲AHB协议的时候有说到，因为HREADY会反压，一直到读数据回来的时候才准写。因此当回数据需要很多拍的时候，并且频繁地发生读写转换的时候，AHB的效率是非常低的！
  
  

AXI的提升

• AXI有五条独立的channel,AXI相比AHB最重要的改变就是读写通道分离，相当于我们有两路可以传输了（全双工），此外AXI还支持Outstanding（现在简单理解为在路上即可）。同样考虑开始开车的例子，同样是读写频繁转换，传输延迟很大为100s，在理想的情况下可以是2car/1s！。因为AXI不需要等读回数据响应再发送下一次传输，它支持“在路上”。