2. 片上互联网络基础：互联拓扑结构、路由算法与流控机制
各位同学，今天我们来聊聊片上互联网络。说白了，就是芯片内部各个核心之间怎么「说话」、怎么「传东西」。我做了这么多年芯片，发现很多同学把精力都放在单核性能上，结果多核一跑起来，瓶颈全在互联上。嗯，这章咱们就把这个坑填上。
2.1 互联拓扑结构：选对路子，事半功倍
拓扑结构，就是核心之间怎么连。我见过不少项目，拓扑选错了，后面怎么优化都救不回来。常见的拓扑有四种：总线、环形、网格、交叉开关。咱们一个一个说。
2.1.1 总线（Bus）
总线是最简单的结构。所有核心挂在一根线上，谁想说话，先抢总线使用权。
- 优点：实现简单，面积小，适合少量核心（2-4个）。
- 缺点：一旦核心多了，总线就成了瓶颈。你想想看，8个核心同时要发数据，总线只能一个一个来，排队排到天荒地老。
2.1.2 环形（Ring）
环形拓扑，核心首尾相连，形成一个环。数据在环上单向或双向传输。
- 优点：比总线扩展性好，布线简单。
- 缺点：最坏情况下，数据要绕整个环才能到达目标，延迟不可控。
我个人习惯，在8-16核的场景下优先考虑环形。它不像总线那么脆弱，又比网格简单。
2.1.3 网格（Mesh）
网格是二维的。核心排成矩阵，每个核心只和上下左右四个邻居相连。
- 优点：扩展性极好，适合大规模多核（16核以上）。
- 缺点：跳数多，延迟随距离增加。而且边缘核心的带宽利用率低。
2.1.4 交叉开关（Crossbar）
交叉开关，就是每个核心都能直接连到其他核心。像一个电话总机。
- 优点：延迟低，带宽高，任意两个核心可以同时通信。
- 缺点：面积和功耗随核心数平方增长。8核还能忍，16核以上基本别想。
交叉开关适合对延迟极度敏感的场景，比如缓存一致性协议中的目录控制器。我建议只在关键路径上用，别铺开。
2.2 路由算法基础：数据怎么走？
拓扑定了，数据怎么从A到B？这就是路由算法的事。说白了，就是「选路」。我见过不少同学，拓扑画得漂亮，路由算法一塌糊涂，结果数据包在芯片里绕圈圈。
2.2.1 确定性路由
最简单的路由。从A到B的路径是固定的，比如「先X方向，再Y方向」（维序路由）。
- 优点：实现简单，无死锁。
- 缺点：不能绕开拥塞点。如果某条路堵了，数据包只能硬等。
嗯，这里要注意：确定性路由虽然简单，但在负载不均时性能很差。我建议在流量模式已知的场景下使用。
2.2.2 自适应路由
自适应路由会根据当前网络状态动态选路。比如，发现某条路堵了，就绕一下。
- 优点：能应对负载变化，利用率高。
- 缺点：实现复杂，可能引入死锁或活锁。
2.2.3 死锁与活锁
死锁：两个数据包互相等对方让路，结果谁都不让。活锁：数据包一直在绕圈，永远到不了。
怎么避免？我个人的经验是：
- 用维序路由，保证路径无环。
- 或者用虚拟通道（Virtual Channel），打破循环等待。
2.3 流控机制：别让数据堵在路上
路由算法决定了数据走哪条路，流控机制决定了数据什么时候走。说白了，就是「管流量」的。
2.3.1 基于信用的流控（Credit-Based）
每个接收端告诉发送端：「我还有N个缓冲空间」。发送端根据这个信息决定发不发。
- 优点：不会丢包，不会溢出。
- 缺点：需要额外的信用线，延迟敏感。
我建议在延迟敏感的场景下用信用流控。比如缓存一致性协议中的请求-响应路径。
2.3.2 基于握手的流控（Handshake）
发送端发一个请求，接收端回一个确认。确认了才能发下一个。
- 优点：实现简单，不需要信用线。
- 缺点：效率低，每发一个包都要等确认。
嗯，握手流控适合低频场景。高频场景下，握手延迟会严重拖慢性能。
2.3.3 虚拟通道（Virtual Channel）
虚拟通道，就是把一条物理通道分成多条逻辑通道。每个逻辑通道有自己的缓冲和流控。
- 优点：能避免头阻塞（Head-of-Line Blocking），提高利用率。
- 缺点：面积和复杂度增加。
2.4 知识体系总览
下面这张图，是我自己总结的片上互联网络知识体系。你可以把它当作一个「地图」，学完这章后，对照着看看自己掌握了多少。
这张图把三大模块的关系讲清楚了。拓扑结构决定了「路怎么修」，路由算法决定了「车怎么走」，流控机制决定了「什么时候发车」。三者缺一不可。
2.5 小结
这一章我们聊了片上互联网络的三个核心：拓扑结构、路由算法、流控机制。我个人觉得，拓扑是基础，路由是灵魂，流控是保障。选对了拓扑，后面的事就好办多了。
嗯，最后提醒一句：别光看书，多动手仿真。我当年就是在仿真里踩了无数坑，才真正理解这些概念的。你们也试试看。
公众号:蓝海资料掘金营，微信deep3321