企业官网建设流程全解析

做多核SoC或者AI加速器的人，迟早会碰到一个绕不开的模块——NoC。而只要开始画NoC的框图，交换矩阵（Switch Matrix，也叫Crossbar、交叉开关）就是那个必须自己动手写、又最容易出问题的地方。我见过不少项目，拓扑图画得挺漂亮，Mesh、Ring、Tree都有模有样，仿真也能跑通，结果一上综合就傻眼：面积翻倍、频率差一截、时序收敛不了，最后只能把交换矩阵整个推倒重来。问题往往不在拓扑，而在于这个矩阵内部怎么排队、怎么仲裁、缓冲挖多深，这些决定成败的细节在教科书里通常只有一句话带过。

这篇就把交换矩阵单独拎出来讲透。我会从它为什么必须存在说起，拆开它的内部结构，然后手把手写一个参数化的4x4实现，最后把时序、面积、死锁这些真正会咬人的坑一个个摆出来。不管你是刚开始接触NoC的在校学生，还是已经做过一两版总线互连、准备往片上网络迁移的工程师，应该都能从里面拿到可以直接复用的东西。

1. NoC交换矩阵到底在解决什么问题

1.1 共享总线撞上的三堵墙

早期SoC里，几个主设备挂一条总线，再加个仲裁器，日子过得挺好。但核数一多、加速器一多，这套架构会接连撞上三堵墙，而且是一堵比一堵硬。

第一堵是带宽墙。共享总线在任何一个时刻只能服务一对主从通信，N个主设备抢一条通路，理论峰值带宽是固定的。你可以加宽位宽，但位宽翻倍意味着走线翻倍、布线资源翻倍，收益远没有想象中线性。第二堵是扩展墙。挂载的设备越多，总线上分布的负载电容越大，驱动能力跟不上，频率只能往下降，物理实现阶段还得插一堆缓冲器，面积和功耗一起涨。第三堵是并发墙，这一堵最要命——多核场景下的通信本质上是并发的，核A给核B发数据的同时，核C可能正在访问内存，核D在往DMA搬数据。共享总线强制把这些并行事务串行化，等于给整个系统加了一道全局锁。

交换矩阵就是为了拆掉这三堵墙而生的。它的基本形态是一个N输入、M输出的交叉点阵列，只要输入和输出不冲突，多个事务可以同时穿过去。带宽从O(1)变成O(N)，并发从"排队"变成"并行"，这就是它存在的全部理由。

1.2 交换矩阵在网络中的定位与规格定义

在NoC的语境里，交换矩阵有两个层次的含义，很多人一开始会混。一个是路由器（Router）内部的交换单元，每个路由器有若干个本地输入端口和若干个方向端口，内部的Crossbar负责把这些输入重新分配到输出方向上去；另一个是独立的大交换矩阵，比如集中式的中心交换节点，所有终端都直接连到它上面。前者是分布式的、小规模的，后者是集中式的、规模大的，但内部原理是同一套。

不管哪种形态，落到设计上都是同一组规格在互相拉扯：端口数N、数据位宽DW、单拍吞吐（每拍能搬几个flit）、端到端延迟（拍数）、工作频率、面积。这六个指标没有一个是孤立的。N从4涨到16，交叉点数量从16涨到256，面积是平方级增长；位宽从32涨到128，数据通路的MUX规模线性增长；为了保频率就得插流水线，插了流水线延迟就上去，延迟上去了系统级的性能模型就得重算。

我的经验是，在动手写第一行代码之前，先把这张表填清楚，后面所有取舍都围绕它来做，能省掉大量返工。

需要强调的是，交换矩阵的规格不能脱离整个NoC单独定。你如果只有4个终端，做一个16×16的全连接矩阵纯属浪费；反过来，如果你做的是16核集群，却为了省面积只做部分连接，路由算法就得跟着改，复杂度转移到了别处。这个账要一起算。

1.3 三种排队模型的取舍：为什么主流选择是输入排队加虚通道

交换矩阵内部怎么放缓冲，是第一个必须做决定的事，它直接决定了吞吐上限。教科书上通常给三种模型：输出排队、输入排队、交叉点排队。

输出排队（Output Queued）是最理想的。每个输出端口前面有一个能跑N倍速率的缓冲，任何时刻只要有包到，就能立刻被接收并排队，输出链路的利用率接近100%，吞吐几乎无损耗。但问题在于"能跑N倍速率"这句话——要让缓冲在一个时钟周期内接收N个输入的数据，存储器的写带宽必须是链路的N倍，这在片上是做不起的，功耗和面积都会爆炸。所以OQ基本只存在于理论分析里，用来当性能上界的参照。

输入排队（Input Queued）最省事，每个输入端口前面放一个FIFO，来了包先存着，等到输出空闲再发出去。代价是著名的队头阻塞（Head-of-Line Blocking）。假设端口0的FIFO队头是一个要去端口1的包，但端口1正忙，这个包就只能干等；可它后面明明还排着一个要去端口2的包，端口2此刻完全空闲，却因为队头被堵住而发不出去。有经典分析结论指出，在均匀随机流量下，纯输入排队的交换矩阵吞吐上限大约只有58.6%，规模越大越接近这个数字。也就是说，你花了大价钱做的交叉点阵列，有一半的带宽是浪费的。

交叉点排队（Crosspoint Queued）是折中方案，在每个交叉点放一个小缓冲，只有真正发生冲突时才排队。吞吐能接近OQ，但交叉点数量是N的平方，每个点都放缓冲，面积很快就顶不住了，控制逻辑也复杂。

实际工程里主流的选择是输入排队配合虚拟输出排队（VOQ）或者虚通道（VC）。VOQ的思路很直白：既然队头阻塞是因为不同目的地的包挤在一个队列里，那就按目的地拆开，每个输入端口对每个输出端口各维护一个队列。这样一来，队头堵住的那个队列不影响其他队列，吞吐能回到接近OQ的水平。代价是每个输入端口要维护N个队列，逻辑上的缓冲数量从N变成N的平方，虽然每个队列可以很浅，但控制复杂度上去了。

虚通道则是另一个维度的解法。它在同一条物理链路上划分出多条逻辑通道，每条通道有独立的缓冲和流控，共享物理链路的数据通路。VC最初是为了解决死锁，后来发现对缓解队头阻塞也有帮助。一般来说，VC数量取2到4是比较常见的折中，再多的话，缓冲面积和仲裁复杂度的增长就不划算了。

注意：VOQ和VC经常被混为一谈，但它们解决的不是同一个问题。VOQ解决的是"不同目的地的包互相堵"，VC解决的是"不同流量类别的包互相堵"以及"环路依赖导致的死锁"。有些设计会两者都用，有些只用VC，取决于你的流量模型。

2. 交换矩阵的内部解剖：仲裁、数据通路与流控

2.1 仲裁器：轮询、固定优先级与它们的代价

交换矩阵里最核心的控制逻辑就是仲裁。同一时刻，可能有多个输入端口都想去同一个输出端口，必须选一个出来。这个选择由输出端口上的仲裁器完成。

最简单的做法是固定优先级，端口号小的永远优先。写起来两行代码，但后果很严重：高优先级端口稍微活跃一点，低优先级端口就可能长期拿不到授权，也就是饥饿。除非你的流量模型里各端口的负载严格可控，否则不要用。

更常用的是轮询（Round-Robin）仲裁。它的核心思想是维护一个指针或者掩码，记录上一次服务到哪个端口，下一次从它的下一个端口开始扫描，保证每个端口在长期统计上获得均等的服务机会。轮询的实现方式有好几种，最直观的是掩码法：维护一个N位的mask寄存器，上一次授予端口i之后，把端口0到i全部屏蔽掉，下一次只在剩下的端口里找；如果剩下的端口都没有请求，再放开全部mask从头找。这个写法面积小、逻辑短，是工程上最常见的做法。

还有一种叫矩阵仲裁（Matrix Arbiter），用N乘N的比特矩阵记录两两之间的优先级关系。它的优点是延迟低、决策确定性强，缺点同样是面积按平方增长，N大了不划算，一般只在端口数很少的时候考虑。

还有一种容易被忽略的情况是加权轮询。有些流量本身就有优先级差异，比如控制通路的数据量小但对延迟敏感，数据通路的数据量大但可以容忍延迟。这时候给不同端口配不同的权重，让高优先级端口在一个轮询周期内获得多次服务机会，比单纯的等权轮询更合理。加权轮询的实现通常是在轮询的基础上加一个计数器，达到权重值才把mask推进到下一个端口。

提示：仲裁器的公平性只能靠统计来验证。别指望看代码能看出饥饿问题，老老实实跑几十万个周期的随机流量，统计每个端口获得授权的次数，偏差超过5%就要回头看。

2.2 数据通路：MUX树、与或结构与流水化

仲裁决定了"谁能走"，数据通路负责"把数据搬过去"。这部分看起来只是几个多路选择器，但它在物理实现阶段往往是面积和时序的大头。

最直接的写法是每个输出端口挂一个N选1的MUX，选择信号来自仲裁器的独热授权向量。综合工具会把它展开成MUX树，N选1的延迟大约是log2(N)级。N=4的时候是两级，N=16就是四级，每一级都有延迟，一路串下来，这条路径很容易成为关键路径。

如果时序吃紧，有两个方向可以调。一个是换成与或结构（AND-OR MUX），把多级选择压成一级：每个输入数据和它的选择信号做按位与，所有结果再做按位或。理论上只有一级门延迟，速度快，但门的数量和扇入会变大，面积和功耗都要付出代价。这个取舍要看你的频率目标，如果目标频率不高，MUX树完全够用，没必要为了那零点几纳秒去换面积。

另一个方向是插流水线。在仲裁和数据选择之间插一级寄存器，把"决策"和"执行"拆到两个时钟周期。代价是延迟加一拍，但对频率的提升往往很明显。我在做16端口以上的矩阵时，基本都会默认在仲裁输出后面插一级，因为这个位置的组合逻辑深度实在太容易超标。

还有一个小细节值得提：数据通路上要不要带目的地址一起走。有些设计只搬数据，目的地信息由控制通路单独维护；有些设计让数据flit自带目的地址，交换矩阵直接根据地址做选择。后者的好处是解耦，交换矩阵不需要知道上游的状态；坏处是位宽增加，而且地址位的翻转会带来额外的动态功耗。我的倾向是，如果目的地在每一跳都可能变化（比如源路由），就带着走；如果路由是确定性的，目的地只在进入网络时算一次，那就把它放在旁路信号里，别占用数据位宽。

2.3 流控：credit与ready-valid的取舍

流控解决的是"下游能不能收"的问题。收不了就得反压，反压的方式直接决定了组合逻辑的深度和整个网络的时序收敛难度。

最常见的是ready-valid握手。上游拉高valid表示有数据，下游拉高ready表示能收，两者同时为高的那个时钟沿完成传输。这个机制简单直观，验证也方便。问题在于ready信号是从下游一路组合反压回来的，在交换矩阵里，一个输出端口的ready要经过仲裁器、经过MUX选择逻辑，才能变成某个输入端口的ready。端口数一多，这条反压路径就长得吓人，而且它天然会形成跨模块的组合环，时序分析的时候非常难受。

另一种是信用（credit）流控。下游维护一个缓冲，每消费一个flit就还一个credit给上游，上游维护一个credit计数器，只有计数大于零才能发。这个机制把反压从组合路径变成了计数器的加减，路径短、时序友好，代价是需要准确计算缓冲深度，算少了会损失带宽，算多了浪费面积。credit流控还有一个隐性好处：它是单向的，上游不需要等下游的组合信号，整个网络的组合环被打断，对后端布局布线非常友好。

大规模NoC里，credit基本是默认选择。但要注意，credit流控本身不解决死锁，它只是把反压变成单向的，如果缓冲环形成了循环依赖，credit照样会全部耗尽然后卡死。这一点在后面讲死锁的时候还会提到。

2.4 虚通道：不是为了快，是为了不堵死

很多人第一次接触虚通道，会觉得它是用来提升带宽的。其实它的第一价值是打破死锁，第二价值才是缓解队头阻塞。

死锁的典型场景是这样的：路由采用维序路由，但网络里存在环形拓扑，或者虽然拓扑是无环的，但流量模式造成了逻辑上的环。每个路由器都在等下一跳的缓冲空出来，而下一跳又在等再下一跳，最后绕一圈回到自己，谁都动不了。虚通道的思路是把一条物理链路拆成多条逻辑通道，每条通道独立分配缓冲，路由的资源依赖图从"物理链路"粒度细化到"虚通道"粒度，环就被打断了。

虚通道开几个合适？常见的取值是2到4。开2个能解决大部分两级依赖的死锁，开4个能覆盖更复杂的场景。再往上，每个VC都要独立做缓冲、独立做仲裁、独立做分配，面积和复杂度的增长很难用性能收益来justify。我见过有设计开8个VC，最后面积里有一大半是缓冲，实际吞吐提升不到15%，性价比很低。

虚通道带来的一个副作用是仲裁变成了两级：先做虚通道分配（VA），决定哪个输入VC能连到哪个输出VC，再做交换分配（SA），决定哪个连接能真正占用交叉点。这两级仲裁可以串行做，也可以并行做。串行做简单但延迟高，并行做需要更复杂的匹配逻辑（比如用轮询迭代匹配），面积和延迟之间又是一次取舍。

3. 手写一个参数化4x4交换矩阵

理论说得差不多了，接下来落到代码上。我选4x4、64位数据、2位目的地址作为例子，这个规模刚好能看清所有细节，又不至于被海量的重复代码淹没。你可以按同样的结构直接扩展到8x8或者16x16，主要的变化在参数和流水线上。

3.1 接口与参数规划

接口设计的第一原则是扁平化。Verilog-2001不支持数组端口，所以输入输出都用打包的向量表示，每个端口占一段。这样例化的时候也方便用generate批量连。

module noc_xbar #( parameter N = 4, // 端口数 parameter DW = 64, // 数据位宽 parameter AW = 2 // 目的地址位宽, 需满足 2**AW >= N )( input wire clk, input wire rst_n, // 输入侧 input wire [N*DW-1:0] in_data, // 每 DW 位一个端口 input wire [N*AW-1:0] in_dest, // 每 AW 位一个端口 input wire [N-1:0] in_valid, output wire [N-1:0] in_ready, // 输出侧 output wire [N*DW-1:0] out_data, output wire [N*AW-1:0] out_dest, output wire [N-1:0] out_valid, input wire [N-1:0] out_ready );

目的地址位宽AW要满足2的AW次方不小于N，4端口就是2位。这个约束最好在模块里用generate或者initial加断言检查一下，省得后面改参数的时候忘掉。

这里我采用的是组合输出加下游ready反压的结构，也就是输出端口直接驱动数据，由out_ready决定能不能收。这个写法简单，但正如前面说的，反压路径长。实际项目中我会在输出端插一级skid buffer或者FIFO，把反压路径切断。为了先看清主干逻辑，这里保持最简形态。

3.2 轮询仲裁器的可综合写法

仲裁器是整个设计里最需要小心的地方。下面这个版本用掩码法实现轮询，综合出来的面积很小，逻辑深度也浅。

module rr_arb #( parameter N = 4 )( input wire clk, input wire rst_n, input wire [N-1:0] req, // 请求向量 input wire upd, // 本拍握手成功, 推进掩码 output wire [N-1:0] gnt // 独热授权 ); reg [N-1:0] mask; // 上一次服务过的端口及其低位全部屏蔽 wire [N-1:0] req_masked = req & mask; // 屏蔽后还有请求就用屏蔽结果, 否则放开全部重新扫 wire [N-1:0] picked = (|req_masked) ? req_masked : req; // 取最低位的 1: picked & (-picked) wire [N-1:0] gnt_nxt = picked & (~picked + 1'b1); always @(posedge clk or negedge rst_n) begin if (!rst_n) mask <= {N{1'b1}}; else if (upd) mask <= ~(gnt_nxt | (gnt_nxt - 1'b1)); end assign gnt = gnt_nxt; endmodule

这段代码里有几个点值得掰开说。第一，picked & (~picked + 1'b1)是取最低位1的标准写法，综合工具能识别成优先级编码器，结果是一个独热向量。第二，mask的更新逻辑~(gnt_nxt | (gnt_nxt - 1'b1))的含义是：如果这次授予了端口i，那么端口0到i全部屏蔽，下一轮从i+1开始扫。第三，当屏蔽后没有任何请求时，picked回退到原始请求，保证不会因为mask把有效请求漏掉。

这个写法有个前提，就是N最好是2的幂。不是2的幂的时候，减法借位会产生一些边角情况，虽然逻辑上仍然正确，但综合出来的电路会多一些冗余。如果你确实需要非2的幂的端口数，建议向上取整到2的幂，把多余端口固定接0。

还有一点，upd信号一定要接真实的握手完成信号，而不是简单的valid。如果接错了，mask会在没有真正传输的情况下推进，导致某些端口被跳过一次服务机会，公平性就被破坏了。

3.3 交叉开关数据通路

数据通路的主体是一组generate循环，每个输出端口一个MUX，选择信号来自对应输出仲裁器的授权向量。

wire [N-1:0] req [0:N-1]; // req[o][i]: 输入i请求输出o wire [N-1:0] gnt [0:N-1]; // gnt[o][i]: 输出o授权给输入i genvar gi, go; generate for (go = 0; go < N; go = go + 1) begin : g_arb for (gi = 0; gi < N; gi = gi + 1) begin : g_req assign req[go][gi] = in_valid[gi] & (in_dest[gi*AW +: AW] == go) & out_ready[go]; end rr_arb #(.N(N)) u_arb ( .clk (clk), .rst_n (rst_n), .req (req[go]), .upd (|gnt[go]), .gnt (gnt[go]) ); end endgenerate

请求的生成条件是三个：上游有有效数据、目的地址指向本输出端口、下游能接收。三个条件同时成立才算真请求，这样仲裁器拿到的永远是可以立即执行的请求，不会出现"授权了但走不了"的情况。

数据选择部分用one-hot选择加循环赋值，这是可综合的写法，综合工具会展开成MUX树：

generate for (go = 0; go < N; go = go + 1) begin : g_out reg [DW-1:0] dat_mux; reg [AW-1:0] dst_mux; integer k; always @(*) begin dat_mux = {DW{1'b0}}; dst_mux = {AW{1'b0}}; for (k = 0; k < N; k = k + 1) begin if (gnt[go][k]) begin dat_mux = in_data[k*DW +: DW]; dst_mux = in_dest[k*AW +: AW]; end end end assign out_data[go*DW +: DW] = dat_mux; assign out_dest[go*AW +: AW] = dst_mux; assign out_valid[go] = |gnt[go]; end endgenerate // 输入侧的ready: 只要该输入在任一输出上拿到授权即可 generate for (gi = 0; gi < N; gi = gi + 1) begin : g_rdy wire [N-1:0] rdy_vec; for (go = 0; go < N; go = go + 1) begin : g_rdy_o assign rdy_vec[go] = gnt[go][gi]; end assign in_ready[gi] = |rdy_vec; end endgenerate

这套结构在N=4、DW=64的情况下，综合出来的面积在几千门量级，关键路径是valid进入仲裁器、仲裁结果进MUX、MUX出数据，中间大概三四级逻辑。如果要跑更高的频率，就在gnt和MUX之间插一级寄存器，代价是延迟加一拍。

3.4 输出FIFO与credit反压

前面这个版本是组合输出，一旦下游不收，整条链路的ready会立刻反压回去。工程上我一般会在输出端加一个深度为4到8的FIFO，把反压切断。FIFO本身的实现很标准，这里只强调credit计数的部分。

module credit_ctrl #( parameter CW = 4 // 信用计数器位宽, 最大信用数 2**CW-1 )( input wire clk, input wire rst_n, input wire tx_en, // 本拍发出一个flit input wire credit_ret, // 下游返还一个credit output wire credit_ok // 计数器非零, 可以发 ); reg [CW-1:0] cnt; always @(posedge clk or negedge rst_n) begin if (!rst_n) cnt <= 4'd8; // 初始信用数等于缓冲深度 else begin case ({tx_en, credit_ret}) 2'b10: cnt <= cnt - 1'b1; 2'b01: cnt <= cnt + 1'b1; default: cnt <= cnt; endcase end end assign credit_ok = (cnt != 0); endmodule

初值必须等于下游缓冲的实际深度，这个数字要和FIFO例化时传的参数严格一致。我见过不止一次因为初值写死成8、而FIFO实际深度改成了4，导致credit虚高、缓冲溢出、数据丢失的事故。这种bug在仿真里往往要跑很久才能暴露，因为只有在长时间满负荷时才溢出。稳妥的做法是把FIFO深度定义成parameter，初值直接用这个parameter，让工具保证一致。

3.5 顶层连线与仿真验证

把仲裁、数据通路、FIFO拼起来之后，验证的重点不是"功能对不对"，而是"极端情况下会不会挂"。我通常分三层来测。

第一层是定向测试，手动构造几组典型的冲突场景：两个输入同时打一个输出、四个输入同时打四个输出、某个输入连续多拍只打一个输出。这一层主要是看握手信号的行为是否符合预期，尤其是ready和valid的组合关系。

第二层是随机流量，用uniform分布让每个输入随机选择目的端口，跑个十万拍，统计每个输出端口的利用率。均匀流量下，4x4矩阵的每个输出端口利用率理论上应该接近100%减去冲突损失。如果某个端口的利用率明显偏低，说明仲裁有问题。

第三层是极端流量，包括热点模式（所有输入都打同一个输出）和置换模式（输入i打输出i+1，形成循环）。热点模式考验仲裁的公平性，置换模式考验死锁。这两种模式是最容易暴露问题的，我在每个项目里都会固定跑。

验证的时候要埋的检查点也很关键，至少要有：同一拍内一个输出端口只能输出一个flit、不能出现valid为高但数据是X的情况、每个输入端口的数据不能重复发送也不能丢失。做端到端的比对时，在源端打上序号，在目的端检查序号连续且唯一，这是最基本也最有效的手段。

4. 时序、面积与功耗：上综合工具前的六个现实约束

4.1 关键路径到底在哪

交换矩阵的关键路径有两条，很多人只盯着其中一条。

第一条是前向路径：in_valid 进入请求生成逻辑，到仲裁器出结果，到MUX选择信号，到数据出来。这条路径的长度和N强相关。N=4的时候，请求生成是一级与门，仲裁是优先级编码加掩码更新（组合部分大约两级），MUX是两级，加起来五六级，还行。N=16的时候，优先级编码器本身就要好几级，MUX是四级，叠加起来很容易超过目标频率允许的逻辑深度。

第二条是反向路径：out_ready 反压回来，经过请求生成、仲裁，变成 in_ready。这条路径经常被忽略，因为它在功能仿真里看不出任何问题，但它同样是组合逻辑，同样要吃时序。而且由于它跨越了从输出到输入的方向，在物理布局上往往是长线，延迟比前向路径还大。

我的处理方式是，前向路径用插寄存器解决，反向路径用FIFO切断。只要输出端有FIFO，out_ready就只影响FIFO的读，不会直接穿透到输入端，反向路径自然就短了。这也是为什么我强烈建议输出端必须加缓冲，哪怕深度只有2。

4.2 面积怎么估：缓冲才是大头

很多人在做面积预算的时候，习惯性地去数交叉点。4x4是16个交叉点，每个交叉点一个64位4选1 MUX，用2:1 MUX来算是3乘64等于192个，16个交叉点就是3072个2:1 MUX，按每个2到3个等效门算，大约六千到九千门。这个数字看起来不大。

但真正吃面积的是缓冲。4个输出端口，每个深度8，位宽64，光触发器就是4乘8乘64等于2048个，折算成等效门大约一万二到一万六千门，直接超过了交叉点本身。如果每个端口再配上虚通道，VC数量乘以2，缓冲面积再翻一倍。所以做面积预算的时候，顺序应该是先算缓冲，再算交叉点，最后算仲裁和控制逻辑。很多人反过来算，最后发现总面积超了一大截，就是因为漏掉了缓冲。

这也解释了一个现象：为什么很多NoC设计在端口数和位宽上斤斤计较，却在缓冲深度上一再压缩。压缩缓冲深度确实能省面积，但代价是credit容易耗尽、带宽下降。这个平衡点要靠流量模型来定，不能拍脑袋。

4.3 功耗与翻转率

交换矩阵的动态功耗主要来自三块：时钟树、数据通路的翻转、仲裁逻辑的翻转。

数据通路的翻转是大头，因为位宽大。一个64位的MUX，每个周期都可能有几十位在翻转。降低这部分功耗的手段有几个：一是数据门控，没有传输的时候把MUX的输入屏蔽掉，避免无效翻转；二是操作数隔离，在MUX前面加与门，选择信号无效时把数据清零，虽然多了一级门，但能显著降低后级的翻转率；三是把不常用的宽通路拆成窄通路，按需启用。

仲裁逻辑的翻转量小，但它的翻转会传播到MUX的选择信号上，间接影响数据通路。所以仲裁结果最好做一次寄存，既解决时序，又让选择信号在一个周期内稳定，减少毛刺带来的额外翻转。

还有一点容易被忽略：目的地址的比较逻辑。每个输入端口的目的地址要和所有输出端口编号逐一比较，N个输入乘N个输出就是N平方个比较器。这些比较器的翻转率取决于地址的变化频率，如果地址高位长期不变，可以用位宽更窄的比较或者分段比较来省功耗。

4.4 FIFO深度的定量计算

这是最常被问的问题：FIFO到底挖多深。答案不是拍脑袋，是可以算的。

以credit流控为例，FIFO的最小深度等于链路的往返延迟，单位是flit。往返延迟包括三段：数据从上游发到下游写入FIFO的时间、下游消费后返还credit的时间、credit更新到上游计数器的时间。假设每一段都是一个时钟周期，那么往返延迟就是3个周期，FIFO深度至少要3，才能保证在credit回来的这段时间里上游不会因为没信用而停摆。

但这只是理论下限。实际还要考虑几个因素：如果上下游时钟频率不同，要按比例换算；如果链路中间有寄存器切片，每切一片就加一个周期；如果下游的消费速率不稳定（比如被更下游反压），还要留出余量。工程上我通常的做法是理论值加2，也就是往返延迟加2，作为默认深度，然后再根据仿真里的停摆统计来微调。

举个具体例子。假设链路没有切片，上下游同频，下游消费一个flit后立即返还credit，那么往返是2个周期（去1拍，回1拍），理论深度2，实际取4。如果中间插了一级流水寄存器，往返变3，理论深度3，实际取5。如果下游还有一级FIFO，消费不是即时的，再留2的余量。

注意：FIFO深度不是越深越好。深度增加会线性增加面积，而且会掩盖上游的拥塞信号，让拥塞传播变慢，网络级的死锁检测和恢复变得更困难。深度够用就行。

5. 常见问题与排查实录

5.1 死锁的三种成因与对应的解法

死锁是NoC里最让人头疼的问题，因为它在功能仿真里可能几十万拍都不出现，一旦出现就是整个网络卡死，日志里什么都看不出来。按成因分，死锁有三类。

第一类是路由死锁。典型场景是环形拓扑配合非自适应路由，包在环上绕，每个节点都在等下一跳的缓冲，绕一圈形成依赖环。解法是路由算法层面禁止某些转向（比如维序路由禁止从X方向转到Y方向再转回X），或者引入逃逸虚通道，让一个包能跳出环。

第二类是缓冲死锁，也叫资源死锁。它和拓扑无关，纯粹是资源分配顺序不当造成的。比如每个路由器只有一个缓冲，两个相邻的路由器互相要向对方发数据，各自的缓冲都满了，谁都发不出去。解法是保证资源分配的有向无环，通常靠虚通道实现，让请求和响应走不同的VC。

第三类是协议死锁。这在带请求-应答机制的NoC里很常见。请求包占满了所有缓冲，应答包没有地方走，而请求包又必须等到应答才能释放缓冲，形成环。解法是给请求和应答分配独立的虚通道，物理上隔离两条路径。

排查死锁的手段，最有效的是超时检测。在仿真里给每个包加一个时间戳，超过预定周期还没到达目的端就报错，同时打印出当前所有路由器的缓冲占用状态。有了这份快照，环在哪里一目了然。比起盯着波形一行行看，这个方法效率高太多。

5.2 吞吐上不去的典型原因

仿真跑通了，延迟也正常，但吞吐只有理论值的一半，这种问题也很常见。按我踩过的坑排序，原因大概有这么几个。

排第一的是队头阻塞没解决。如果你用的是纯输入排队，每个输入端口只有一个FIFO，没有按目的地拆队列，那么吞吐上限就是58.6%，怎么调都上不去。这个问题的解法前面说过，VOQ或者VC，没有别的路。

排第二的是credit深度不足。credit耗尽的直接后果是上游明明有数据、下游明明有空位，但就是发不出去。判断方法是统计credit计数器的零值占比，如果长期在零附近徘徊，说明深度不够。这种情况在突发流量下特别明显，均匀流量反而看不出来。

排第三的是仲裁不公平。某个端口长期抢不到授权，它的上游就一直堵着，整体吞吐自然上不去。判断方法是统计各端口的授权次数分布，偏差大的话就要检查仲裁器。

排第四的是路由热点。所有流量都往一个区域集中，那个区域的路由器成为瓶颈，其他部分再空也没用。这是拓扑和路由算法的问题，交换矩阵本身没法解决，但可以通过在矩阵里加优先级来缓解——给热点区域的流量更高的优先级，至少能保证关键流量不被饿死。

5.3 功能仿真里最容易漏掉的坑

第一个坑是复位。交换矩阵里的状态寄存器不少：仲裁器的mask、credit计数器、FIFO的读写指针。任何一个没复位干净，仿真前半段可能正常，跑到某个特定序列才出错。我习惯的做法是给所有状态寄存器一个明确的复位值，并且在测试里加一个复位中途拉低的场景，验证复位后的行为是否可恢复。

第二个坑是X态传播。数据通路上有MUX，如果选择信号是X，输出就是X，然后X会顺着链路一路传下去，最后在目的端比对的时候才发现。定位起来很麻烦，因为X可能是在很多拍之前产生的。解决办法是在MUX的输出加X检查，一旦出现就立即报错并打印当时的grant向量，把问题锁定在当前拍。

第三个坑是边界条件。比如同时有多个输入打到同一个输出、某个输入的目的地址超出范围、out_ready在valid为高的同一拍拉低。这些场景在随机测试里出现的概率不高，要专门写定向用例覆盖。特别是那个out_ready和valid同拍拉低的场景，握手协议里这是合法的，但如果你的实现里假设了ready不会在传输当拍变化，就会出错。

5.4 问题速查表

把上面这些整理成一张表，方便你调试的时候对着看。

这张表不能覆盖所有情况，但能挡掉八成常见问题。真正难搞的往往是几个因素叠加在一起，比如队头阻塞加credit不足加仲裁不公平，三个问题同时存在，表现出的现象和单独任何一个都不一样。这时候就要一个一个关掉，先解决最明显的，再逐步深入。

最后分享一个我在实际项目里养成的小习惯：交换矩阵的每个关键信号都留一个可配置的调试输出端口，把仲裁状态、credit计数、FIFO水位打包成一个向量引出来，正常模式下综合掉，调试模式下接到片上逻辑分析仪上。这个习惯在定位那些"仿真复现不了、只在特定场景出现"的问题时，价值巨大。多花的那点面积，比事后靠猜要划算得多。