SOC

SOC设计领域的核心技术——软/硬件协同设计 文/汤磊 摘要： 基于IP库的SOC必将是今天与未来微电子设计领域的核心。它既是一种设计技术，也是一种设计方法学。一块SOC上一定会集成各种纯硬件IP、和作为软件载体的IP（MCU、DSP，etc）。因此，作为一种软/硬件平台，面向系统需求的软/硬件协同设计技术与方法一定是决定SOC设计成败的最关键因素。针对这一问题，本文从阐述软/硬件协同设计对SOC芯片开发的关键作用开始，根据我们的研究与实践结果，具体详细展开讨论了如何针对不同的系统需求抽象进行软/硬件规划与协同设计。 关键词： 软/硬件协同设计、SOC、系统任务流图、硬件、软件。 导言——软/硬件协同设计对SOC芯片开发的关键作用： 1．研发约束因素间的矛盾与平衡： 满足预定的功能需求永远是芯片设计的最终目标。在满足功能需求这一目标外，还有很多约束条件需要同时考虑。我们需要在各种矛盾约束中寻求一种尽量达到平衡与和谐的设计结果。 芯片设计最终必须能占领市场、取得利润，并要考虑到产品的可持续发展问题。制约芯片 设计方案 关于薪酬设计方案通用技术作品设计方案停车场设计方案多媒体教室设计方案农贸市场设计方案 的各种因素如图1所示。所有这些研发约束因素之间相互矛盾、彼此制约。 参照图1，就第一层的宏观3因素之间的作用而言： 如果为了考虑产品的可持续发展问题而要在设计中着重考虑“芯片的可重配置性与多应用性”，在“设计约束”要求不变的情况下，必然要耗费更多的“人力资源与时间资源”。设计成本增加了，还要冒产品投入市场时间推迟带来的商业影响。 如果为了要突出产品的竞争优势而重点考虑“设计约束”各方面（面积、功耗、性能）的全面优化，那么，不但要耗费更多的“人力资源与时间资源”，而且“芯片的可重配置性与多应用性”必然下降。 如果想节省人力资源，而又希望尽快推出产品（节省时间资源），那么在“设计约束”和“芯片的可重配置性与多应用性”方面都不可能优化得很好，芯片的设计质量将下降。 就“设计约束”所包括的3个子因素之间的作用而言，同样互相矛盾： 同一个系统任务，若强调高性能，通常芯片的面积和功耗都会变大。 低功耗的设计通常系统性能不会很高。 芯片成本（面积）的减小与性能提高通常彼此矛盾。 总之，我们不可能在设计一款芯片时，同时使各种约束因素都达到最优。哲学的本质是在矛盾中寻求平衡与和谐而并非消除各种矛盾，而这就是设计方法学的意义和重要性所在。 对于任一款芯片的开发，我们的设计任务是，在满足系统功能需求的前提下： 首先要明确到底哪个研发约束是最主要的矛盾（比如对手机而言是：芯片功耗、性能、芯片的可重配置性与多应用性），哪些约束是次要矛盾。 找到一条“以真正面向解决主要矛盾为导向的芯片设计算法”。 在基于IP-Reuse的SOC系统集成芯片开发模式下，应用一系列以满足主要研发约束为导向的软硬件划分与协同设计算法来进行软/硬架构设计。 2．软/硬件协同设计的作用： IP-SoC系统架构规划的最主要部分是所谓软/硬件协同设计。软/硬件协同设计的首要任务是软/硬件任务划分，或边界划分。大体来说，软/硬件任务分配比例的改变对各种研发约束因素条件的影响如 表 关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf 1所示。由表1可见，采用合理的软/硬件协同设计方案，对以真正面向解决主要矛盾约束为设计导向的芯片设计至关重要！ 在以下各节中，我们将就如何针对不同的系统需求进行软硬件规划作具体介绍。 二、关于系统任务流图： 对于系统任务流图的科学数学形式，简单说： 一个系统任务流图由一系列节点和节点间的有向连线组成，每个节点代表一个系统子任务（FFT、JPEG、Viterbi decoder、etc），两节点间的连线代表了数据传递流向。 任何一个系统任务都可表示为单任务流图的形式。 多个、并行的系统任务可以由多个并行的系统任务流图来表示。 如果，有多个不同的系统任务，但是每次只有一个被执行，则可用多分支系统任务流图来表示。各系统任务之间为时间互斥关系。 三、单任务流图的软/硬件协同设计方法： 一个TD-SCDMA的典型下行通话流程可被视为一个单系统任务，如下所示： 无线信号接收(信号检测(物理 协议 离婚协议模板下载合伙人协议 下载渠道分销协议免费下载敬业协议下载授课协议下载 栈解包（信道解码）(2、3层协议栈解包(信源解码(语音、图象输出 当然，如上单任务流图需要进行进一步深入的子任务细化。 根据研究结果，单任务流图的软/硬件划分原则如下： 不适宜由软件处理的任务应由硬件来做。（如：RF接收。） 关键路径上性能要求苛刻的任务应由硬件来做。（如：Viterbi decoder） 关键路径上、多循环次数的特定复杂运算任务应由硬件来做[1]。（如：矢量乘法、FFT） 关键路径上、多分支判断结构的子任务应由软件来做[1]。（如：协议栈） 有可重配置性与多应用性灵活要求的任务应由软件来做。 四、单任务流图的宏流水线软/硬件协同设计方法：[2] 通常的软件执行载体（各种处理器：MCU、DSP）都为软件的指令执行提供了多级流水线方式以增加IO吞吐量。但这只是一种微观的软件流水线。根据研究[2]，为从本质上提高任意单任务流图的IO吞吐量，存在一种宏观的硬件流水线划分算法。根据相关算法[2]，我们总可以将任意串行单任务流图根据相似性原则纵向划分为几个子图。其中操作度最相似的子图可以用一个合成子图来描述并用一个定制硬件模块来实现，而不同的硬件模块之间则可以实现一种宏流水线的软件调度方式已使总系统IO吞吐量成倍增加。 五、多分支系统任务流图的软/硬件协同设计方法：[1][3][4] 强调任一款软/硬件平台通用性的同时一定不能忽略该平台的专用性与适用性。任一款IP-SOC通用芯片的可重配置性与多应用性一定是大体指向一个总体相似的专向应用系列。 如果要在实际设计中强调某一款专用芯片的可重配置性与多应用性，一个最有效的方法，就是尽可能考虑到各个应用的大体功能需求，即每个单应用的单任务流图形式，然后将各个单任务流图看作一个彼此互斥的多分支总系统任务流图来进行系统架构规划。 简单举例： TD-SCDMA、GSM、可视电话3模合一应用下（下行链路）的多分支系统任务流图粗框架如图2所示： 多分支系统任务流图软/硬件划分原则如下： 首先采用算法将不同分支间功能相似的子任务节点尽可能进行一一自动对应。 各个分支间，完全对应相同的子任务节点由硬件完成。（比如，假设如果3个应用模式下的语音解码协议完全相同，则完全可将语音解码部分做成纯硬件。） 各个分支间任务有差别的相对应节点由软件完成。（如：3种应用下彼此不同的协议栈处理工作） 各个分支间任务不同，但不适宜由软件完成的工作，由不同硬件各自单独完成。（比如：对于芯片的3模应用，架构中一定要有TD-RFIO、GSM-RFIO、可视电话UART 3个各自独立的对外接口模块，这里暂不讨论软件无线电的可实现性。） 软件载体（MCU、DSP）的最大处理能力应该由已被划分为软件任务的、各个分支间任务相似的相对应节点对软件性能需求的最大值来决定。（如图：假设可视电话和TD的信源解码都要求有语音及图象解码能力，而GSM的信源解码只要求有语音解码能力。则芯片中DSP的性能必须具备语音及图象解码能力。） 根据研究，对多分支系统任务流图，由于不同分支间的互斥性与分时性，可以将各个分支进行基于对应节点功能相似度的图形合并，由此生成一张复合任务流图[3，4]。复合任务流图中的每一个复合节点子任务，由生成该复合节点的原各个分支间相对应节点的功能集之合集组成。 例如，上述TD-SCDMA、GSM、可视电话3模式应用下的多分支系统任务流图的复合任务流图粗框架形式如图2右所示。也就是说，对于多分支系统任务流图，我们可以通过图论的方法将各个分支进行任务合并生成一张复合任务流图，当且仅当系统架构能够胜任复合任务流图的功能及性能需求时，芯片设计能够满足所预定的可重配置性与多应用性的需要。（关于“基于节点任务相似度的多图自动化合并算法”可参考[3，4]。） 并行系统任务流图的软/硬件协同设计方法： 多并行与多分支系统任务的最大区别是各单任务流图在时间上并行因此不能进行合并。 比如对于手机基带芯片的应用而言，通话过程的上行与下行任务之间就可视为并行任务。而对于手机大多数的其它功能需求，如：发短信、记事本、打游戏、上网、MP3，等等，它们通常不可能与通话过程同时进行，并且它们彼此之间并行的可能性也不高。我们可将其相互之间视为多分支系统任务[1]。各个分支任务的多样性适宜由软件来完成，而软件载体（MCU、DSP）的最大处理能力则由各个分支间相对应各节点对软件性能需求的最大值来决定。 广泛地说，一个多并行系统任务流图的软/硬件协同设计方法是一件非常复杂的事情（NP完全问题）。一个多并行系统的芯片架构上通常需要包含多个微处理器及与之相应的互连结构。采用多处理器的理由如下： 每个处理器都需要通过软件编程来完成某种实际的任务，因此多处理器的采用从本质上是在允许芯片的多用途性。以处理器群为主的芯片架构设计本质上是一个通用平台的架构设计。 多处理器从本质上成倍增加了系统任务的并行性，更适合运行一个多并行系统任务流图。 任何事物都是双刃剑，多处理器为子任务的并行分配提供了极大的空间和选择余地，但是也为到底采用一种怎样的算法来进行多并行系统任务流图面向处理器群的合理任务分配和调度带来了难题。简单说，问题的数学模型如下： 现有数个系统任务流图需要并行执行，每个任务流图的运行各自有其不同的性能要求（deadline），如果用一个多处理器芯片来运行它，如何通过软件规划将每个单任务流图中的每个子任务节点拓扑到某一个合适的硬件处理器上来运行，使整个多并行系统任务流图的各个单系统任务都能满足其性能要求（deadline）。 对于每个单任务流图中的每个子任务节点，主要考虑两点问题： 一是如何分配（用哪一个处理器来运行它）， 二是如何调度（何时在所选的处理器上运行它）。 考虑因素大致有如下几点： 哪个处理器对该节点的执行速度最快； 哪个处理器的总任务列表比较空闲； 与该节点有连线（即有数据传输）关系的相邻节点被分配在哪个处理器上（这关系到数据传输延迟长短的问题。） 如此复杂的问题，通常属于NP完全问题，它的解决方法通常是所谓启发式算法（如遗传算法、模拟退火、神经网络、禁忌算法）。此类算法虽不保证得到最优解，但是尽量保证在限定的计算机时间内得到尽可能优的解。 适应这种多并行系统任务流图的硬件架构之一是所谓Network on Chip[5]。简单说，Network on Chip是将处理器群（MCU、DSP、etc）用局域网和一些路由节点相互连接起来的一种单芯片系统，各个处理器之间通过网络进行近似符合TCP/IP协议的数据包交换（不是电路交换）。如图3所示。我们的任务就是：对于任意一个多并行系统任务流图，每个任务流图的运行性能各自有其deadline要求，如何将每个任务流图中的每个子任务节点拓扑到某一个合适的处理器上来运行，使整个多并行系统任务流图的每个单系统任务都能满足其deadline。我们首先建立了关于任务流图运行时间的数学模型，然后开发了一种2步遗传算法来解决这个问题并最终得到每个节点的分配和调度方案。[6] 图4是我们根据此算法自行开发的一个相应EDA工具。如图4所示，工具能够给出各种相关数据，以及每个系统任务流图的关键路径。 基于Network on Chip架构的片上多处理器群是未来芯片设计的必然选择。 总结： 本文首先提出了软/硬件协同设计对SOC芯片开发关键的作用，然后根据我们的研究与实践结果，具体详细展开讨论了如何针对不同的系统需求抽象（单系统任务、流水线系统任务、多分支系统任务、多并行系统任务）进行软硬件规划。本文认为，软/硬件协同设计技术，将是今后IP-SOC设计领域的最核心技术。 参考文献： Tang Lei, Wei Shaojun, Qiu Yulin, CFG in sub-graph matching based HW/SW co-design. The 4th International Conference on ASIC Proceedings, 2001; pp. 171-174. Tang Lei, Wei Shaojun, Qiu Yulin, Pipelined-multi-similarity-system generation based HW/SW co-design. The 6th International Conference for Young Computer Scientists. 2001; pp. 111-115. Tang Lei, Wei Shaojun, Qiu Yulin, Hardware Optimization Technique of Full-Customized HW/SW Co-Design. Chinese Journal of Semiconductors. June, 2002; No.6, Vol.23, pp.637-644. Tang Lei, Wei Shaojun, Qiu Yulin, Character analysis of HW/SW mono-similarity-system. Chinese Journal of Electronics. Oct. 2002; No.4, Vol.11, pp.444-449. Axel Jantsch and Hannu Tenhunen (Editors), Networks on Chip, Kluwer Academic Publishers, 2003. Tang Lei, Shashi Kumar, A Two-Step Genetic Algorithm for Mapping Task Graphs to a Network on Chip Architecture, EUROMICRO Symposium on Digital System Design, Antalya, Turkey, September, 2003; pp. 180-187. 作者介绍 汤磊：嵌入式系统软硬件协同设计领域博士；曾在瑞典延雪平大学电子与计算机工程学系 做博士后。以第一作者发表IC设计研究论文16篇，均为EI或SCI收录。现就职于信息产业部软件与集成电路促进中心。 � 图1 表1： � 面积� 功耗� 性能� 可重配置性与多应用性� 人力与时间资源需求� � 硬件代替软件� ↑� ↓� ↑� ↓� ↑� � 软件代替硬件� ↓� ↑� ↓� ↑� ↓� � TD-SCDMA GSM 可视电话 3模合一的复合任务流图 � 图2 � 图3 � 图4 7