做片上网络这行只要项目里出现“NI”两个字母基本就意味着有人要开始连着几天对着波形发呆了。我第一次拿到网络接口 master 侧的设计任务时需求文档只有薄薄三页把 AXI 主机发出来的读写事务打包成 NoC 的 packet 送进路由器再把回来的响应还原成 AXI 语义。看上去就是一个 FIFO 加一个状态机的事真做起来才发现每一层都埋着细节——burst 怎么切、head flit 带不带数据、ID 怎么映射、响应怎么保序、credit 什么时候还、复位怎么对齐任何一处想当然后面都要用两倍的调试时间还回去。这篇就围绕 NoC 网络接口的 master 侧把我从功能定位、方案选型、拆包实现到仿真上板踩过的坑尽量完整地摊开讲一遍。它适合刚接触 NoC 集成的数字前端工程师也适合已经写过 AXI 外设、想往互连方向转的朋友不需要你事先懂路由算法但最好对 AXI 的 burst、ID、valid/ready 握手有基本概念剩下的部分我会尽量用生活化的类比把原理讲透。1. NI master 在 NoC 里的位置与职责边界1.1 一句话说清网络接口到底在干什么NoC 由两部分组成负责转发数据的路由器网络以及负责把外部设备接进来的网络接口。路由器像城市里的立交桥和主干道只关心“这个包从哪个口进、往哪个口出”网络接口则是匝道加收费站负责把外部设备那套完全不同的语言翻译成 NoC 能听懂的语言。上游的处理器、DMA、加速器说的是 AXI 或者 AHB语义是“一次 burst 读 16 拍、每拍 8 字节、ID 是 3”NoC 说的是 packet 和 flit语义是“一个包头带着目的坐标、源坐标、长度、包类型后面跟着若干个数据切片”。这两种语义之间没有天然对应关系中间那层翻译、拆分、缓存、重排的全部工作就是网络接口的活。放到 master 侧职责还要更具体一点它站在发起方这一边面向上游是一个 AXI 从端口因为上游主机是 AXI masterNI 对它是 slave面向下游是 NoC 的一个注入端口。请求方向上它要把 AXI 的读写命令吸收进来、拆成若干 flit 注入网络响应方向上它要把网络里飘回来的响应包接住、按 ID 归位、重新拼成符合 AXI 时序的 R 通道数据和 B 通道响应。这一进一出之间还夹着地址映射、位宽变换、时钟域跨越、outstanding 跟踪、反压处理任何一项没想清楚系统就会在某个奇怪的场景下挂住。很多人以为 NI 只是个协议转换壳子实际上它是整个 NoC 里状态最复杂的模块之一因为它是唯一同时理解两套协议、并且要为此维护大量上下文的部件。1.2 master 侧 NI 与 slave 侧 NI 的分工差异新手常犯的一个错误是把 master NI 和 slave NI 当成镜像关系觉得把方向反过来就能复用代码。实际做下来两者的设计重心差得很远。master 侧 NI 的核心矛盾在“拆分与追踪”。上游一个 AXI 主机可能同时挂着多个 ID、多个 outstanding 事务NI 要把它们全部接住按网络允许的粒度拆包同时记录每一个包属于哪个事务、什么时候能收齐响应。它的状态表是“一个事务一条记录”关注的是完整性和顺序性。slave 侧 NI 的核心矛盾在“并发与汇聚”。下游往往挂着一个存储器控制器或者一组外设多个 master 的请求会同时涌过来slave NI 要做的仲裁、地址转换、响应汇聚还要处理不同 master 之间的隔离。它的状态表是“一个端口一套队列”关注的是公平性和吞吐。再具体一点master NI 需要处理 AXI 的 burst 拆分而 slave NI 面对的是已经拆好的请求包它要做的是把包重新拼成 AXI 事务发给下游master NI 要维护响应重排序缓冲slave NI 则要维护请求队列和仲裁器。两边都有 ID 管理但 master 侧的 ID 是用来做响应归位的slave 侧的 ID 是用来做请求隔离的。理解了这个差异你在划分模块、定接口的时候就不会把不该耦合的东西耦在一起。1.3 为什么很多人的第一个 NoC 工程都栽在 NI 上我在几个项目里观察下来NI 成为 bug 集中营有几个结构性的原因不是谁水平不行。第一是语义层次多。AXI 一层就有 burst 类型、长度、大小、字节通道、ID、cache 属性、保护属性NoC 一层有 flit 宽度、包头字段、包类型、虚拟通道、credit 流控。两套语义要做正交映射组合数非常大你很难在设计阶段把所有组合都想到。第二是它经常正好卡在时钟域边界上。系统里 CPU 跑一个频率、NoC 跑另一个频率、存储器再跑一个频率NI 天然就是异步 FIFO 的宿主。跨时钟域的问题本来就隐蔽再加上协议状态机出错之后波形上看就是“某个信号偶尔不对”极难复现。第三是它同时是性能和功能的交点。功能上要保证不丢包不乱序性能上要保证 outstanding 打得满、credit 不断流。这两个目标经常互相拉扯你把 outstanding 开大重排序缓冲就变大你把拆包粒度做细包头开销就上去了。第四是验证难度高。一个 NI 的输入空间是“命令序列 × 数据模式 × 反压时序”的三维组合定向用例只能覆盖主干路径真正的角落要靠随机加断言去扫。很多团队前期只跑通了 happy path一上系统级联调就开始出问题。1.4 动手之前必须先问清的五个问题这一段是我自己的血泪总结。每次接手 NI 设计我会在写第一行 RTL 之前把这五个问题在评审会上问一遍答案不明确就不开工。序号必问问题不澄清的后果1NoC 的 flit 格式和包头字段定了吗拆包逻辑推倒重来2网络是否支持乱序同 ID 是否保证有序重排序缓冲白做或漏做3请求通道和响应通道是否走独立虚拟网络死锁风险无法评估4上游允许的最大 outstanding 是多少缓冲深度拍脑袋性能不达标5narrow transfer、exclusive、cache 属性怎么处理系统级功能缺失返工表格里第五条最容易被忽略。很多 NoC 在设计时默认所有传输都是对齐的、全宽度的、非独占的结果上游 CPU 发一个非对齐的窄传输过来NI 要么直接算错地址要么把不该合并的字节通道合并了。这类问题在模块级仿真里根本看不出来因为你的激励就是按对齐全宽写的等到系统级跑操作系统一个 memcpy 就炸了。提示这五个问题最好形成一份简短的接口约定文档和 NoC 团队、SoC 集成团队三方签字。口头对齐在半年后的联调阶段基本等于没对齐。2. 核心功能拆解与设计选型背后的取舍2.1 协议转换AXI 事务字段到 NoC 包头的映射关系协议转换是整个 NI 的第一层也是最基础的一层。AXI 的一次读事务携带的信息包括地址、burst 长度、每拍字节数、burst 类型、ID、cache 属性、保护属性写事务还多一个写数据通道和字节选通。NoC 的包头通常需要目的节点坐标、源节点坐标、包类型读请求、写请求、读响应、写响应、事务 ID、地址、长度、以及一些流控和 QoS 字段。映射的时候不是一对一照抄而是要做语义压缩。比如 AXI 的 burst 类型有 FIXED、INCR、WRAP 三种但在很多 NoC 里只支持线性的地址递增那么 WRAP 类型就必须在 NI 里先展开成若干段线性 burst 再发或者干脆在接口约定里声明不支持让上游软件规避。再比如 AXI 的字节选通是每拍一个位向量NoC 的 flit 里如果不带选通位你就得在 NI 里把选通转换成“有效字节数 起始偏移”或者干脆把数据先对齐再发。我一般会在设计文档里画一张完整的映射表把 AXI 的每个字段和 NoC 包头的每个字段列出来标清楚哪些是直通、哪些是变换、哪些是丢弃。这张表是后面写 RTL 和写验证用例的共同依据比任何口头描述都管用。AXI 字段NoC 包头对应处理方式awaddr / araddrdst_id offset高位查表得目的节点低位作偏移awid / aridtxn_id位宽不足时做压缩映射awlen / arlenpkt_len按拆包策略重新计算awsize / arsizebyte_en 描述转成有效字节信息awburst / arburst无INCR 直通WRAP 需展开awcache / arcache无或标志位多数场景丢弃需与系统确认awvalid / wvalidpkt_valid经状态机转换这张表里最容易出问题的是 ID 那一行。AXI 的 ID 宽度是上游主机决定的常见 4 位到 8 位NoC 包头里给 ID 留的字段往往只有 3 位到 4 位。位宽不够就得做映射而映射一旦做错响应回来的时候就找不到原来的事务表现为“某个读请求永远等不到数据”。这块后面 2.4 节会专门展开。2.2 事务拆分从 burst 到 packet 的两种切法拆包策略是 NI 设计里第一个真正需要做取舍的地方直接决定了带宽效率和逻辑复杂度。第一种策略我称为“一拍一包”也就是 AXI burst 的每一拍数据单独组成一个最短的 packet注入网络。这种做法逻辑极简一个 AXI 拍进来就立刻转成一个 flit 发出去不需要缓存整个 burst状态机只有几个状态。代价是包头开销巨大如果一个 flit 的有效载荷是 16 字节而包头本身占了 8 字节的字段虽然物理上还在同一个 flit 里但路由和交换资源被占用了有效带宽就会明显下降更严重的是每个包都要单独走一遍路由路由器的仲裁压力成倍增加延迟也会上去。第二种策略是“按 flit 边界合并”也就是把连续的多拍 AXI 数据拼成较长的 packet一个 packet 里包含一个 head flit 加上若干个 body flit 和一个 tail flit只有 head flit 携带完整包头body flit 只带少量标志位甚至不带。这种做法的带宽效率高路由开销被摊薄是大规模 NoC 的主流选择。代价是 NI 内部必须有一个至少能容纳一个 packet 的缓冲状态机要处理“数据还没攒够但 tail 已经到了”的情况还要处理反压时缓冲不溢出的问题。还有一个中间派的折中方案设一个最大包长约束比如一个 packet 最多包含 4 个 flit超过就切成多个包。这样既摊薄了包头开销又限制了单个 packet 占用的网络资源避免一个大 burst 长时间霸占某条链路造成拥塞。我在实际项目里用得最多的就是这个方案包长上限一般取 4 到 8 个 flit具体值要看网络直径和典型负载。策略逻辑复杂度带宽效率延迟特性适用场景一拍一包低低单包延迟低总吞吐差小规模网络、低频次访问按 flit 合并高高单包延迟高总吞吐好大流量、长 burst限长折中中中高平衡大多数通用场景注意包长上限不是随便定的。如果定得比路由器的缓冲深度还大一个包就可能跨越多个路由节点时被反复阻塞反而拉高平均延迟。这个值要和 NoC 团队一起评估。2.3 地址映射与路由信息生成包头里那个目的坐标怎么来网络接口要做的第二件事是决定包往哪儿送。上游 AXI 主机给出的是一个扁平的系统地址NoC 需要的是一个节点编号或者坐标中间这层转换就在 NI 里完成。常见的实现方式有两种。一种是硬连线比较把系统地址空间按区间切好每个区间对应一个目的节点号用一组比较器做并行判断输出目的 ID。这种方式延迟低、面积可控缺点是地址空间一旦调整就要改 RTL。另一种是查表把地址到节点号的映射写在一张小表里运行时可以配置灵活但多了一级读表的延迟。规模小的系统用前者地址空间会动态变化的系统用后者。这里有一个容易踩的细节地址对齐。AXI burst 的起始地址不一定是 flit 宽度的整数倍。假设 flit 有效载荷是 16 字节上游发来一个起始地址是 0x1004 的 8 拍读那么第一个 flit 里只有 12 个字节是这次的、前 4 个字节属于上一段地址空间直接按 flit 对齐去取就会错位。处理办法是在 NI 里做一次对齐预处理把起始地址向下取整到 flit 边界同时记录有效的字节偏移从对齐后的位置开始读数据再在返回路径上把多余的头尾字节丢掉。这个预处理逻辑写起来不难但极其容易在 corner case 上翻车尤其是当地址跨越 flit 边界、同时 burst 长度又很短的时候。我在一个项目里就遇到过起始地址 0x10FC、长度 4 拍的读请求前 4 字节在一个 flit 的尾部、后 28 字节在下一个 flit 里对齐逻辑没处理好返回数据整体移位了 4 个字节表现是软件读到的结构体字段全部错乱。这种 bug 在模块级仿真里如果用对齐地址做激励是永远发现不了的。所以我给自己定了一条规矩NI 的所有验证用例里非对齐起始地址的比例不能低于三成而且要专门构造“跨 flit 边界”和“跨 4KB 边界”的定向用例。2.4 ID 管理与乱序响应为什么读数据回来会找不到主这是 master 侧 NI 里最绕的一块也是我见过最多人栽跟头的地方。AXI 协议允许不同 ID 的事务乱序完成同一个 ID 的事务必须保序。上游主机之所以需要这个特性是为了让多个不同来源的访问互不阻塞——比如一个 CPU 同时发出取指和取数请求两者 ID 不同取数慢了不应该卡住取指。NoC 网络本身如果是一个包交换网络理论上不同包的到达顺序是不确定的这正好和 AXI 的乱序语义契合但前提是 NI 要能把回来的响应正确归位。归位的关键就是 ID。NI 在发出请求的时候要把上游 AXI 的 ID 和自己分配的包序号绑定起来记录在一张 outstanding 表里响应回来的时候用包里的 ID 或者序号去查表找到对应的原始事务再按 AXI 的顺序要求吐出数据。如果 NoC 包头里的 ID 字段比 AXI 的 ID 窄就需要做压缩映射比如 4 位 AXI ID 映射到 3 位网络 ID那么多出来的那一位就得用别的方式记住或者干脆限制上游最多只用 8 个 ID。我一般会把 outstanding 表设计成一个小的内容寻址结构每一条记录包含有效位、AXI 原始 ID、网络 ID、剩余待收 flit 数、数据缓冲区指针、写响应待收标志。当响应包到达用网络 ID 去匹配匹配到就把数据写进对应的缓冲位置剩余计数减一减到零就触发一次 AXI 响应输出。这里有个隐含的假设同一个 AXI ID 的多个事务在网络里是按顺序回来的。如果 NoC 不保证这一点你就必须在 NI 里再加一级按 ID 排序的重排逻辑代价是缓冲翻倍、延迟增加。所以 1.4 节里的第 2 个问题必须问清楚——这不是优化项是决定架构的问题。提示如果网络确实无法保证同 ID 有序最省事的做法不是加排序逻辑而是在 NI 里把同一个 AXI ID 的事务串行化也就是同一个 ID 同时只允许一个事务在飞。这样逻辑简单代价是同 ID 的并发度降为一需要评估对性能的影响。2.5 位宽变换与时钟域跨越那些看起来简单却最容易出事的模块位宽变换这一块逻辑本身不复杂但边界条件多。典型场景是上游 AXI 数据宽度 64 位NoC flit 有效载荷 128 位需要一个 2 比 1 的拼装。写方向上要等两拍 AXI 数据凑齐才发一个 flit读方向上反过来要把一个 flit 拆成两拍返回。麻烦在于 burst 长度是奇数的时候最后一个 flit 只有半满要正确标记有效字节。还有就是反压的时候如果第一拍已经收进来了、第二拍迟迟不来缓冲里就悬着一个半成品状态机必须能正确记住这个中间态。时钟域跨越是另一个雷区。NI 常常是上游 AXI 时钟域和 NoC 时钟域的交界请求方向要做异步 FIFO响应方向也要做。异步 FIFO 的深度选择有个经验值至少能吸收两个时钟周期的最坏相位差加上突发长度太浅会导致频繁反压从而拉低吞吐太深则面积和延迟都上去了。我在一个项目里因为 FIFO 只做了 4 深结果上游突发 8 拍的时候每一拍都要停顿实测带宽只有理论值的一半。复位处理也值得单独提一句。两个时钟域的复位释放顺序如果不对异步 FIFO 的读写指针可能进入一个非法状态表现为上电后偶尔丢第一个包。稳妥的做法是让 NoC 侧先释放复位、上游侧后释放并且在异步 FIFO 里加指针合法性检查。2.6 QoS 与虚拟通道什么时候真的需要虚拟通道和 QoS 这一层很多入门项目里是不做的所有流量走一条通道先到先服务。这样做的优点是简单缺点是在混合流量场景下一个大的 DMA 写突发可能把一条关键的读请求堵在后面造成明显的延迟抖动。是否需要引入虚拟通道我的判断标准是看系统里有没有“延迟敏感但带宽不高”的流量。比如中断控制器、配置寄存器的访问带宽极小但对延迟敏感而大块数据搬运带宽大但对延迟不敏感。这两类流量混在一条通道上后者会把前者堵死。这时候就值得在 NI 里做至少两条虚拟通道按 ID 或者按地址区间分流。分流策略一般有两种静态优先级和加权轮询。静态优先级实现简单但低优先级流量在拥塞时可能被饿死加权轮询公平性好逻辑复杂一些。我的经验是如果高优先级流量占比很小比如不到 5%静态优先级就够了如果两类流量比例接近就要上加权轮询。3. 一次 128 字节 burst 的完整拆包实录3.1 先把参数钉死一个具体的设计点为了把上面的概念落到实处我用一个具体的设计点走一遍完整流程。这个参数组合是典型的入门配置也是我在教学和带新人时最常用的例子。上游接口AXI4数据宽度 64 位ID 宽度 4 位支持 INCR burst最大 burst 长度 16 拍地址按 8 字节对齐。NoC 侧flit 宽度 128 位其中 16 位留给包头字段包类型、源、目的、序号112 位留给有效载荷一个 packet 最多 4 个 flit采用 credit 流控初始 credit 为 8。现在上游发来一个读请求起始地址 0x2000burst 长度 16 拍每拍 8 字节ID 为 3。总数据量是 16 × 8 128 字节。先算拆包结果。每个 flit 的有效载荷是 112 位也就是 14 字节不是 16 字节——这一点很多人会算错因为包头占用了位宽。128 字节除以每 flit 14 字节向上取整是 10 个 flit。但一个 packet 最多 4 个 flit所以要拆成 3 个 packet4 4 2。等一下这里还要考虑 head flit 是否携带数据。如果 head flit 的 112 位载荷全部用于数据那么第一个 packet 的 4 个 flit 都能装数据总共 4 × 14 56 字节第二个 packet 同样 56 字节第三个 packet 需要装剩下的 16 字节用 2 个 flit28 字节容量就够最后一个 flit 只有 2 字节有效其余填充。这样总共 3 个 packet、10 个 flit。如果 head flit 因为要放完整包头而不携带数据那么每个 packet 实际只能传 3 个 flit 的数据也就是 42 字节128 字节需要 4 个 packet。包头开销从 1/10 涨到 1/13效率明显下降。这个计算过程说明一件事flit 的位宽分配不是纯物理问题它直接影响拆包效率和 NI 内部的缓冲设计。在评审 flit 格式的时候一定要把典型负载的拆包结果算一遍看看包头开销占比是否可接受。项目数值说明AXI 数据宽度64 位每拍 8 字节burst 长度16 拍总 128 字节flit 总宽度128 位链路位宽flit 包头16 位控制字段flit 有效载荷112 位14 字节单包 flit 上限4网络约束head 带数据时总 flit 数103 个 packethead 不带数据时总 flit 数134 个 packet3.2 拆包状态机的状态划分拆包引擎是整个 master NI 的心脏我一般把它设计成六个状态逻辑清晰且便于加断言。第一个状态是空闲态等待上游的地址通道握手。一旦 arvalid 和 arready 同时有效锁存地址、长度、ID、burst 类型进入第二个状态。第二个状态是请求预处理态。这里做三件事把起始地址对齐到 flit 边界并记录偏移量把 AXI 的字节选通转换成 flit 内部的有效字节标记根据长度和 flit 容量算出总共需要多少个包、每个包多少 flit把结果写进一个小的描述表。第三个状态是发送态。按描述表逐包构造 flit先发 head flit写入目的节点、源节点、事务序号、包类型再发 body flit逐拍从上游数据通道取数据填充最后发 tail flit标记包结束。每发出一个 flitcredit 计数减一计数为零就停在发送态等待。第四个状态是等待响应态。请求包全部发完之后把这条事务挂到 outstanding 表里等待响应包回来。这个状态不影响后续请求的接收NI 可以继续处理下一条请求所以它其实不是一个阻塞状态而是并行存在的上下文。第五个状态是响应重组态。响应包到达后用包内序号查 outstanding 表把数据写进对应的缓冲同时把 AXI 的 ID 还原回去。第六个状态是响应输出态。当一个事务的所有数据都到齐就拉高 rvalid按 AXI 时序一拍一拍吐出数据最后一拍拉高 rlast。这六个状态里最需要小心的是第三个和第五个之间的配合。发送态是逐 flit 推进的响应重组态是逐包触发的两者通过 outstanding 表解耦。如果表项不够用发送态就必须停下来等这就是 outstanding 深度限制的实际体现。3.3 握手与 credit 反压的具体写法credit 流控的逻辑很直白但要写对细节。核心是两组计数器一组记录下游还有多少可用 credit初始值等于下游缓冲深度一组记录已经发出但还没收到 credit 返还的 flit 数。发送一个 flit 的条件是当前有数据要发、下游 ready、并且可用 credit 大于零。每发一个 flit可用计数减一每收到一个 credit 返还信号可用计数加一。这里有个细节是 credit 返还是按 flit 计还是按包计取决于网络实现。如果是按 flit 计返还信号和发送信号之间要有正确的对应关系绝不能出现上游多减了或者下游多还了的情况否则整个链路会慢慢失去平衡表现为运行一段时间后突然卡死。我一般会在 RTL 里加一条断言可用 credit 计数器的值永远不超过初始深度也永远不为负。这条断言在仿真里能抓出绝大多数的 credit 泄漏问题。// credit 计数与发送许可示意非完整实现 always (posedge clk or negedge rst_n) begin if (!rst_n) credit_cnt CREDIT_INIT; else if (flit_fire !credit_ret) credit_cnt credit_cnt - 1b1; else if (!flit_fire credit_ret) credit_cnt credit_cnt 1b1; end assign flit_fire flit_valid flit_ready (credit_cnt ! 0); // 断言credit 不得越界 // assert property ((posedge clk) disable iff (!rst_n) // credit_cnt CREDIT_INIT);上面这段只是骨架实际代码里还要处理 credit 返还和发送同拍发生的情况也就是计数不变。这种“同拍加减抵消”的写法能省一个周期的延迟但对时序要求更高如果综合后关键路径吃紧可以退化成两个独立计数器再相减。3.4 响应路径的还原与保序检查响应回来的路径要比请求路径更谨慎因为这里涉及数据正确性。一个响应包到达后第一步是解析包头取出事务序号和包内偏移。第二步是查 outstanding 表如果查不到对应表项说明这是一个不该出现的包要么是序号算错了要么是网络串包了这时候要拉高错误标志并记录现场绝不能默默丢弃。第三步是把数据写进缓冲的对应位置写的时候要按包内偏移定位不能简单地追加因为多个包可能乱序到达。第四步是更新剩余计数减到零就触发输出。输出的保序逻辑是另一个重点。AXI 要求同 ID 保序不同 ID 可乱序。如果 NI 内部是多条事务并行推进的输出时就要做一次按 ID 分组的顺序检查。我的做法是给每个 AXI ID 维护一个小的顺序计数器事务挂表的时候分配一个序号输出的时候只有序号最小的那个才能吐出去。这样实现起来逻辑简单代价是同一 ID 的多个事务在输出端会串行化但这对大多数场景是可以接受的。还有一个容易漏的点是写响应。写事务的数据发完之后还需要等下游返回一个写响应NI 要把它转换成 AXI 的 B 通道响应。这个响应的 ID 要和原始写事务的 ID 一致而且如果上游有多个写事务在飞响应顺序也要符合 AXI 的规则。我在早期版本里就漏了写响应的 ID 还原结果所有写响应都用 ID 0 返回跑单事务测试完全正常跑多事务并发就错乱。3.5 一个最小可用的模块划分把上面的内容落到模块上我一般会切五个子模块地址解码器负责把系统地址转成目的节点号请求拆包器负责把 AXI 事务拆成 flit 序列发送仲裁器负责在多个请求之间调度并管理 credit响应重组器负责接收响应包并按事务归位响应输出器负责按 AXI 时序吐出数据。五个模块之间用 FIFO 或者简单的 valid/ready 连接每个模块都能单独验证。这种切法的好处是每个模块的状态机都很小出了问题容易定位到底是哪一级。坏处是多了一级流水延迟略有增加。对于入门项目我认为这个代价完全值得因为可调试性比省那两个周期重要得多。4. 常见问题与排查技巧实录4.1 仿真跑着跑着挂住先查 credit 再查依赖环仿真卡死是 NI 调试里最常见的现象波形上表现为某一时刻之后所有 valid 都不再变化或者某一方一直等 ready 而另一方一直等 valid。排查的时候我按固定顺序走。第一站查 credit。找到发送侧的 credit 计数器看它是不是掉到零之后再也没涨回来。如果确实如此顺着 credit 返还信号往回追看下游到底有没有发返还是不是返还信号被某种条件屏蔽了。最常见的根因是返还路径和发送路径共用了某个 FIFO而 FIFO 满了之后返还也被堵住形成互锁。第二站查请求-响应依赖环。如果请求通道和响应通道共享了物理资源比如同一个虚拟通道、同一组缓冲就可能出现“请求要发出去才能腾出缓冲给响应响应要回来才能腾出缓冲给请求”的死锁。这类问题在轻负载下完全不出现一旦并发度上去就必然发生。解决办法是把请求和响应分成两个独立的虚拟网络物理上不共享缓冲从根上断掉环路。第三站查握手协议本身。有些设计里 valid 的产生依赖 readyready 的产生又依赖 valid综合出来的组合逻辑形成环路。这种写法在 RTL 仿真里可能因为延迟模型不同而偶尔通过上板必挂。规矩很简单valid 只能由数据可用性决定不能看 ready。现象优先排查典型根因credit 停在零不涨返还路径FIFO 共用导致互锁高并发下挂死请求响应是否共享资源依赖环组合逻辑振荡握手依赖valid 依赖 ready某 ID 事务永不完成响应是否丢失ID 映射错误4.2 数据整体错位几个字节对齐和 tail 判断是重灾区数据错位的表现很好认仿真能跑完不报错但 scoreboard 比对的时候数据整体偏移了整数个字节或者最后一个 flit 的数据是上一段的。这类问题的根因通常只有两个。第一个是起始地址没对齐。前面 2.3 节讲过AXI burst 起始地址可能不在 flit 边界上如果拆包的时候直接按 flit 取数就会把不属于本次事务的字节带进来。解决方案是在预处理阶段把地址向下取整同时记录偏移量返回时按偏移量裁掉多余的字节。第二个是 tail 判断错误。当一个 packet 的最后一个 flit 没有装满时剩下的字节通道应该是无效的如果错误地把它们当成有效数据发出去或者接收端错误地把它们当成有效数据收进来就会在数据流里插入垃圾。判断的依据是事务总长度和已经传输的字节数两者相减得到剩余量剩余量小于 flit 容量时就要标记部分有效。这里有个隐蔽的坑如果 burst 长度不是 flit 容量的整数倍最后一个 flit 的部分有效标记必须精确到字节而不是简单地标记“这一拍有效”。我见过一个实现里只标记了拍级有效字节级全开结果最后一个 flit 里多出来的字节被下游当成了真实数据写进存储器把相邻的数据覆盖掉了。这种错误在功能仿真里如果存储器模型不做写保护检查是完全看不出来的。注意验证环境里的存储器模型一定要打开越界写检查和写保护检查。很多数据破坏类的 bug 就是靠这个抓出来的。4.3 模块级全过、系统级挂掉跨时钟域和复位顺序这是最让人抓狂的一类问题因为你手上所有的模块级用例都是绿的一上系统就开始偶发失败而且往往不能稳定复现。跨时钟域是第一嫌疑。检查异步 FIFO 的读写指针是否做了格雷码转换空满判断是否用了保守策略复位释放是否做了同步。我遇到过一次异步 FIFO 的写指针直接用了二进制码跨域大部分时间能工作但在指针从 7 跳到 8 的时候多位同时变化采样端偶尔采到中间值导致空满判断错误。这种问题在低频下几乎不出现一旦跑高频就开始丢包。复位顺序是第二嫌疑。如果 NoC 侧的复位比上游侧先释放而 NI 内部的异步 FIFO 在复位期间指针处于不确定状态就可能出现第一个包被吞掉的情况。稳妥的做法是两个时钟域的复位各自同步释放并且在 NI 内部加一个短暂的启动屏蔽期等所有 FIFO 的空满标志稳定之后再放行数据。第三嫌疑是 X 传播。模块级仿真里很多信号初始值是 X但因为用例简单没暴露系统级一上电某个 X 沿着数据通路传下去把整个状态机带偏。解决办法是在所有状态机和关键寄存器的复位分支里给确定值并且在仿真里打开 X 检查。4.4 带宽只有理论值一半outstanding 和包长是两个抓手性能不达标的问题排查思路和功能问题完全不同。先做一件事在仿真里统计实际吞吐和理论值对比算出差距比例。如果差距在 20% 以内通常是开销问题如果差一倍基本就是并发度不够。并发度不够的第一个原因是 outstanding 深度太小。如果 NI 一次只允许一个事务在飞那么每次读都要等响应回来才能发下一个延迟完全暴露吞吐被延迟锁死。这种情况下把 outstanding 从 1 提到 4吞吐往往能翻两三倍。第二个原因是包长太短。如果每个 AXI 拍都单独成包包头开销占比可能超过三成有效带宽自然上不去。把包长从 1 提到 4开销摊薄吞吐明显改善。第三个原因是响应通道成为瓶颈。有些设计里请求通道做得很宽响应通道却很窄或者响应通道的缓冲深度不够导致数据回来了却没地方放只能反压网络。这种不均衡在写密集和读密集场景下表现完全不同需要分别测。我在实际项目里的做法是搭一个简单的性能测试台用固定模式的流量全读、全写、读写各半、随机长度跑一遍记录吞吐和延迟两个指标形成一张基线表。以后每次改设计都跑一遍这张表性能回退立刻就能发现。4.5 一份可以直接对照的问题速查表现象可能原因排查动作仿真卡死不动credit 耗尽或依赖环看 credit 计数和返还信号数据错位起始地址未对齐检查预处理阶段的地址取整尾部数据是垃圾tail flit 字节标记错误检查剩余字节计算某事务永不完ID 映射冲突或响应丢失查 outstanding 表匹配偶发丢包跨时钟域指针未做格雷码检查异步 FIFO 实现上电首个包丢失复位释放顺序检查复位同步链带宽只有一半outstanding 太小或包太短统计并发度和包长分布高优先级流量被饿死仲裁策略问题检查是否用了纯静态优先级5. 验证策略与交付前的自检清单5.1 激励怎么造定向打底随机扫角落NI 的验证不能只靠随机也不能只靠定向两者要配合。我的经验配比是定向用例覆盖协议主干随机用例扫组合空间比例大概三七开。定向用例至少要覆盖这么几类单拍读写、最大长度 burst、非对齐起始地址、跨 flit 边界的 burst、跨 4KB 边界的 burst、部分字节有效的窄传输、多个 ID 并发、写后读同一地址。这几类跑通了主干路径就没有大问题。随机用例的关键是约束要合理。完全无约束的随机地址和长度会产生大量无意义的组合覆盖率涨得慢。我的做法是把地址约束在几个有代表性的区间、长度约束在 1 到 16 之间、ID 约束在 0 到最大值、并且按一定概率注入反压。反压注入特别重要很多握手相关的 bug 只有在特定反压时序下才会出现。还有一个技巧是在随机用例里故意制造“同一 ID 的连续事务”和“不同 ID 的交错事务”这两种模式对乱序处理的考验完全不同前者考保序后者考归位。5.2 断言写什么五条能抓住大部分问题断言比覆盖率更早发现问题我一般在 RTL 里就埋好不依赖验证环境。第一条credit 计数不越界。前面提过这条能抓 credit 泄漏。第二条同一 AXI ID 的响应必须按请求顺序输出。这条能抓保序逻辑的漏洞。第三条任何 valid 拉高之后必须在有限周期内被 ready 接受否则报超时。这条能抓死锁。第四条响应包的数量必须和请求包的数量匹配不能多也不能少。这条能抓丢包和重复包。第五条输出数据的字节数必须和原始请求的长度一致。这条能抓长度计算错误。这五条写下来不到一百行但在我做过的每个项目里都至少抓到过一次真问题。特别是第三条和第四条系统级联调阶段基本靠它们定位。5.3 面积和时序的权衡别在小地方过度设计最后说一点工程上的取舍。NI 这个模块功能正确是第一位的但也不能无限堆资源。outstanding 表的深度直接决定面积。从 4 提到 8表项翻倍匹配逻辑也变复杂。如果系统里的典型并发度只有 2 到 3做到 8 就是浪费。判断依据是看上游主机的实际行为而不是看协议允许的最大值。重排序缓冲也是类似。如果网络本身能保证同 ID 有序这一级缓冲可以大幅简化甚至省掉。所以在架构评审阶段和 NoC 团队确认这个特性能省下不少面积。时序上的关键路径通常在地址解码和 ID 匹配这两处。地址解码如果是并行比较器位宽一大就容易成为瓶颈可以改成两级流水ID 匹配如果是全表扫描表项一多延迟就上去了可以改成哈希或者分段匹配。这些优化都是后话先把功能跑通再谈。我在几个项目里反复体会到的一件事是NI 这个东西写出来不难写对很难写到性能达标更难。真正拉开差距的不是你把状态机画得多漂亮而是你有没有在动手之前把那五个接口问题问清楚有没有在验证阶段把非对齐和反压这两个角落覆盖到有没有在仿真卡死的时候按顺序一站一站排查而不是乱改代码。上面这些内容每一条背后都是我或者同事实际踩过的坑希望你在自己的项目里能少走一遍。