流量管理：SoC设计者越来越大的梦魇
发布时间：2010-10-8 12:21
发布者：eetech
|
要 点 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像素的信息，因此需要能方便地装入和保存这些块，而无需在面向扫描线的内存中去收集或散发像素。 但是，最恼人的还得是无处不在的内存元件，即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用途的请求。 对其它功能块，相同观点正变得越来越普遍。通常，信号处理或编码器/解码器块包含有复杂的DMA引擎，它提供很多与DRAM控制器相似的功能，如散播/获取处理、数据重新排序以及将随机请求转为突发请求的缓冲等。引擎完成这些功能并不会方便DRAM控制器，事实上它们可能把DRAM控制器弄乱，使流量适合于必须通过的物理链接。 结果与未来 全部这些工作的结果很显著。MIPS总裁兼首席执行官John Bourgoin称，对基本相同的功能块，SoC调整的结果可以提高系统性能四倍或五倍。这种加速等级已超过从CPU升级或更快处理中获得的好处，有时甚至快于增加一个硬件加速器的结果。 当SoC架构从功能区别的异质多处理，向半对称的多处理器转变时，对互连架构的专注需求也从增强性能和节能替代方法转而成为系统设计的一个必要部分。没有对数据流的详细分析，一个动态多处理系统可能只是要求更多的互连，从而超过一个合理硅片设计所能提供的水平。 这种可能性使我们回到工具的问题上。Lautzenheiser说，今天架构师（如果他们没有用白板或电子数据表的话）的工具流是ESL建模工具、基于排队理论的统计分析（可以给出一个良好的整体图像，但可能完全错过角落情况）以及周期精确模型（可以寻找各个角落但可能因太慢而找不出它们）的一个特殊组合。 Arteris的Janac同意这个说法：“你需要架构级的建模。对一个电子数据表来说，问题变得太复杂。但对ESL，即使最好的工具也不具有现实性，它们给出的是一个抽象。因此，你必须将系统级的研究与你的IP周期精确模型捆 绑在一起。” MIPS的Intrater建议，做这种捆绑的一种方法是使用硬件仿真。“周期精确模型是基于RTL，它们用于引导Linux或运行一个应用程序时速度太慢了。今天的最新技术是手工将细粒度的统计工具与周期精确仿真结合起来。但是，如果你在足够早的阶段就拥有互连的RTL模型，那么就可以使用仿真，将周期精确模型运行几十亿个循环。” 这种状态的工具使架构继续成为一种艺术。在正确水平上对某种方案建模；拥有来自实际用户的精确使用模型；找到关键情况的正确位置；以及从周期精确模型得出准确的结论，等等，这些都来自于艺术与经验，尽管系统级工具在逐步涌现，尤其是来自互连IP供应商的产品。但这是一种越来越具生命活力的艺术，当我们步入晶片上大型多处理系统的时代时，它将成为不可或缺的艺术。 附文：问题是总线带宽还是处理器带宽 随着通信与媒体流数据速率的增长，多数芯片设计者很快意识到数据带宽是设计成功的一个重要因素。Tensilica公司有100个以上的多处理器芯片设计的经验，它提出了一些基本概念，以解决有关带宽的疑惑。 例如，不恰当的数据通信会造成原始带宽的不足：I/O及片外内存的数据通信，片上不同块之间带宽共同构成的对持续带宽的总需求，超出了接口的最大持续带宽。它还会造成过高的延迟。数据存取的最差情况或典型延迟都会在某些重要场合造成数据饥饿，比如当没有合适的总带宽时就会增加竞争延迟。 通信中的瓶颈会出现于设计中的多个地方。三个最常见的位置分别是：片外的内存控制器；片上总线，尤其是当有多个主（特别是处理器和DMA控制器）访问多个从（内存与I/O接口）时；还有处理器与总线之间的接口。 处理器总线的瓶颈与接口的峰值数据传输速率有关，它通常接近于片上总线的峰值带宽。瓶颈还与如下的数据移动速率有关，即将远处内存数据沿片上总线或在片外移动，将数据移入本地内存，将数据移入或移出处理器寄存器，通过本地内存移动数据，以及将数据移出到远程内存等的速率。采用传统RISC处理器通过片上总线存取数据时，这种数据移动可能每32bit数据字要花费10个"20个处理器周期，即使数据已经在片上，并且处理器在整个路径中都不修改数据。 打破处理器总线瓶颈有两种方式。首先，使用第二个总线主控，如其它处理器或一个DMA（直接内存访问）控制器，将数据移入和移出第一个处理器的本地内存，这样可以部分解决瓶颈问题。不过，RISC的32bit寄存器与负载存储寄存器仍有问题。其次，可以扩充处理器接口，使之允许大带宽的数据流，从而绕过总线接口上的瓶颈。具有直接连接端口和队列的处理器可以通过处理器执行单元，移动比RISC处理器高一个数量级的数据流。 在复杂芯片设计中，总线互连与非总线互连可以协调工作。最佳的实践表明，当一个设计者了解到一对子系统需要大互连带宽和有良好限制的延迟时，他就应该在两者之间建立一个最佳的路径。其它通信（包括敏感的子系统间的通信）可以安全地使用一个公共的多主/多从片上总线，用于较低带宽和延迟敏感的数据移动。这种区分保持了普通总线的通用性，但减少了竞争异常的风险，简化了建模工作，并且提高了平台的缩放性能。 对大带宽链接的通信优化亦有助于节省能源。对于处理器与处理器通信队列之间的直接连接，每次数据传输一般比等效的总线传输要节能10倍。 |
网友评论