在SoC设计里摸爬滚打这几年AXI协议几乎是每天都要打交道的。之前带一个实习生调DMA搬运图像数据的用例他对着波形图问我“这明明是连续的几笔传输为什么日志里写的是1个Burst但波形上却有4个Beat这两个到底啥关系”这个问题看似基础但确实把很多刚接触AXI的工程师绕晕了。Burst和Beat这两个词在协议文档里反复出现但如果你没在真实的总线波形里盯过它们光看手册很容易把它们混为一谈。这篇就好好拆一拆这两个概念的区别顺带把地址计算、边界判断、窄传输这些容易踩坑的细节一并捋清楚。1. 先搞清楚两者的原始定义1.1 从协议文档的字面意思看差距AXI协议把一次完整的数据交换过程定义为一个交易Transaction而Burst就是构成这个交易的核心机制——它表示一次事务中主设备连续发起的一组数据传输。Beat则更底层它指的是一次单独的数据传输节拍也就是在总线上完成一次握手VALID和READY同时拉高的那一拍。换句话说Burst描述的是“一组连续传输”的组织形式Beat描述的是“一次实际数据搬移”的发生动作。一个Burst里可以有很多个Beat比如AxLEN3意味着这个Burst里有4个Beat。可以这么想Burst像一列火车的整个班次Beat就是这列火车里的一节车厢。火车班次决定起点站、终点站和有几个停靠点而每一节车厢才是真正拉货的单元。我见过有人把这两个词完全混着用在代码注释里写“这个burst包含8个burst”这种注释自己看着都别扭。协议文档明确区分了这三个层次Transaction事务 Burst突发传输 Beat节拍传输。弄清这层包含关系后面读任何AXI相关的IP文档、看总线波形、调性能计数器都会顺畅很多。1.2 为什么协议要区分这两个概念如果你只看功能好像Beat才真正承载数据Burst只是个“包装”。那协议为什么要单独定义Burst呢因为总线不仅要传数据还要传“关于数据的元信息”。Burst这个层级携带了三个关键参数长度AxLEN决定有几个Beat、大小AxSIZE决定每个Beat传多少字节、类型AxBURST决定地址怎么变化。这三个参数组合起来才能让从设备知道如何准备自己的存储空间如何计算地址如何校验接收完整性。Beat这个层级则携带了实际的写数据信号WDATA、写数据有效信号WSTRB、读数据信号RDATA、还有最后的响应信号RESP。可以说Burst是“计划”Beat是“执行”。没有计划执行就是乱的没有执行计划就是空的。SoC设计里你写总线主设备逻辑时本质上是在规划Burst写从设备接收逻辑时本质上是处理一个个Beat。这两个视角必须同时把握才不会出结构性bug。2. Beat的细节一次握手一次搬运2.1 Beat里那些容易忽略的字段一个Beat的读传输由AR握手和R握手共同定义。主设备发起AR通道的请求后从设备在R通道上送回应数据每个R通道的有效传输都算一个Beat。写传输则更复杂一些分为写地址通道AW上的一个Burst请求和写数据通道W上的多个数据节拍。关键点在于一个Burst只在AW通道上出现一次地址请求但在W通道上会出现AxLEN1个数据节拍。这里有一个特别容易误解的地方。很多人以为一个Burst里的多个Beat每一拍都必须紧挨着中间不能停。其实不是这样的。AXI协议允许每一拍之间有气泡gap只要VALID和READY没有同时拉高总线就处于等待状态不算完成一个Beat。所以从波形上看一个Burst里的多个Beat不一定在时间上连续。但它要求地址变化逻辑上连续固定、递增或回卷方式数据通道的逻辑关系是连续的。我在实际调试中见过一种情况写通道的WVALID拉高后从设备因为内部FIFO满了把WREADY拉低导致这一拍WVALID一直保持为高直到WREADY重新拉高握手成功才算这一Beat完成。这种情况下这一个Beat可能被拉伸成很多个时钟周期。从功能仿真上看数据没错但如果你用这个信号去做延迟估算会得出完全错误的结论。2.2 窄传输Beat与Strobe的对应关系再举一个Beat层面的经典细节——窄传输。假设数据总线是64位8字节但一个Beat只需要传输3个字节的有效数据。这时候数据总线并没有被全部占用AXI通过WSTRB信号来表明哪几个字节通道是有效的。WSTRB是8 bit每一位对应总线上一个字节置1表示这一字节有效。我调试过的一个图像缩放IP输入像素格式是RGB888一个像素3字节但总线是128位。当时主设备发出的写请求每个Beat的WSTRB都在不断跳变有时候只写4个字节有时候写8个字节。从设备的写FIFO必须严格按照WSTRB来拼接数据一旦拼接逻辑没考虑strobe的边界图像就会花屏。这个问题排查起来很折磨人因为读回地址上的数据和写进去的期望数据对不上但又不是每次都不对——只有行尾像素处理时才会错。Beat层面的处理逻辑写起来琐碎但恰恰是这些琐碎决定了一个总线IP能不能在真实场景里稳定运行。以后写RTL时凡是处理写数据的模块都要把WSTRB当成一等公民看待不要只在地址对齐时才处理它。3. Burst的核心机制三个参数定乾坤3.1 AxLEN、AxSIZE、AxBURST怎么配合Burst这个层级最核心的就是三个信号AxLEN长度、AxSIZE大小、AxBURST类型。AxLEN是8位表示突发长度减1。AxSIZE是3位表示每个Beat传输的字节数以2的指数形式表达000表示1字节001表示2字节010表示4字节011表示8字节以此类推。AxBURST是2位决定地址如何变化一共有三种类型FIXED固定地址、INCR递增地址、WRAP回卷地址。这三个参数之间的计算关系非常明确一次Burst传输的总字节数 (AxLEN 1) × 2^AxSIZEINCR类型的地址递增量 2^AxSIZEFIXED类型的地址始终不变WRAP类型有一个回卷上界一旦地址到达上界就回卷到起始地址对应的“基础地址”继续递增举个实际例子你要从某外设寄存器里连续读128字节数据数据总线宽度设成64位那么AxSIZE可以设成3表示8字节AxLEN设成15表示16个Beat这样总字节数 16 × 8 128字节。这个Burst走INCR类型地址从起始位置开始每个Beat增加8连续增加16次。这个组合非常常见几乎所有DMA搬数都是这类模式。3.2 Burst边界与4KB保护关于Burst边界有一个资深工程师必须刻在脑子里的规则任何Burst都不能跨越4KB地址边界。这是AXI协议的铁律因为4KB正好是一个典型的内存页大小也对应着大多数从设备比如某些片上存储、外设寄存器区域的地址窗口。如果让总线事务跨越4KB边界就可能访问到完全不同的从设备区域导致互联逻辑出大问题。实操中这意味着当你写DMA描述符或总线主设备逻辑时必须做4KB边界检查。如果你的传输起始地址是0x1FF0要给一个长度为128字节的Burst那么0x1FF0到0x207F跨越了0x2000边界这个Burst必须拆成两个一个先从0x1FF0传到0x1FFF16字节另一个从0x2000传到0x207F112字节。不拆的话很可能触发从设备报错或者数据错乱。我记得有一次排查一个PCIe控制器下的DMA偶发卡死问题最后定位到就是某个驱动配置的传输长度恰好让一次DMA跨过了4KB边界从设备那边把这次访问当成了非法访问直接不回应答导致总线挂着。从那以后我在所有DMA引擎的RTL前端都加了一个地址边界检测模块逻辑不复杂但能避免极难排查的死锁问题。3.3 WRAP边界为什么让人犯晕WRAP类型的Burst最容易被忽略也最容易写错。它在图像处理领域很常用典型场景就是cache line的填充或逐行处理。WRAP突发的特点是地址曲线上有一个上界和一个下界所有Beat的地址都约束在这个范围内越界就回卷。规定是这样WRAP突发只能用在AxLEN为2、4、8、16等2的幂次的情况下且突发的传输字节数不能超过这个“基础地址”的窗口大小。比如你设置AxSIZE24字节AxLEN34个BeatAxBURSTWRAP那么这个Burst的总字节数是16字节这16字节必须发生在16字节地址对齐边界内。起始地址可以是窗口内的任意4字节对齐位置但如果地址算到窗口上界下一个Beat就从窗口下界继续。我踩过的一个坑是在做图像行缓存操作时给AXI从设备配置了WRAP突发但起始地址设在了窗口的中间偏上位置导致前面两个Beat正常第三个Beat地址回卷后出现了一个很诡异的高位地址翻转。后来仔细看协议才知道地址回卷不是简单的“回卷到窗口起点”而是要在地址位宽内实现一种特定规则如果窗口大小是16字节地址的低4位到达0xF后再递增就变成0x0而高位的地址保持不变。本质上这是低比特位的回卷不是完整的地址回卷。搞清楚这个规则后我又去检查了好几个WRAP相关的从设备实现发现不少人在回卷逻辑上都有些小毛病。4. 区别在哪里Burst vs Beat的完整对照4.1 一张表看清核心差异为了让大家一目了然我把这两个概念的核心差异整理成一张对照表对比维度Burst突发传输Beat节拍传输层级事务层面的组织形式传输层面的单次动作携带的核心信息传输长度、数据大小、地址增长方式实际数据、字节使能、握手信号出现通道AW/AR通道一个事务一次W/R通道一个事务多次地址变化决定整体增长策略每个Beat执行具体地址递进波形特征对应一次完整的通道请求窗口对应一次VALIDREADY同时拉高的时刻寄存器状态通常由主设备状态机管理通常由从设备状态机逐拍处理边界约束不得跨越4KB地址必须保持在Burst定义范围内常见混淆点误以为一个Burst等于一拍误以为Beat之间必须无气泡这张表我建议新手直接存下来做总线级调试遇到概念混乱时翻一翻就能快速定位自己到底是在说哪个层面的事情。比如你是看性能计数器的那关注的永远是Burst的个数和Beat的总数如果你是在看数据完整性那就要逐Beat检查WSTRB和WDATA的匹配关系。4.2 物理层、协议层、仿真层的三重理解除了这张表我更想强调的是三个不同视角下的理解。在物理层的视角下Burst并不真实存在于时序中真实存在于时序里的只有一个个握手后的Beat。你拿逻辑分析仪抓总线波形时看到的其实是一连串的VALID/READY握手Burst只是你在事后通过地址变化规律反推出来的一个逻辑单位。用调试工具看波形时那些标注为“Burst”的框本质上是工具根据地址是否连续、通道请求是否相邻把多个Beat聚合成了一个显示单位。在协议层的视角下Burst却是实实在在存在的事务单位。从设备处理完最后一个Beat之后要么产生写响应B通道要么通过RLAST向主设备标出最后一个读Beat。RLAST这个信号值得注意它在读数据通道上标志着一个Burst的最后一个读Beat。也就是说从设备需要知道自己当前处理的Beat是不是这个突发请求中的最后一拍这直接影响它是否需要在B通道上给出响应或者在R通道上完成最后一次数据返回。你处理一个锁页lock防护逻辑也需要知道当前事务什么时候结束。这就是Burst在协议层发挥的作用。在仿真层的视角下两者的意义又不同。写testbench时我们通常按照Burst来生成激励比如用UVM的sequence发起一个“ INCR 长度16 ”的burst请求但在scoreboard检查数据时必须按照Beat来逐拍比对特别是要处理乱序返回out-of-order的情况。如果不搞清楚这两个层级连testbench里的回调函数都写不对——你会不知道该在哪个回调里比对地址、在哪个回调里比对数据。5. 实战中的经验与踩坑记录5.1 地址计算的经验法则与4KB拆分技巧先分享一个我在项目中反复使用的地址计算流程。当你要发起一次性搬运N字节的DMA请求时不要直接设一个大Burst完事而是要分三步走第一步对齐检查。计算起始地址和传输长度的边界对齐情况。如果起始地址不是AxSIZE所代表字节数的整倍数就得拆分。比如AxSIZE3表示每个Beat 8字节起始地址必须是8字节对齐。不对齐就会出问题没有例外。第二步4KB检查。估算总传输字节数看从起始地址开始是否会跨4KB边界。如果跨了按4KB边界拆成两个Burst并重新计算第二个Burst的AxLEN。第三步算AxLEN。每个Burst的剩余字节数除以每个Beat的字节数再减1得到AxLEN。举个例子假设64位总线起始地址0x2018搬运128字节AxSIZE3。检查发现第一个Burst从0x2018到0x2FFF跨了4KB边界所以第一个Burst只能传0x2018到0x2FFF这刚好是8字节对齐的0x2018到0x2FFF是0xFE8字节不对齐其实0x2018的8字节对齐点就是0x2018本身后面每步8字节到0x2FF070x2FF7之间下一个8字节就跨边界了所以传多少个Beat取决于从0x2018开始到0x2FF7有多少个8字节窗口——精确说是从0x2018递增8直到不超过0x2FFF。也就是 (0x2FFF - 0x2018 1) / 8 0x7E8 / 8 0xFD 253个Beat。不过实际上0x2FFF不是对齐端所以搬完253个Beat后最后一个地址是0x2018 252×8 0x2018 1260 0x2FCC超过0x2FFF了吗0x201812600x2FCC没有超过0x2FFF但下一个Beat地址是0x2FD4还是没超过0x2FD4小于0x3000但是距离0x3000还差0x2C字节等等我需要仔细算一下。0x2FFF到0x3000边界从0x2018开始的8字节窗口序号n地址0x20188n需要小于0x3000即0x20188n 0x3000所以8n 0xFE8n 0x1FD/8? 0xFE8/8 0x1FD 509所以n最大508也就是509个Beat。最后一个Beat地址是0x20188×508 0x20180xFE0 0x2FF8传输8字节到0x2FFF恰好不跨边界。所以第一个Burst AxLEN508传了508×84064字节不对509个Beat就是 AxLEN508传509×8 4072字节。从0x2018到0x2FFF总共0xFE84072字节。这才第一个Burst。第二Burst从0x3000开始总长度128字节的剩余呢如果总共只要搬128字节其实就不需要拆了啊我举的例子数字有点大。重新来起始地址0x2018搬运128字节64位总线AxSIZE3AxLEN(128/8)-115。4KB检查0x20181280x2098小于0x3000没有跨4KB边界所以一个Burst就够了。我需要一个真正跨边界的例子比如起始地址0x2FF0搬运128字节那0x2FF01280x3070跨了0x3000。那么从0x2FF0到0x2FFF只有16字节所以第一个Burst AxLEN1传2个Beat共16字节。第二个Burst从0x3000开始剩余112字节AxLEN(112/8)-113传14个Beat共112字节。这个例子更干净。这种拆分逻辑在写RTL时就是一段纯粹的地址计算状态机但很多人图省事只在软件层做硬件上不做防护一旦软件配置出错硬件不会自动拆总线就崩了。我现在写的DMA引擎都会在硬件里内置这个拆分逻辑软件侧只管发大请求硬件侧自动拆成多个合规的Burst这才叫靠谱的设计。5.2 波形图怎么看怎么对照代码排查看总线波形是每个SoC工程师的基础功但怎么快速从波形里识别出Burst和Beat的区别是有技巧的。我分享一个我自己习惯的读波顺序先找到AWVALID和AWREADY同时拉高的时刻这是Burst的起点。记录此时的AWADDR和AWLEN这是整个Burst的“计划书”。然后切到写数据通道W数一下从现在开始WVALID和WREADY同时拉高的次数。这个次数必须等于AWLEN 1。在波形工具里通常会给对齐的握手画上一个小记号这些记号就是Beat的完成点。读通道稍有不同因为读请求在AR通道上发起但数据返回在R通道。要找RVALID和RREADY的同时拉高并观察RLAST信号当RLAST为高且握手完成时意味着这是这个Burst的最后一个Beat。很多初学者以为读通道的burst也是通过AWLEN来判断结束实际上在读通道里你要关注RLAST而不是AWLEN。AWLEN只是用来知道你“期望”多少个Beat真正告诉你读数据流结束的是RLAST信号。有一次我排查一个AXI从设备返回数据多拍的问题主设备发起了一个AxLEN3的读Burst期望收到4个Beat的数据但R通道上多返回了2个Beat。最终发现是从设备的读状态机在生成RLAST时错误地以“FIFO里的数据数量”为准来拉高RLAST信号而不是以AxLEN为准。不过这种错误还算好查因为波形上RLAST和AxLEN期望值不一致非常明显反倒是那些“少拍”的bug比如RLAST提前拉高剩下的数据就挂在那边会带来难缠的hang问题。5.3 关于Burst类型选择的建议关于该用INCR还是WRAP或者FIXED很多场景里其实已经是大半个默认选择。一般DMA、普通读写都用INCR因为内存地址是线性的访问固定外设状态寄存器用FIXED因为寄存器地址不变Cache操作、块填充这类场景用WRAP因为它能让地址被约束在特定对齐窗口内方便和Cache内的地址tag做比较。但我想特别提醒不要过度使用WRAP。很多工程师觉得WRAP“更先进”会给普通的数据搬运也用WRAP。从功能上看WRAP没有错但它限制了你一个Burst里最多传的字节数——它必须是一个对齐窗口的大小。这意味着如果你想用一个WRAP Burst搬一个大块数据你得拆成很多个WRAP窗口来搬传输管理和地址恢复都变得麻烦。用INCR一把梭通常最省心。还有个细节FIXED类型虽然地址不变但每一个Beat的WSTRB可以不同。也就是说你可以对一个固定的32位寄存器端口连续写4次每次只写其中1个字节。这是FIXED标准用法经常用于写在同一个地址上的多个位域配置。如果你从设备逻辑里把所有Beat都当成整字写那位域配置就会错乱——我见过好几个这样的小模块在一个大系统里造成过配置错误查起来真的很伤。5.4 窄总线到宽总线的转换陷阱在一个多主多从的SoC里主设备和从设备的数据总线宽度往往不一致。比如CPU侧AXI总线是128位而你挂的一个外设总线是32位中间需要有一个宽度转换桥。此时一个128位总线上的Beat在32位总线上可能对应4个Beat。这里Burst和Beat的关系就变得更加微妙——从这里也能看出Beat这个概念并不是绝对物理上的“一拍”它还取决于你观察的是哪一段总线。宽度转换桥的核心逻辑是把宽总线侧的一个Beat拆成多个窄总线侧的Beat同时保持地址递增的连续性或者反过来把多个窄侧Beat积累成宽侧的一个Beat。这里最容易出错的地方是WSTRB的展开。宽侧写一个Beat32位有效数据WSTRB0xF但这是在128位总线的最高或最低32位字节通道上。转到窄侧时需要把宽侧总线上的哪个字节通道对应到窄侧总线的位置上搞清楚否则数据就会错位。我记得有一次做视频输出接口主设备是128位AXIVGA控制器是32位接口中间桥接了几个月总有小概率的花屏。最后就看到底是窄侧字节通道的映射在少量场景下反了。而且这种问题还不是每次必现只有在像素行末地址不对齐时才出现。调试这类问题建议在桥两侧同时拉出波形把“宽侧Beat”和“窄侧Beat”的地址做一次映射检查对不上再往下查。6. 仿真验证时如何正确构造Burst与检查Beat6.1 写Testbench时的推荐做法仿真层面我推荐的做法是把Burst当成一个transaction对象来产生把Beat当成stream item来处理。UVM里通常定义一个总线传输对象比如称为axi_transaction里面包含addr、len、size、burst等字段再定义一个数据对象对应每个Beat。发起激励时先生成一个完整的burst事务然后通过sequence把它拆解成一个一个beat发送到driver。Driver在驱动总线时按协议要求把每一个Beat的握手信号严格拉高直到双方都ready。这里最容易错的一个点是握手信号不能只靠延时对齐必须等双方都ready才算完成绝不能自说自话地推进到下一个Beat。否则你的验证环境就是带病工作后面所有数据比对都可能是错的。我见过一个验证工程师在driver里写了一个非常理想化的模型每拍都假设slave一定ready结果真实系统的slave内部有FIFO半满时要stall导致系统的时序行为和模型预期完全不符。也就是说至少在随机测试里必须让slave时不时拉低READY这样才能验证主设备对反压back-pressure的处理是否完善。6.2 断言与计分的监控点设置如果要在验证环境中加入监控和计分我的建议是设置三类监控点第一类是事务级监控点在AW/AR通道上捕获Burst请求。记录地址、长度、大小、类型这些是后续一切检查的基础。第二类是数据级监控点在W/R通道上逐Beat检查数据流。包括数据是否按照协议出现在合适的通道上、写数据的WSTRB是否和地址对齐规则匹配、读数据的RLAST是否出现在最后一个Beat。第三类是协议违例监控点。常见的检查项包括INCR突发是否跨越4KB边界、WRAP突发是否设置了非2幂次的len、AXSIZE超过总线宽度、FIXEDWRAP混用等。这些断言一旦触发就说明主设备端代码或激励有bug。计分板的比对逻辑建议也按Beat粒度做。对于写通道每个Beat的WSTRB决定了有效字节的位置比对时先根据WSTRB生成有效字节掩码再和期望数据比对。对于读通道则要根据RID和RLAST来匹配事务的返回特别是有多个outstanding读请求时读回的数据可能是乱序的不能按返回顺序直接比对。这个经验我觉得值得单独说一下out-of-order在读通道是允许的所以你的scoreboard必须支持按ID分组、乱序返回的数据比对否则仿真会报一堆莫名其妙的误报。7. 最后的一个实操小建议如果你刚开始接触AXI或者正在被一堆总线相关的概念绕晕我的建议是不要苦背手册而是动手做一个小实验搭一个最小验证环境主设备发一个INCR类型的BurstAxLEN3、AxSIZE2从设备侧做一个简单的FIFO然后拉出波形图。在波形图上你先找到AR/AW通道上的Burst请求再去R/W通道上数出4个Beat观察地址递增的方式观察RLAST的位置观察如果从设备拉低READY时Beat如何被拉伸。这个过程走一遍你对Burst和Beat的区别就不再停留在概念层面而是真正长在了手上。后面再去调真芯片、看总线协议分析仪的数据就能一眼看出工具上面标注的“Burst Start”和“Beat N”到底是什么关系了。
在SoC设计里摸爬滚打这几年AXI协议几乎是每天都要打交道的。之前带一个实习生调DMA搬运图像数据的用例他对着波形图问我“这明明是连续的几笔传输为什么日志里写的是1个Burst但波形上却有4个Beat这两个到底啥关系”这个问题看似基础但确实把很多刚接触AXI的工程师绕晕了。Burst和Beat这两个词在协议文档里反复出现但如果你没在真实的总线波形里盯过它们光看手册很容易把它们混为一谈。这篇就好好拆一拆这两个概念的区别顺带把地址计算、边界判断、窄传输这些容易踩坑的细节一并捋清楚。1. 先搞清楚两者的原始定义1.1 从协议文档的字面意思看差距AXI协议把一次完整的数据交换过程定义为一个交易Transaction而Burst就是构成这个交易的核心机制——它表示一次事务中主设备连续发起的一组数据传输。Beat则更底层它指的是一次单独的数据传输节拍也就是在总线上完成一次握手VALID和READY同时拉高的那一拍。换句话说Burst描述的是“一组连续传输”的组织形式Beat描述的是“一次实际数据搬移”的发生动作。一个Burst里可以有很多个Beat比如AxLEN3意味着这个Burst里有4个Beat。可以这么想Burst像一列火车的整个班次Beat就是这列火车里的一节车厢。火车班次决定起点站、终点站和有几个停靠点而每一节车厢才是真正拉货的单元。我见过有人把这两个词完全混着用在代码注释里写“这个burst包含8个burst”这种注释自己看着都别扭。协议文档明确区分了这三个层次Transaction事务 Burst突发传输 Beat节拍传输。弄清这层包含关系后面读任何AXI相关的IP文档、看总线波形、调性能计数器都会顺畅很多。1.2 为什么协议要区分这两个概念如果你只看功能好像Beat才真正承载数据Burst只是个“包装”。那协议为什么要单独定义Burst呢因为总线不仅要传数据还要传“关于数据的元信息”。Burst这个层级携带了三个关键参数长度AxLEN决定有几个Beat、大小AxSIZE决定每个Beat传多少字节、类型AxBURST决定地址怎么变化。这三个参数组合起来才能让从设备知道如何准备自己的存储空间如何计算地址如何校验接收完整性。Beat这个层级则携带了实际的写数据信号WDATA、写数据有效信号WSTRB、读数据信号RDATA、还有最后的响应信号RESP。可以说Burst是“计划”Beat是“执行”。没有计划执行就是乱的没有执行计划就是空的。SoC设计里你写总线主设备逻辑时本质上是在规划Burst写从设备接收逻辑时本质上是处理一个个Beat。这两个视角必须同时把握才不会出结构性bug。2. Beat的细节一次握手一次搬运2.1 Beat里那些容易忽略的字段一个Beat的读传输由AR握手和R握手共同定义。主设备发起AR通道的请求后从设备在R通道上送回应数据每个R通道的有效传输都算一个Beat。写传输则更复杂一些分为写地址通道AW上的一个Burst请求和写数据通道W上的多个数据节拍。关键点在于一个Burst只在AW通道上出现一次地址请求但在W通道上会出现AxLEN1个数据节拍。这里有一个特别容易误解的地方。很多人以为一个Burst里的多个Beat每一拍都必须紧挨着中间不能停。其实不是这样的。AXI协议允许每一拍之间有气泡gap只要VALID和READY没有同时拉高总线就处于等待状态不算完成一个Beat。所以从波形上看一个Burst里的多个Beat不一定在时间上连续。但它要求地址变化逻辑上连续固定、递增或回卷方式数据通道的逻辑关系是连续的。我在实际调试中见过一种情况写通道的WVALID拉高后从设备因为内部FIFO满了把WREADY拉低导致这一拍WVALID一直保持为高直到WREADY重新拉高握手成功才算这一Beat完成。这种情况下这一个Beat可能被拉伸成很多个时钟周期。从功能仿真上看数据没错但如果你用这个信号去做延迟估算会得出完全错误的结论。2.2 窄传输Beat与Strobe的对应关系再举一个Beat层面的经典细节——窄传输。假设数据总线是64位8字节但一个Beat只需要传输3个字节的有效数据。这时候数据总线并没有被全部占用AXI通过WSTRB信号来表明哪几个字节通道是有效的。WSTRB是8 bit每一位对应总线上一个字节置1表示这一字节有效。我调试过的一个图像缩放IP输入像素格式是RGB888一个像素3字节但总线是128位。当时主设备发出的写请求每个Beat的WSTRB都在不断跳变有时候只写4个字节有时候写8个字节。从设备的写FIFO必须严格按照WSTRB来拼接数据一旦拼接逻辑没考虑strobe的边界图像就会花屏。这个问题排查起来很折磨人因为读回地址上的数据和写进去的期望数据对不上但又不是每次都不对——只有行尾像素处理时才会错。Beat层面的处理逻辑写起来琐碎但恰恰是这些琐碎决定了一个总线IP能不能在真实场景里稳定运行。以后写RTL时凡是处理写数据的模块都要把WSTRB当成一等公民看待不要只在地址对齐时才处理它。3. Burst的核心机制三个参数定乾坤3.1 AxLEN、AxSIZE、AxBURST怎么配合Burst这个层级最核心的就是三个信号AxLEN长度、AxSIZE大小、AxBURST类型。AxLEN是8位表示突发长度减1。AxSIZE是3位表示每个Beat传输的字节数以2的指数形式表达000表示1字节001表示2字节010表示4字节011表示8字节以此类推。AxBURST是2位决定地址如何变化一共有三种类型FIXED固定地址、INCR递增地址、WRAP回卷地址。这三个参数之间的计算关系非常明确一次Burst传输的总字节数 (AxLEN 1) × 2^AxSIZEINCR类型的地址递增量 2^AxSIZEFIXED类型的地址始终不变WRAP类型有一个回卷上界一旦地址到达上界就回卷到起始地址对应的“基础地址”继续递增举个实际例子你要从某外设寄存器里连续读128字节数据数据总线宽度设成64位那么AxSIZE可以设成3表示8字节AxLEN设成15表示16个Beat这样总字节数 16 × 8 128字节。这个Burst走INCR类型地址从起始位置开始每个Beat增加8连续增加16次。这个组合非常常见几乎所有DMA搬数都是这类模式。3.2 Burst边界与4KB保护关于Burst边界有一个资深工程师必须刻在脑子里的规则任何Burst都不能跨越4KB地址边界。这是AXI协议的铁律因为4KB正好是一个典型的内存页大小也对应着大多数从设备比如某些片上存储、外设寄存器区域的地址窗口。如果让总线事务跨越4KB边界就可能访问到完全不同的从设备区域导致互联逻辑出大问题。实操中这意味着当你写DMA描述符或总线主设备逻辑时必须做4KB边界检查。如果你的传输起始地址是0x1FF0要给一个长度为128字节的Burst那么0x1FF0到0x207F跨越了0x2000边界这个Burst必须拆成两个一个先从0x1FF0传到0x1FFF16字节另一个从0x2000传到0x207F112字节。不拆的话很可能触发从设备报错或者数据错乱。我记得有一次排查一个PCIe控制器下的DMA偶发卡死问题最后定位到就是某个驱动配置的传输长度恰好让一次DMA跨过了4KB边界从设备那边把这次访问当成了非法访问直接不回应答导致总线挂着。从那以后我在所有DMA引擎的RTL前端都加了一个地址边界检测模块逻辑不复杂但能避免极难排查的死锁问题。3.3 WRAP边界为什么让人犯晕WRAP类型的Burst最容易被忽略也最容易写错。它在图像处理领域很常用典型场景就是cache line的填充或逐行处理。WRAP突发的特点是地址曲线上有一个上界和一个下界所有Beat的地址都约束在这个范围内越界就回卷。规定是这样WRAP突发只能用在AxLEN为2、4、8、16等2的幂次的情况下且突发的传输字节数不能超过这个“基础地址”的窗口大小。比如你设置AxSIZE24字节AxLEN34个BeatAxBURSTWRAP那么这个Burst的总字节数是16字节这16字节必须发生在16字节地址对齐边界内。起始地址可以是窗口内的任意4字节对齐位置但如果地址算到窗口上界下一个Beat就从窗口下界继续。我踩过的一个坑是在做图像行缓存操作时给AXI从设备配置了WRAP突发但起始地址设在了窗口的中间偏上位置导致前面两个Beat正常第三个Beat地址回卷后出现了一个很诡异的高位地址翻转。后来仔细看协议才知道地址回卷不是简单的“回卷到窗口起点”而是要在地址位宽内实现一种特定规则如果窗口大小是16字节地址的低4位到达0xF后再递增就变成0x0而高位的地址保持不变。本质上这是低比特位的回卷不是完整的地址回卷。搞清楚这个规则后我又去检查了好几个WRAP相关的从设备实现发现不少人在回卷逻辑上都有些小毛病。4. 区别在哪里Burst vs Beat的完整对照4.1 一张表看清核心差异为了让大家一目了然我把这两个概念的核心差异整理成一张对照表对比维度Burst突发传输Beat节拍传输层级事务层面的组织形式传输层面的单次动作携带的核心信息传输长度、数据大小、地址增长方式实际数据、字节使能、握手信号出现通道AW/AR通道一个事务一次W/R通道一个事务多次地址变化决定整体增长策略每个Beat执行具体地址递进波形特征对应一次完整的通道请求窗口对应一次VALIDREADY同时拉高的时刻寄存器状态通常由主设备状态机管理通常由从设备状态机逐拍处理边界约束不得跨越4KB地址必须保持在Burst定义范围内常见混淆点误以为一个Burst等于一拍误以为Beat之间必须无气泡这张表我建议新手直接存下来做总线级调试遇到概念混乱时翻一翻就能快速定位自己到底是在说哪个层面的事情。比如你是看性能计数器的那关注的永远是Burst的个数和Beat的总数如果你是在看数据完整性那就要逐Beat检查WSTRB和WDATA的匹配关系。4.2 物理层、协议层、仿真层的三重理解除了这张表我更想强调的是三个不同视角下的理解。在物理层的视角下Burst并不真实存在于时序中真实存在于时序里的只有一个个握手后的Beat。你拿逻辑分析仪抓总线波形时看到的其实是一连串的VALID/READY握手Burst只是你在事后通过地址变化规律反推出来的一个逻辑单位。用调试工具看波形时那些标注为“Burst”的框本质上是工具根据地址是否连续、通道请求是否相邻把多个Beat聚合成了一个显示单位。在协议层的视角下Burst却是实实在在存在的事务单位。从设备处理完最后一个Beat之后要么产生写响应B通道要么通过RLAST向主设备标出最后一个读Beat。RLAST这个信号值得注意它在读数据通道上标志着一个Burst的最后一个读Beat。也就是说从设备需要知道自己当前处理的Beat是不是这个突发请求中的最后一拍这直接影响它是否需要在B通道上给出响应或者在R通道上完成最后一次数据返回。你处理一个锁页lock防护逻辑也需要知道当前事务什么时候结束。这就是Burst在协议层发挥的作用。在仿真层的视角下两者的意义又不同。写testbench时我们通常按照Burst来生成激励比如用UVM的sequence发起一个“ INCR 长度16 ”的burst请求但在scoreboard检查数据时必须按照Beat来逐拍比对特别是要处理乱序返回out-of-order的情况。如果不搞清楚这两个层级连testbench里的回调函数都写不对——你会不知道该在哪个回调里比对地址、在哪个回调里比对数据。5. 实战中的经验与踩坑记录5.1 地址计算的经验法则与4KB拆分技巧先分享一个我在项目中反复使用的地址计算流程。当你要发起一次性搬运N字节的DMA请求时不要直接设一个大Burst完事而是要分三步走第一步对齐检查。计算起始地址和传输长度的边界对齐情况。如果起始地址不是AxSIZE所代表字节数的整倍数就得拆分。比如AxSIZE3表示每个Beat 8字节起始地址必须是8字节对齐。不对齐就会出问题没有例外。第二步4KB检查。估算总传输字节数看从起始地址开始是否会跨4KB边界。如果跨了按4KB边界拆成两个Burst并重新计算第二个Burst的AxLEN。第三步算AxLEN。每个Burst的剩余字节数除以每个Beat的字节数再减1得到AxLEN。举个例子假设64位总线起始地址0x2018搬运128字节AxSIZE3。检查发现第一个Burst从0x2018到0x2FFF跨了4KB边界所以第一个Burst只能传0x2018到0x2FFF这刚好是8字节对齐的0x2018到0x2FFF是0xFE8字节不对齐其实0x2018的8字节对齐点就是0x2018本身后面每步8字节到0x2FF070x2FF7之间下一个8字节就跨边界了所以传多少个Beat取决于从0x2018开始到0x2FF7有多少个8字节窗口——精确说是从0x2018递增8直到不超过0x2FFF。也就是 (0x2FFF - 0x2018 1) / 8 0x7E8 / 8 0xFD 253个Beat。不过实际上0x2FFF不是对齐端所以搬完253个Beat后最后一个地址是0x2018 252×8 0x2018 1260 0x2FCC超过0x2FFF了吗0x201812600x2FCC没有超过0x2FFF但下一个Beat地址是0x2FD4还是没超过0x2FD4小于0x3000但是距离0x3000还差0x2C字节等等我需要仔细算一下。0x2FFF到0x3000边界从0x2018开始的8字节窗口序号n地址0x20188n需要小于0x3000即0x20188n 0x3000所以8n 0xFE8n 0x1FD/8? 0xFE8/8 0x1FD 509所以n最大508也就是509个Beat。最后一个Beat地址是0x20188×508 0x20180xFE0 0x2FF8传输8字节到0x2FFF恰好不跨边界。所以第一个Burst AxLEN508传了508×84064字节不对509个Beat就是 AxLEN508传509×8 4072字节。从0x2018到0x2FFF总共0xFE84072字节。这才第一个Burst。第二Burst从0x3000开始总长度128字节的剩余呢如果总共只要搬128字节其实就不需要拆了啊我举的例子数字有点大。重新来起始地址0x2018搬运128字节64位总线AxSIZE3AxLEN(128/8)-115。4KB检查0x20181280x2098小于0x3000没有跨4KB边界所以一个Burst就够了。我需要一个真正跨边界的例子比如起始地址0x2FF0搬运128字节那0x2FF01280x3070跨了0x3000。那么从0x2FF0到0x2FFF只有16字节所以第一个Burst AxLEN1传2个Beat共16字节。第二个Burst从0x3000开始剩余112字节AxLEN(112/8)-113传14个Beat共112字节。这个例子更干净。这种拆分逻辑在写RTL时就是一段纯粹的地址计算状态机但很多人图省事只在软件层做硬件上不做防护一旦软件配置出错硬件不会自动拆总线就崩了。我现在写的DMA引擎都会在硬件里内置这个拆分逻辑软件侧只管发大请求硬件侧自动拆成多个合规的Burst这才叫靠谱的设计。5.2 波形图怎么看怎么对照代码排查看总线波形是每个SoC工程师的基础功但怎么快速从波形里识别出Burst和Beat的区别是有技巧的。我分享一个我自己习惯的读波顺序先找到AWVALID和AWREADY同时拉高的时刻这是Burst的起点。记录此时的AWADDR和AWLEN这是整个Burst的“计划书”。然后切到写数据通道W数一下从现在开始WVALID和WREADY同时拉高的次数。这个次数必须等于AWLEN 1。在波形工具里通常会给对齐的握手画上一个小记号这些记号就是Beat的完成点。读通道稍有不同因为读请求在AR通道上发起但数据返回在R通道。要找RVALID和RREADY的同时拉高并观察RLAST信号当RLAST为高且握手完成时意味着这是这个Burst的最后一个Beat。很多初学者以为读通道的burst也是通过AWLEN来判断结束实际上在读通道里你要关注RLAST而不是AWLEN。AWLEN只是用来知道你“期望”多少个Beat真正告诉你读数据流结束的是RLAST信号。有一次我排查一个AXI从设备返回数据多拍的问题主设备发起了一个AxLEN3的读Burst期望收到4个Beat的数据但R通道上多返回了2个Beat。最终发现是从设备的读状态机在生成RLAST时错误地以“FIFO里的数据数量”为准来拉高RLAST信号而不是以AxLEN为准。不过这种错误还算好查因为波形上RLAST和AxLEN期望值不一致非常明显反倒是那些“少拍”的bug比如RLAST提前拉高剩下的数据就挂在那边会带来难缠的hang问题。5.3 关于Burst类型选择的建议关于该用INCR还是WRAP或者FIXED很多场景里其实已经是大半个默认选择。一般DMA、普通读写都用INCR因为内存地址是线性的访问固定外设状态寄存器用FIXED因为寄存器地址不变Cache操作、块填充这类场景用WRAP因为它能让地址被约束在特定对齐窗口内方便和Cache内的地址tag做比较。但我想特别提醒不要过度使用WRAP。很多工程师觉得WRAP“更先进”会给普通的数据搬运也用WRAP。从功能上看WRAP没有错但它限制了你一个Burst里最多传的字节数——它必须是一个对齐窗口的大小。这意味着如果你想用一个WRAP Burst搬一个大块数据你得拆成很多个WRAP窗口来搬传输管理和地址恢复都变得麻烦。用INCR一把梭通常最省心。还有个细节FIXED类型虽然地址不变但每一个Beat的WSTRB可以不同。也就是说你可以对一个固定的32位寄存器端口连续写4次每次只写其中1个字节。这是FIXED标准用法经常用于写在同一个地址上的多个位域配置。如果你从设备逻辑里把所有Beat都当成整字写那位域配置就会错乱——我见过好几个这样的小模块在一个大系统里造成过配置错误查起来真的很伤。5.4 窄总线到宽总线的转换陷阱在一个多主多从的SoC里主设备和从设备的数据总线宽度往往不一致。比如CPU侧AXI总线是128位而你挂的一个外设总线是32位中间需要有一个宽度转换桥。此时一个128位总线上的Beat在32位总线上可能对应4个Beat。这里Burst和Beat的关系就变得更加微妙——从这里也能看出Beat这个概念并不是绝对物理上的“一拍”它还取决于你观察的是哪一段总线。宽度转换桥的核心逻辑是把宽总线侧的一个Beat拆成多个窄总线侧的Beat同时保持地址递增的连续性或者反过来把多个窄侧Beat积累成宽侧的一个Beat。这里最容易出错的地方是WSTRB的展开。宽侧写一个Beat32位有效数据WSTRB0xF但这是在128位总线的最高或最低32位字节通道上。转到窄侧时需要把宽侧总线上的哪个字节通道对应到窄侧总线的位置上搞清楚否则数据就会错位。我记得有一次做视频输出接口主设备是128位AXIVGA控制器是32位接口中间桥接了几个月总有小概率的花屏。最后就看到底是窄侧字节通道的映射在少量场景下反了。而且这种问题还不是每次必现只有在像素行末地址不对齐时才出现。调试这类问题建议在桥两侧同时拉出波形把“宽侧Beat”和“窄侧Beat”的地址做一次映射检查对不上再往下查。6. 仿真验证时如何正确构造Burst与检查Beat6.1 写Testbench时的推荐做法仿真层面我推荐的做法是把Burst当成一个transaction对象来产生把Beat当成stream item来处理。UVM里通常定义一个总线传输对象比如称为axi_transaction里面包含addr、len、size、burst等字段再定义一个数据对象对应每个Beat。发起激励时先生成一个完整的burst事务然后通过sequence把它拆解成一个一个beat发送到driver。Driver在驱动总线时按协议要求把每一个Beat的握手信号严格拉高直到双方都ready。这里最容易错的一个点是握手信号不能只靠延时对齐必须等双方都ready才算完成绝不能自说自话地推进到下一个Beat。否则你的验证环境就是带病工作后面所有数据比对都可能是错的。我见过一个验证工程师在driver里写了一个非常理想化的模型每拍都假设slave一定ready结果真实系统的slave内部有FIFO半满时要stall导致系统的时序行为和模型预期完全不符。也就是说至少在随机测试里必须让slave时不时拉低READY这样才能验证主设备对反压back-pressure的处理是否完善。6.2 断言与计分的监控点设置如果要在验证环境中加入监控和计分我的建议是设置三类监控点第一类是事务级监控点在AW/AR通道上捕获Burst请求。记录地址、长度、大小、类型这些是后续一切检查的基础。第二类是数据级监控点在W/R通道上逐Beat检查数据流。包括数据是否按照协议出现在合适的通道上、写数据的WSTRB是否和地址对齐规则匹配、读数据的RLAST是否出现在最后一个Beat。第三类是协议违例监控点。常见的检查项包括INCR突发是否跨越4KB边界、WRAP突发是否设置了非2幂次的len、AXSIZE超过总线宽度、FIXEDWRAP混用等。这些断言一旦触发就说明主设备端代码或激励有bug。计分板的比对逻辑建议也按Beat粒度做。对于写通道每个Beat的WSTRB决定了有效字节的位置比对时先根据WSTRB生成有效字节掩码再和期望数据比对。对于读通道则要根据RID和RLAST来匹配事务的返回特别是有多个outstanding读请求时读回的数据可能是乱序的不能按返回顺序直接比对。这个经验我觉得值得单独说一下out-of-order在读通道是允许的所以你的scoreboard必须支持按ID分组、乱序返回的数据比对否则仿真会报一堆莫名其妙的误报。7. 最后的一个实操小建议如果你刚开始接触AXI或者正在被一堆总线相关的概念绕晕我的建议是不要苦背手册而是动手做一个小实验搭一个最小验证环境主设备发一个INCR类型的BurstAxLEN3、AxSIZE2从设备侧做一个简单的FIFO然后拉出波形图。在波形图上你先找到AR/AW通道上的Burst请求再去R/W通道上数出4个Beat观察地址递增的方式观察RLAST的位置观察如果从设备拉低READY时Beat如何被拉伸。这个过程走一遍你对Burst和Beat的区别就不再停留在概念层面而是真正长在了手上。后面再去调真芯片、看总线协议分析仪的数据就能一眼看出工具上面标注的“Burst Start”和“Beat N”到底是什么关系了。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
