2.3 片上互连与数据流：从总线到片上网络

2.3 片上互连与数据流：从总线到片上网络

计算单元与存储层次都定了，本节把两者接起来：互连是三大件里唯一"自己不产生价值、却决定别人能不能产生价值"的一层。它同时承接了原"数据流与控制流"设计的职责——数据怎么走是拓扑问题，谁先走是仲裁问题，两者在互连里是一体的。读完本节，你应当能给一颗 SoC 做一次带宽预算，并在预算超支时知道先动哪根杠杆。

所有路都汇进的十字路口

从最朴素的模型说起。互连要解决的事情只有一件：让任意主设备（核、加速器、直接访存引擎）能对任意从设备（存储控制器、外设寄存器）发起读写，且多路请求同时到达时有条不紊。现代总线的答案是把它拆成两条单向通道——读地址与写地址各走各的，数据与应答也有独立通道，地址发出后不必干等，通道分开让请求流水起来，这是片上总线效率的根基。

一次读事务的完整生命周期值得背下来：主设备在地址通道发出"我要从某处读多长"；互连里的仲裁器判断此刻总线归属，把请求转发给从设备；从设备取数后经读数据通道返回，附带应答标记表示成功还是出错。写事务类似，多一步"先发数据再等应答"。事务化意味着总线上的单位不是"连线电平"而是"有身份的请求"，这正是 1.1 节边界判定第二问"结构化互连"的含义。

仲裁是十字路口的红绿灯。多主设备抢同一从设备时，仲裁器按策略放行：固定优先级简单但会饿死低优先级；轮转公平但不懂业务轻重。成熟的互连在两者之间提供服务质量配置——给"不能等"的流量发保障通行证（预留带宽），给"慢点无妨"的流量设上限（防止挤占），余下的按轮转分。这段定义请记住，本节案例会把它用上。

图：CK770 互连拓扑与带宽预算标注

带宽预算：架构师的三栏账本

带宽预算的做法与 2.2 节容量估算同门：按流量逐条记账，而不是拍一个总数。三个要素缺一不可：每条流量的峰值速率（数据宽度乘以频率，再考虑突发效率打折）、它的服务等级（保障、优先、限制三档）、以及叠加校验（所有进存储控制器的流量加总，不得超过介质有效带宽的八成左右——满打满算必翻车，突发永远比理想模式差）。

预算表要演两个场景：全速运行（各流量同时到峰值的概率不高，但要验证热点组合）与最坏组合（采集满载加推理全速同时跑）。CK770 的首次预算恰好在最坏组合上漏了算：加速器的权重重载与推理结果回写撞上采集写入高峰，叠加流量把介质带宽顶穿，采集流的保障形同虚设。这个漏洞是怎么发现又怎么堵上的，见下面的案例复盘。

案例复盘：CK770 的首次带宽超支

背景：架构冻结前的最后一轮评审，性能仿真组按预算表做了全负载联合仿真，报告里一条曲线异常——采集流的写延迟在推理启动后的几十毫秒里翻了数倍，超过实时承诺。此时 RTL 尚未完成，问题还停留在纸面上，这正是架构阶段做预算的意义所在。

操作。 团队先定位肇事流：逐条关闭重放，确认是加速器的批量搬运在推理启动瞬间以最高优先级涌入，挤掉了采集流的保障窗口。随后开出三联处方：其一，给加速器流量设速率上限，从"不限速的保障"改成"限速的尽力而为"；其二，把推理任务的重载阶段与采集高峰错相——固件调度上让权重重载避开采集窗口，这属于数据流设计里的时间维治理；其三，把采集写入改成分段缓冲，用 2.2 节的紧耦合存储吸收瞬时峰值，等总线空闲再成批刷入片外。

结果。 复测全负载场景：采集流写延迟回到承诺值以内，推理吞吐下降约一成，推理本身是分钟到秒级任务，这一成毫发无伤。预算表更新为三档明确的服务等级，并把"最坏组合联合仿真"写进架构验收清单，成为后续每个改版的固定动作。

解读。 这单案例浓缩了互连设计的一条元规则：带宽问题的本质是调度问题，调度的本质是业务分层。三层处方分别对应三个治理维度——限制流量的量（速率上限）、错开流量的时（调度错相）、吸收流量的峰（缓冲削谷）。多数带宽问题不用换拓扑就能解决，杠杆顺序应当是先调这三样，再考虑动结构。另一个教训是预算表必须配联合仿真：纸面叠加按理想效率计算，永远偏乐观，仿真才会暴露"撞车时刻"。

变式。 若主设备数量再增——加显示控制器、加多路摄像头接口——矩阵的十字路口会变成拥塞常发路段，那时该讨论的才是拓扑升级：从共享矩阵走向带路由的片上网络，用局部化通信换取全局可扩展。判断的信号很朴素：当互连面积占比、仲裁延迟、布线拥塞三者中任何一项在物理设计阶段亮红灯（第六章会讲怎么读这些灯），就该重新审视拓扑了。

仲裁之外，互连里还藏着两样不起眼却处处收费的"翻译"：位宽转换与时钟域转换。宽窄两侧对接要拆包合包，快慢两侧对接要先进先出缓冲——两者都消耗面积、延迟与验证注意力，而且往往在架构图上根本不出现。有经验的做法是把翻译点集中规划：位宽尽量统一到少数几档、跨域收拢到固定几处，让翻译的账单集中可见，而不是散落在几十个接口上各自为政。

常见问题辨析

问：拓宽位宽和提高频率，预算表上怎么选？

两者都加带宽，但副作用谱不同。宽位宽加的是每拍搬运量，代价是互连面积与布线拥塞（线多了要地方走）；提频率加的是每秒拍数，代价是时序收敛压力沿整条路径传导，6.2 节的违例风险随之上升。经验次序是先把位宽配到自然对齐（与主设备突发长度匹配），频率只提到位宽与频率组合的最省力点——单项孤注都会在下游某一章收到账单。

问：总线事务失败了谁来重试？

责任分两层。互连层的重试：从设备忙时给主设备回"请稍后再来"的应答，主设备负责重新排队发起，这类重试对软件透明。协议层的重试：数据完整性出错（伴随校验的链路）时，由链路两端的纠错与重传机制处理。软件唯一要负责的是幂等性设计——凡是"可能被重复执行"的操作（写外设命令寄存器），语义要设计成重复执行无害，否则一次透明重试就是一次事故。

问：片上网络成熟了，传统总线还有存在价值吗？

有，而且仍是多数项目的正确起点。片上网络的强项是多主多从规模下的可扩展性与全局拥塞管理，它的代价是每跳路由的面积与延迟——主从数量少、拓扑简单的芯片上，这些开销纯属白付。判断信号在 2.3 节说过：互连面积占比、仲裁延迟、布线拥塞三盏灯。没亮灯之前，矩阵总线加服务质量就是性价比最高的答案；亮了灯，再谈拓扑升级。

问：为什么突发传输的效率远高于一笔一笔单发？

因为每次事务都有固定开销——地址发出、仲裁裁决、应答返回，这些"公务环节"不搬数据。突发传输把一笔公务摊到多拍数据上：地址报一次起点与长度，数据成串流水通过，开销被稀释到近乎可见。这也是预算表里"突发效率打折"一栏的由来：理论上限按满拍算，现实要考虑突发的起止、与别的流量交错、以及地址不连续时的重新发起。工程纪律是对齐——把缓冲区按突发长度对齐、让大块搬运保持地址连续，效率就贴近上限；反之，零散小事务会让互连忙于公务、疏于搬货。

本节要点回顾

• 事务是互连的基本单位：地址、数据、应答分通道流水，这是结构化互连与"零件堆放"的分水岭。
• 仲裁从固定优先级、轮转进化到服务质量三档：保障给实时、上限给批量、轮转给其余。
• 带宽预算是逐条记账加最坏组合校验，介质有效带宽只能按八成规划。
• 带宽治理的三根杠杆依次是限流量、错时间、缓冲峰，拓扑升级是最后的手段。

三大件到此齐备，图纸可以送审了。下一章回答"模块从哪来"：哪些功能买现成的 IP 核，哪些必须自己动手——台账进入选料阶段。