芯片NoC为何算够还拥堵？一致性风暴怎么驯服？

芯片互连最容易误判的地方，在于平均带宽看起来总是够，真正出事的是局部阻塞被放大成全局掉速。NoC拥堵如果只按吞吐均值评估，热点业务一来就会把整片系统拖慢。

NoC反压传播的杀伤力，在于一个出口堵住后，阻塞会沿着共享缓冲和信用回传路径一跳一跳往回传。很多片上网络采用虫洞或基于信用的流控，单个报文头部如果在目标端口等待，后面的flit虽然已经穿过多个路由器，却不能自由释放通道。于是本来看似局部的冲突，会迅速占住上游缓冲，连原本去往其他目的地的报文也被一起拖住。平均带宽计算无法看见这种链式阻塞，因为它默认流量可以平滑摊开，真实芯片里的访存突发、DMA聚集和共享LLC热点访问却会把队列瞬时堆到极高。若虚通道配置过少，或QoS优先级设计只保证峰值吞吐不保证阻塞隔离，最先掉下来的往往不是最重流的业务，而是依赖低延迟的小报文控制流。很多SoC满载时看似“所有模块都慢了一点”，根因其实是某几个热点端口把反压一路传回主干，整个网络被迫一起踩刹车。因此互连仿真必须保留突发流量和队列时序，若只把事务平均到长时间窗口，反压链条会被数学平均值直接抹掉。真正决定体验的，往往是那几个短时拥塞峰。

一致性回写风暴会在多核和加速器共享内存的场景里进一步放大这种阻塞。缓存一致性协议本来是为了保证视图正确，但当多个主设备围绕同一批缓存线反复读改写，失效通知、探测响应、脏数据回写和目录更新会在短时间内叠出成倍控制流量。尤其是伪共享严重、写热点集中或目录放置不均时，真正占满网络的未必是业务数据，而是为维护一致性而产生的附加消息。若架构评估只用纯读写带宽模型，不把协议流量单独记账，就会高估可用带宽。工程上常用的优化不是一味加宽链路，而是从源头减少风暴：调整缓存线粒度、减少跨核写共享、给目录和回写通道留出独立缓冲，必要时让部分加速器走软件管理一致性。协议正确不等于系统高效，一致性若没有按最坏共享模式验证，NoC算得再宽也可能在真实工作负载下先被控制流量淹没。软件层若继续制造细粒度写共享，即便硬件协议本身无错，也会把目录和回写缓存长期顶在高占用区，形成看不见的网络税。系统掉速时，最先被怀疑的常常还是错误的模块。因此NoC调优最后看的是最坏时延尾巴，而不是平均吞吐曲线。互连一旦进入尾时延主导区，平均带宽再好看也撑不起真实性能。

片上网络怕的不是均值不够，而是局部阻塞和协议流量同时放大。把反压路径和一致性消息分开建模，互连带宽预算才不会停留在纸面上。