要 点
SoC(系统级芯片)越来越不适应基于中心化总线的架构。
精确的使用模型对于理解流量模式非常重要。
要理解互连，就必须有ESL(电子系统级)方案和周期精确方案的结合。
随着SoC的发展，互连建模会变得不可或缺。
SoC上各块的连接正在成为先进芯片设计中的一个主要问题。
SoC（系统级芯片）在先于它出现的板级计算机上开始了自己的生命：作为一个中央处理器，其CPU总线连接到本地内存与外设控制器。从此以后，这种以CPU为中心、面向总线的架构一直是很多SoC的优先规划。但集成化带来了一种复杂性，表现为复杂的外设及其DMA（直接内存访问）控制器、协处理器和附加中央处理器，所有这些都存在于同一个晶片上。因此，SoC的互连架构正在变化。以CPU为中心的老式总线正快速隐退到芯片的功能块中，代替它的是多总线、专用的点对点连接，以及片上网络。
改变的速度很快，架构师差不多都在担心这个变化会远远超过需要支持它的工具。ASIC供应商eSilicon的营销副总裁Hugh Durdan 注意到：“今天，我们仍能看到很多经典的SoC设计，它们采用ARM核心、外设和内存接口。即使这些设计发展到包含多个处理核心，它们通常也会保持传统的AMBA AHB（先进微控制器总线架构先进高性能总线）结构。”
但是，越来越多的迹象表明，SoC互连的中心式总线方案正在日趋完善（见附文《问题是总线带宽还是处理器带宽》）。这个问题部分表现在架构上。随着一只芯片上处理结点数的增长，以及这些结点生成或消耗数据流量的增加以及日益多样化，仅对原始带宽的需求就成为一个问题（图1）。无疑，用九个金属层以及统计时序工具能够使一个多主控总线具有近乎任意的带宽。但复杂布局、信号完整性分析、功耗以及拥塞的成本使这种方案几乎难以处理，尤其是今天有严格的可制造性设计原则。
问题也部分涉及到工具。坦率地说，传统SoC总线使用的工具是微软的Excel。在比较简单的时代，架构师可以只累加起总线上各个块的带宽需求，为高峰拥塞留一些余量，即可用总和决定总线的带宽需求。可用的总线带宽大大超过了单个块的需要，因此从数学上不可能出现问题。
但这些日子已成过去。Silistix营销副总裁David Lautzenheiser警告说：“你不再能从累积带宽估计中获得任何结果。”随着中心化总线快速让位于更复杂的互连架构，电子数据表也让位于更复杂的系统级建模、统计工具，还有周期精确的模型，这同时考验着架构师的技术和耐心。
问题评估
累积带宽并非问题所在，中心化总线也并非总是正确答案，原因有二：首先，流量特征可以有巨大差异。其次，即使数据与时序需求一样，但它们功能块之间也有差异。片上互连的分析和实现问题并能提供人人满意的答案，只不过有助于在正确的块之间提供正确的互连。通常，用一个总线就可以实现这个目标。如果无法实现，还有无数其它技术有自我表现的机会。多媒体SoC很好地展示了一位设计人员必须面对的各种数据流。通常可以用到一个CPU，这个CPU会产生至少两个有独特标志的数据流：新指令的连续获取，以及装入与存储操作的偶发式双向流。
CPU块中的缓存一般会修改这种流量模式。因此，当缓存清空或填充行时，来自CPU核心的流量模式是一种随机散发的突发数据。这种情况与来自其它设备的流量模式有极大的差异。例如，一个射频SoC中的基带信号看上去像来自一只ADC的固定间隔（有时非常短）的一两个数据字。来自摄像头或DVD播放机的视频流也很类似。但视频压缩引擎推入本地内存的中间数据看来则像一系列按近乎随机的序列存储和装入的宏块，而不是扫描线排列的像素流。每种类型的数据都有一个属性标志。并且，如同在CPU中心的情况下，本地内存和状态机都可以改变这个标志。
带宽与延迟
正如各种流量都有自己的标志一样，不同功能块也是个性化的。CPU、硬接线信号处理流水线、视频编码器、串行口和DRAM接口都有不同的需求和期望。MIPS Technologies 公司解决方案架构副总裁Gideon Intrater 注意到：“处理器对延迟极其灵感，不过与一些带宽掠夺者比较，它们对带宽的要求倒是适中的。”CPU缓存控制器并不经常请求数据，但一旦它这样做时，整个CPU都可能要坐等。
