【片上网络专题讨论一】 片上总线的发展历程

闲言稍叙

我在研二的2023年10月开始接触片上网络，中间也学习过一段时间超标量CPU设计，也算都是相关的课题。随着研究生毕业，也许以后不一定能再用到这块的知识，就想着趁着最近有时间，把这块的知识整理整理输出到社区，发挥一点余热也好过留在我的脑子里，在岁月的橱柜中逐渐吃灰。相比于写学位论文所要求的格式完美、结果丰满，我可能更喜欢写博客，因为可以更加充分和完整地表述在研究过程中经历的种种思考，而不是只是给出一个完美的答案。我希望用相对口语化的表述来讲清楚我理解的片上总线以及片上网络，并无偿分享所做的片上网络仿真器设计以及电路设计，因此这个系列会带有比较多的个人观点，可能有许多未必正确，有兴趣的朋友点个关注不迷路。

片上总线的发展

随着芯片上晶体管数量的变多，对于连接片上各模块的总线要求也在提高。高带宽、高可靠、低延迟、可扩展、低功耗是片上总线关心的重点指标。

首先出现的总线应当是点到点互联，也就是将需要通信的模块直接连起来，比如CPU和内存之间用一个512bits的总线连接。从芯片后端物理实现的角度来说，总线的本质是金属，可以传导信号。但是点到点互联的问题是，在不进行数据传输的时候，显然总线带宽是被浪费了。

为了更充分地利用总线，就出现了共享总线。将所有IP核接入到共享总线下，共享总线在同一时间只能被一对主从设备使用（这里的设备和IP核意思一样，后面不再区分），其他设备需要通信则必须要等待总线仲裁获胜并授权。从底层电路角度来说，共享总线的组成部分首先是金属互连线本身，然后还有仲裁电路以及译码电路。仲裁电路用来对申请通信的设备按照一定的算法来授权，译码电路则是用来判断读写请求的地址，并发送到对应的设备。

共享总线的问题是随着接入设备的变多，显然会出现因为仲裁失败而导致的时延问题，优先级比较低的设备可能有饥饿现象。有人可能会说，那你只要频率够高，位宽够大，那就可以很快轮到低优先级设备呀，不一定就会饥饿。这么说也有道理，但共享总线的位宽是固定的，比如CPU访存可能需要位宽比较大的总线，而中断或者外设可能就只需要位宽很小的总线，这时候就只能按照大位宽来设计。那么小设备占用共享总线的时候，就会存在带宽浪费的情况。此外，由于大家共享同一个总线，采用同一个clk，此时随着接入设备的增多，由于时钟源链接到各个模块的互连线长度不同，进而互连线造成的延迟也不同，进而造成了时钟偏斜问题。为了让大家的时钟都是同一个clk，在芯片后端实现时就需要解决时钟偏斜问题，通过插buffer来加延迟（即时钟树综合），让大家时钟一致。而插入了buffer就会有功耗，所以高频电路设计中，共享总线也会面临时序收敛以及功耗问题。

共享总线的下一个发展形态是交叉开关总线。共享总线的问题就是全局时钟同步、只有一个大位宽总线、分时复用的仲裁机制，交叉开关总线的本质就是将每个主机和每个从机连接起来，通过多路选择器来选通。如果不需要通信的主从对，就可以去掉那根线。由于可以通信的线多了，并行度就会好一些，并且位宽也可以分别设定。在实际应用中，往往会分级处理，将高速设备和低速设备挂载在不同频率的交叉开关下，通过Bridge来连接交叉开关，这样做也有助于降功耗。

片上网络是在进入21世纪以后就被提出的课题。随着单CPU核在指令级并行上的提升遇到瓶颈，而且互联网的发展增强了并行计算的需求，从而多核架构成为主流。既然核数变多了，互联需求也就增加了，CPU核、缓存、DDR之间需要互联，片上网络作为一种新型总线形态应运而生。片上网络其实是借鉴了计算机网络的概念，在片上采用路由转发的方式来进行IP之间的通信。这里面增加的电路设计工作有两个，一个是路由器电路设计，另一个是网络接口设计。前者需要考虑路由算法、仲裁机制、原子、死锁等等，网络接口设计则需要适配各个现有的协议，比如AXI/AHB/CHI等等。以CPU访存为例，先通过网络接口接入到路由网络中，将AXI转化为NoC内部的flit格式，经过若干跳路由转发到达Slave端的网络接口，然后再做格式转化，阿巴阿巴。目前标准的片上网络主要还是应用在CPU场景为主，会基于CHI协议来做缓存一致性的各种事务，也有少数公司用在GPU互联上。不过片上网络这个词被滥用的厉害，现在很多公司里是个互联IP就用片上网络来指代，实际上可能就是个交叉开关，但这也无所谓了。。

后续会分享的

后面打算分享下基于C语言设计的NoC仿真器，支持各种流量模式，支持时延/链路利用率/吞吐量的统计，支持自定义路由算法。会详细说明这里面时延的统计方法，以及如何在没用多线程的情况下仿真数字电路的并行特性。
然后分享电路设计，这个后面再说吧。