要 点
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都可能要坐等。
与之相反，一些功能块只对原始带宽有兴趣。Intrater说：“这些产品包括高性能的连网设备，PON（无源光网络）是一个很好的例子；视频引擎，如DVD录像机中的MPEG编码器和HDTV中的H.264解码器；还有图像引擎，如打印机中的光栅处理器和数码相机中的JPEG编码器。所幸，在多数系统中，带宽掠夺者对延迟不敏感，而对延迟敏感的处理器对带宽也不贪婪。”
除了这个差别以外，还存在着有特殊要求的块。采用离散余弦变换算法的图像或视频处理器一般是按照宏块来处理像素，通常是8像素×8像素的信息，因此需要能方便地装入和保存这些块，而无需在面向扫描线的内存中去收集或散发像素。
www.55dianzi.com
但是，最恼人的还得是无处不在的内存元件，即DRAM。DRAM采用复杂的同步接口，还有分段的存储阵列，对顺序错误的请求会产生显著的延迟。根据存取方式的不同，DRAM提供的有效带宽可以有很大变动。很多情况下，一种读写请求的排列就会产生接近于理论的流量。不幸的是，尽管这些严格的需求能相当好地匹配于CPU L2缓存控制器的流量模式，但当几款不同处理器都共享一个DRAM端口时，它们就不像累积流量的模式了。
简单地说，互连架构的目标就是：使流量模式适应客户块的需求，让所有数据在恰当的时间，以最小的扩展量到达。由于架构师对流量和客户端知识的局限，以及他们所用工具的能力，这一说法相当好地描述了今天的情况。但对这些是有严格的约束。问题是：要了解流量模式，架构师必须知道完成后系统的使用模型。Lautzenheiser指出：“这里，使用趋向很重要，它涉及无法捉摸的用户感觉。在手机显示的视频中，成功的关键可能并非是总线向视频解码器提供的每秒字节数，而是用户是否认为自己的显示屏在闪烁。要预测这种定性的
用户感觉，就需要全面搜索那些未曾预料的对系统造成最大压力的使用模型。并且，要在将物理原型送交实际用户以前完成这个任务，还需要系统级建模。”
事实上，这个领域可能是系统设计中难以处理的 ESL （电子系统级）工具扮演稳固角色的一个地方。互连IP（知识产权）公司Arteris的总裁兼首席执行官Charlie Janac称：“如果系统架构师可以在完全确定IP块以前就开始进行数据流建模，那就再好不过了。真正意义上是数据流定义了芯片。”
Lautzenheiser与其它专家也持这些观点，他们建议一个架构的设计流要从概念级着手：哪些块应连接到哪些块？然后可以从这个简化的连接图尝试流的建模，即用块的ESL建模和使用模型的最可能信息，将数据流量化到数量、标志以及客户要求。最后，架构师要尝试去证明片上的互连满足这些标准。但这是一个反复迭代的过程。Lautzenheiser说：“总是会有惊奇。窍门是在架构设计和实现之间建立一个简单路径，这样你就可以作快速迭代，以及一个足以适应各种变动而无需作重大架构修订的可扩展基础方案。”
链接与整形
片上网络的建立有两个基本工具：链接与整形资源。链接是为各个块之间提供数据路径。它们的实现可以是一个共享总线的一部分、一种专用连接、交换网络中的一条路径，或更有创意的方式。整形资源包括缓存、FIFO、排队引擎，以及再排序缓冲区等。从传统CPU 总线架构 转向更强大方案的最简便方法也许就是将总线分段。Janac建议说：“在媒体 SoC 中，可以将流量划分为低延迟事务、大带宽事务以及不太关键的外设事务。”可以分别处理各种类型的事务，虽然这样意味着在同一块上有多个总线连接。Denali SOFtware公司IP产品副总裁Brian Gardner指出，这种方案不仅将每种类型的流量放在与之相应的物理介质上，而且还连接到能以类似方式建模的数据流上，从而大大增加了用于其后链接的建模精度。
Lautzenheiser称，这一过程的结果一般是一个层次化的互连链接。这一结果在Raza MICroeleCTRonics的网络处理器中表现得非常明显（图1）。当深入观察一些功能块时，就会发现一种相似的模式，例如在一只现代CPU内的互连，如ARM Cortex A9。在这里，内部链接将处理器核心连接到L1指令缓存和数据缓存。而多主高速缓存总线则将L1缓存连接到L2级缓存，供多达四个处理器核心使用。其它链接则用于控制和探测背后的逻辑潜伏。两个系统总线的连接来自L2控制器。但当无法为每个数据流提供一个正确的物理链接时会发生什么？SoC的DRAM控制器就是一个很好的例子，它必须接受芯片上多个处理器传给它的任何流量混合，但必须设法将这种混乱局面理顺，成为DDR DRAM可以接受的、高度有序的指令流。为了说明问题的复杂性，请看这样一款控制器（图2）。这个器件在一系列分立级上处理各个事务。首先，一个仲裁引擎根据某种优先级方案，决定对控制器的访问。然后，控制器将请求装入指令、读和写队列，它们在队列中按照服务质量要求和DRAM时序的实际情况，等候重新排序。最后，这些请求传递到一个事务处理引擎，它预先检查队列，以重组和获取最能发挥DRAM用途的请求。
