SOC设计领域的核心技术——软硬件协同设计
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
制约芯片设计方案的因素
芯片的可重配置性与多应用性
设计约束
人力资源与时间资源time to market
面积
功耗
性能
图1 时间资源” 。设计成本增加了，还要冒产品投入市场时间推迟带来的商业影响。 B． 如果为了要突出产品的竞争优势而重点考虑“设计约束”各方面（面积、功耗、性 能）的全面优化，那么，不但要耗费更多的“人力资源与时间资源” ，而且“芯片 的可重配置性与多应用性”必然下降。
3
列。 如果要在实际设计中强调某一款专用芯片的可重配置性与多应用性，一个最有效的方 法，就是尽可能考虑到各个应用的大体功能需求，即每个单应用的单任务流图形式，然 后将各个单任务流图看作一个彼此互斥的多分支总系统任务流图来进行系统架构规划。 简单举例： TD-SCDMA、GSM、可视电话 3 模合一应用下（下行链路）的多分支系统 任务流图粗框架如图 2 所示： 多分支系统任务流图软/硬件划分原则如下： A． 首先采用算法将不同分支间功能相似的子任务节点尽可能进行一一自动对应。 B． 各个分支间，完全对应相同的子任务节点由硬件完成。 （比如，假设如果 3 个应用模 式下的语音解码协议完全相同，则完全可将语音解码部分做成纯硬件。 ） C． 各个分支间任务有差别的相对应节点由软件完成。 （如：3 种应用下彼此不同的协议 栈处理工作） D． 各个分支间任务不同， 但不适宜由软件完成的工作， 由不同硬件各自单独完成。 （比 如： 对于芯片的 3 模应用， 架构中一定要有 TD-RFIO、 GSM-RFIO、 可视电话 UART 3 个各自独立的对外接口模块，这里暂不讨论软件无线电的可实现性。 ） E． 软件载体（MCU、DSP）的最大处理能力应该由已被划分为软件任务的、各个分支 间任务相似的相对应节点对软件性能需求的最大值来决定。 （如图： 假设可视电话和 TD 的信源解码都要求有语音及图象解码能力，而 GSM 的信源解码只要求有语音解 码能力。则芯片中 DSP 的性能必须具备语音及图象解码能力。 ） 根据研究，对多分支系统任务流图，由于不同分支间的互斥性与分时性，可以将各个分 支进行基于对应节点功能相似度的图形合并，由此生成一张复合任务流图[3，4]。复合 任务流图中的每一个复合节点子任务，由生成该复合节点的原各个分支间相对应节点的 功能集之合集组成。 例如，上述 TD-SCDMA、GSM、可视电话 3 模式应用下的多分支系统任务流图的复合 任务流图粗框架形式如图 2 右所示。也就是说，对于多分支系统任务流图，我们可以通 过图论的方法将各个分支进行任务合并生成一张复合任务流图，当且仅当系统架构能够 胜任复合任务流图的功能及性能需求时，芯片设计能够满足所预定的可重配置性与多应 用性的需要。 （关于“基于节点任务相似度的多图自动化合并算法”可参考[3，4]。 ） 六、并行系统任务流图的软/硬件协同设计方法： 多并行与多分支系统任务的最大区别是各单任务流图在时间上并行因此不能进行合并。 比如对于手机基带芯片的应用而言，通话过程的上行与下行任务之间就可视为并行任 务。而对于手机大多数的其它功能需求，如：发短信、记事本、打游戏、上网、MP3， 等等，它们通常不可能与通话过程同时进行，并且它们彼此之间并行的可能性也不高。 我们可将其相互之间视为多分支系统任务[1]。各个分支任务的多样性适宜由软件来完 成，而软件载体（MCU、DSP）的最大处理能力则由各个分支间相对应各节点对软件性 能需求的最大值来决定。
1
C． 如果想节省人力资源，而又希望尽快推出产品（节省时间资源） ，那么在“设计约 束”和“芯片的可重配置性与多应用性”方面都不可能优化得很好，芯片的设计质 量将下降。 就“设计约束”所包括的 3 个子因素之间的作用而言，同样互相矛盾： A． 同一个系统任务，若强调高性能，通常芯片的面积和功耗都会变大。 B． 低功耗的设计通常系统性能不会很高。 C． 芯片成本（面积）的减小与性能提高通常彼此矛盾。 总之，我们不可能在设计一款芯片时，同时使各种约束因素都达到最优。哲学的本质是 在矛盾中寻求平衡与和谐而并非消除各种矛盾， 而这就是设计方法学的意义和重要性所 在。 对于任一款芯片的开发，我们的设计任务是，在满足系统功能需求的前提下： A． 首先要明确到底哪个研发约束是最主要的矛盾（比如对手机而言是：芯片功耗、性 能、芯片的可重配置性与多应用性） ，哪些约束是次要矛盾。 面积 硬件代替软件 软件代替硬件 ↑ ↓ 功耗 ↓ ↑ 表 1： 性能 ↑ ↓ 可重配置性与 多应用性 ↓ ↑ 人力与时间资 源需求 ↑ ↓
2
一个 TD-SCDMA 的典型下行通话流程可被视为一个单系统任务，如下所示： 无线信号接收信号检测物理协议栈解包（信道解码）2、3 层协议栈解包信源 解码语音、图象输出 当然，如上单任务流图需要进行进一步深入的子任务细化。 根据研究结果，单任务流图的软/硬件划分原则如下： A． 不适宜由软件处理的任务应由硬件来做。 （如：RF 接收。 ） B． 关键路径上性能要求苛刻的任务应由硬件来做。 （如：Viterbi decoder ） C． 关键路径上、多循环次数的特定复杂运算任务应由硬件来做[1]。 （如：矢量乘 法、FFT ） D． 关键路径上、多分支判断结构的子任务应由软件来做[1]。 （如：协议栈） E． 有可重配置性与多应用性灵活要求的任务应由软件来做。 四、单任务流图的宏流水线软/硬件协同设计方法：[2] 通常的软件执行载体（各种处理器：MCU、DSP）都为软件的指令执行提供了多级流水 TD-SCDMA GSM 可视电话
UART
3 模合一的复合任务流图
TDRF GSMRF UART
RFIO
RFIO
JD
JD
TD物理协议、 GSM物理协议、信检
物理协议
物理协议、信检
2、3层协议
2、3层协议
固网协议
无线2、3层通用协议, 固网协议
音、像解码
音解码
音、像解码
音、像解码
音、像输出
音输出
音、像输出
音、像输出
图2 线方式以增加 IO 吞吐量。但这只是一种微观的软件流水线。根据研究[2]，为从本质上 提高任意单任务流图的 IO 吞吐量，存在一种宏观的硬件流水线划分算法。根据相关算 法[2]，我们总可以将任意串行单任务流图根据相似性原则纵向划分为几个子图。其中操 作度最相似的子图可以用一个合成子图来描述并用一个定制硬件模块来实现，而不同的 硬件模块之间则可以实现一种宏流水线的软件调度方式已使总系统 IO 吞吐量成倍增加。 五、多分支系统任务流图的软/硬件协同设计方法：[1][3][4] 强调任一款软/ 硬件平台通用性的同时一定不能忽略该平台的专用性与适用性。任一款 IP-SOC 通用芯片的可重配置性与多应用性一定是大体指向一个总体相似的专向应用系
RNI
S
RNI
S
RNI
S
IP Node 1,3
IP Node 1,1
ห้องสมุดไป่ตู้
IP Node 1,2
S
RNI RNI
S
RNI
S
IP Node 2,3
IP Node 2,1
IP Node 2,2
S
RNI RNI
S
RNI
S
IP Node 3,3
IP Node 3,1
IP Node 3,2
图3
B． 哪个处理器的总任务列表比较空闲； C． 与该节点有连线（即有数据传输）关系的相邻节点被分配在哪个处理器上（这 关系到数据传输延迟长短的问题。 ） 如此复杂的问题，通常属于 NP 完全问题，它的解决方法通常是所谓启发式算法（如遗 传算法、模拟退火、神经网络、禁忌算法） 。此类算法虽不保证得到最优解，但是尽量 保证在限定的计算机时间内得到尽可能优的解。 适应这种多并行系统任务流图的硬件架构之一是所谓 Network on Chip[5] 。简单说， Network on Chip 是将处理器群（MCU、DSP、etc ）用局域网和一些路由节点相互连接 起来的一种单芯片系统，各个处理器之间通过网络进行近似符合 TCP/IP 协议的数据包 交换（不是电路交换） 。如图 3 所示。我们的任务就是：对于任意一个多并行系统任务 流图，每个任务流图的运行性能各自有其 deadline 要求，如何将每个任务流图中的每个 子任务节点拓扑到某一个合适的处理器上来运行， 使整个多并行系统任务流图的每个单 系统任务都能满足其 deadline。我们首先建立了关于任务流图运行时间的数学模型，然
B． 找到一条“以真正面向解决主要矛盾为导向的芯片设计算法” 。 C． 在基于 IP-Reuse 的 SOC 系统集成芯片开发模式下，应用一系列以满足主要研发约 束为导向的软硬件划分与协同设计算法来进行软/硬架构设计。 2．软/硬件协同设计的作用： IP-SoC 系统架构规划的最主要部分是所谓软/硬件协同设计。 软/硬件协同设计的首 要任务是软/硬件任务划分，或边界划分。大体来说，软/硬件任务分配比例的改变 对各种研发约束因素条件的影响如表 1 所示。由表 1 可见，采用合理的软/硬件协 同设计方案，对以真正面向解决主要矛盾约束为设计导向的芯片设计至关重要！ 在以下各节中，我们将就如何针对不同的系统需求进行软硬件规划作具体介绍。 二、关于系统任务流图： 对于系统任务流图的科学数学形式，简单说： A． 一个系统任务流图由一系列节点和节点间的有向连线组成， 每个节点代表一个 系统子任务（FFT 、JPEG、Viterbi decoder 、etc ） ，两节点间的连线代表了数据 传递流向。 B． 任何一个系统任务都可表示为单任务流图的形式。 C． 多个、并行的系统任务可以由多个并行的系统任务流图来表示。 D． 如果，有多个不同的系统任务，但是每次只有一个被执行，则可用多分支系统 任务流图来表示。各系统任务之间为时间互斥关系。 三、单任务流图的软/硬件协同设计方法：
4
广泛地说， 一个多并行系统任务流图的软/硬件协同设计方法是一件非常复杂的事情 （NP 完全问题） 。一个多并行系统的芯片架构上通常需要包含多个微处理器及与之相应的互 连结构。采用多处理器的理由如下： 1． 每个处理器都需要通过软件编程来完成某种实际的任务，因此多处理器的采用从 本质上是在允许芯片的多用途性。以处理器群为主的芯片架构设计本质上是一个 2． 通用平台的架构设计。 多处理器从本质上成倍增加了系统任务的并行性，更适合运行一个多并行系统任 务流图。 任何事物都是双刃剑， 多处理器为子任务的并行分配提供了极大的空间和选择余地， 但 是也为到底采用一种怎样的算法来进行多并行系统任务流图面向处理器群的合理任务 分配和调度带来了难题。简单说，问题的数学模型如下： 现有数个系统任务流图需要并行执行， 每个任务流图的运行各自有其不同的性能要 求（deadline） ，如果用一个多处理器芯片来运行它，如何通过软件规划将每个单任 务流图中的每个子任务节点拓扑到 某一个合适的硬件处理器上来运行， 使整个多并行系统任务流图的各个 单 系 统 任 务 都 能 满 足 其性 能 要 求 （deadline） 。 对于每个单任务流图中的每个子任务节 点，主要考虑两点问题： 一是如何分配 （用哪一个处理器来运 行它） ， 二是如何调度 （何时在所选的处理器 上运行它） 。 考虑因素大致有如下几点： A． 哪个处理器对该节点的执行速 度最快；
SOC 设计领域的核心技术——软/硬件协同设计
文/汤磊 摘要： 基于 IP 库的 SOC 必将是今天与未来微电子设计领域的核心。它既是一种设计技术，也是一 种设计方法学。 一块 SOC 上一定会集成各种纯硬件 IP、 和作为软件载体的 IP（MCU、 DSP， etc ） 。因此，作为一种软/硬件平台，面向系统需求的软/硬件协同设计技术与方法一定是决 定 SOC 设计成败的最关键因素。针对这一问题，本文从阐述软/硬件协同设计对 SOC 芯片 开发的关键作用开始， 根据我们的研究与实践结果， 具体详细展开讨论了如何针对不同的系 统需求抽象进行软/硬件规划与协同设计。 关键词： 软/硬件协同设计、SOC、系统任务流图、硬件、软件。 一、导言——软/硬件协同设计对 SOC 芯片开发的关键作用： 1．研发约束因素间的矛盾与平衡： 满足预定的功能需求永远是芯片设计的最终目标。 在满足功能需求这一目标外， 还 有很多约束条件需要同时考虑。 我们需要在各种矛盾约束中寻求一种尽量达到平衡与和 谐的设计结果。 芯片设计最终必须能占领市场、取得利润，并要考虑到产品的可持续发展问题。制约芯 片设计方案的各种因素如图 1 所示。所有这些研发约束因素之间相互矛盾、彼此制约。 参照图 1，就第一层的宏观 3 因素之间的作用而言： A． 如果为了考虑产品的可持续发展问题而要在设计中着重考虑 “芯片的可重配置性与 多应用性” ，在“设计约束”要求不变的情况下，必然要耗费更多的“人力资源与
芯片的可重配置性与多应用性
设计约束
人力资源与时间资源time to market
面积
功耗
性能
图1 时间资源” 。设计成本增加了，还要冒产品投入市场时间推迟带来的商业影响。 B． 如果为了要突出产品的竞争优势而重点考虑“设计约束”各方面（面积、功耗、性 能）的全面优化，那么，不但要耗费更多的“人力资源与时间资源” ，而且“芯片 的可重配置性与多应用性”必然下降。
3
列。 如果要在实际设计中强调某一款专用芯片的可重配置性与多应用性，一个最有效的方 法，就是尽可能考虑到各个应用的大体功能需求，即每个单应用的单任务流图形式，然 后将各个单任务流图看作一个彼此互斥的多分支总系统任务流图来进行系统架构规划。 简单举例： TD-SCDMA、GSM、可视电话 3 模合一应用下（下行链路）的多分支系统 任务流图粗框架如图 2 所示： 多分支系统任务流图软/硬件划分原则如下： A． 首先采用算法将不同分支间功能相似的子任务节点尽可能进行一一自动对应。 B． 各个分支间，完全对应相同的子任务节点由硬件完成。 （比如，假设如果 3 个应用模 式下的语音解码协议完全相同，则完全可将语音解码部分做成纯硬件。 ） C． 各个分支间任务有差别的相对应节点由软件完成。 （如：3 种应用下彼此不同的协议 栈处理工作） D． 各个分支间任务不同， 但不适宜由软件完成的工作， 由不同硬件各自单独完成。 （比 如： 对于芯片的 3 模应用， 架构中一定要有 TD-RFIO、 GSM-RFIO、 可视电话 UART 3 个各自独立的对外接口模块，这里暂不讨论软件无线电的可实现性。 ） E． 软件载体（MCU、DSP）的最大处理能力应该由已被划分为软件任务的、各个分支 间任务相似的相对应节点对软件性能需求的最大值来决定。 （如图： 假设可视电话和 TD 的信源解码都要求有语音及图象解码能力，而 GSM 的信源解码只要求有语音解 码能力。则芯片中 DSP 的性能必须具备语音及图象解码能力。 ） 根据研究，对多分支系统任务流图，由于不同分支间的互斥性与分时性，可以将各个分 支进行基于对应节点功能相似度的图形合并，由此生成一张复合任务流图[3，4]。复合 任务流图中的每一个复合节点子任务，由生成该复合节点的原各个分支间相对应节点的 功能集之合集组成。 例如，上述 TD-SCDMA、GSM、可视电话 3 模式应用下的多分支系统任务流图的复合 任务流图粗框架形式如图 2 右所示。也就是说，对于多分支系统任务流图，我们可以通 过图论的方法将各个分支进行任务合并生成一张复合任务流图，当且仅当系统架构能够 胜任复合任务流图的功能及性能需求时，芯片设计能够满足所预定的可重配置性与多应 用性的需要。 （关于“基于节点任务相似度的多图自动化合并算法”可参考[3，4]。 ） 六、并行系统任务流图的软/硬件协同设计方法： 多并行与多分支系统任务的最大区别是各单任务流图在时间上并行因此不能进行合并。 比如对于手机基带芯片的应用而言，通话过程的上行与下行任务之间就可视为并行任 务。而对于手机大多数的其它功能需求，如：发短信、记事本、打游戏、上网、MP3， 等等，它们通常不可能与通话过程同时进行，并且它们彼此之间并行的可能性也不高。 我们可将其相互之间视为多分支系统任务[1]。各个分支任务的多样性适宜由软件来完 成，而软件载体（MCU、DSP）的最大处理能力则由各个分支间相对应各节点对软件性 能需求的最大值来决定。
1
C． 如果想节省人力资源，而又希望尽快推出产品（节省时间资源） ，那么在“设计约 束”和“芯片的可重配置性与多应用性”方面都不可能优化得很好，芯片的设计质 量将下降。 就“设计约束”所包括的 3 个子因素之间的作用而言，同样互相矛盾： A． 同一个系统任务，若强调高性能，通常芯片的面积和功耗都会变大。 B． 低功耗的设计通常系统性能不会很高。 C． 芯片成本（面积）的减小与性能提高通常彼此矛盾。 总之，我们不可能在设计一款芯片时，同时使各种约束因素都达到最优。哲学的本质是 在矛盾中寻求平衡与和谐而并非消除各种矛盾， 而这就是设计方法学的意义和重要性所 在。 对于任一款芯片的开发，我们的设计任务是，在满足系统功能需求的前提下： A． 首先要明确到底哪个研发约束是最主要的矛盾（比如对手机而言是：芯片功耗、性 能、芯片的可重配置性与多应用性） ，哪些约束是次要矛盾。 面积 硬件代替软件 软件代替硬件 ↑ ↓ 功耗 ↓ ↑ 表 1： 性能 ↑ ↓ 可重配置性与 多应用性 ↓ ↑ 人力与时间资 源需求 ↑ ↓
2
一个 TD-SCDMA 的典型下行通话流程可被视为一个单系统任务，如下所示： 无线信号接收信号检测物理协议栈解包（信道解码）2、3 层协议栈解包信源 解码语音、图象输出 当然，如上单任务流图需要进行进一步深入的子任务细化。 根据研究结果，单任务流图的软/硬件划分原则如下： A． 不适宜由软件处理的任务应由硬件来做。 （如：RF 接收。 ） B． 关键路径上性能要求苛刻的任务应由硬件来做。 （如：Viterbi decoder ） C． 关键路径上、多循环次数的特定复杂运算任务应由硬件来做[1]。 （如：矢量乘 法、FFT ） D． 关键路径上、多分支判断结构的子任务应由软件来做[1]。 （如：协议栈） E． 有可重配置性与多应用性灵活要求的任务应由软件来做。 四、单任务流图的宏流水线软/硬件协同设计方法：[2] 通常的软件执行载体（各种处理器：MCU、DSP）都为软件的指令执行提供了多级流水 TD-SCDMA GSM 可视电话
UART
3 模合一的复合任务流图
TDRF GSMRF UART
RFIO
RFIO
JD
JD
TD物理协议、 GSM物理协议、信检
物理协议
物理协议、信检
2、3层协议
2、3层协议
固网协议
无线2、3层通用协议, 固网协议
音、像解码
音解码
音、像解码
音、像解码
音、像输出
音输出
音、像输出
音、像输出
图2 线方式以增加 IO 吞吐量。但这只是一种微观的软件流水线。根据研究[2]，为从本质上 提高任意单任务流图的 IO 吞吐量，存在一种宏观的硬件流水线划分算法。根据相关算 法[2]，我们总可以将任意串行单任务流图根据相似性原则纵向划分为几个子图。其中操 作度最相似的子图可以用一个合成子图来描述并用一个定制硬件模块来实现，而不同的 硬件模块之间则可以实现一种宏流水线的软件调度方式已使总系统 IO 吞吐量成倍增加。 五、多分支系统任务流图的软/硬件协同设计方法：[1][3][4] 强调任一款软/ 硬件平台通用性的同时一定不能忽略该平台的专用性与适用性。任一款 IP-SOC 通用芯片的可重配置性与多应用性一定是大体指向一个总体相似的专向应用系
RNI
S
RNI
S
RNI
S
IP Node 1,3
IP Node 1,1
ห้องสมุดไป่ตู้
IP Node 1,2
S
RNI RNI
S
RNI
S
IP Node 2,3
IP Node 2,1
IP Node 2,2
S
RNI RNI
S
RNI
S
IP Node 3,3
IP Node 3,1
IP Node 3,2
图3
B． 哪个处理器的总任务列表比较空闲； C． 与该节点有连线（即有数据传输）关系的相邻节点被分配在哪个处理器上（这 关系到数据传输延迟长短的问题。 ） 如此复杂的问题，通常属于 NP 完全问题，它的解决方法通常是所谓启发式算法（如遗 传算法、模拟退火、神经网络、禁忌算法） 。此类算法虽不保证得到最优解，但是尽量 保证在限定的计算机时间内得到尽可能优的解。 适应这种多并行系统任务流图的硬件架构之一是所谓 Network on Chip[5] 。简单说， Network on Chip 是将处理器群（MCU、DSP、etc ）用局域网和一些路由节点相互连接 起来的一种单芯片系统，各个处理器之间通过网络进行近似符合 TCP/IP 协议的数据包 交换（不是电路交换） 。如图 3 所示。我们的任务就是：对于任意一个多并行系统任务 流图，每个任务流图的运行性能各自有其 deadline 要求，如何将每个任务流图中的每个 子任务节点拓扑到某一个合适的处理器上来运行， 使整个多并行系统任务流图的每个单 系统任务都能满足其 deadline。我们首先建立了关于任务流图运行时间的数学模型，然
B． 找到一条“以真正面向解决主要矛盾为导向的芯片设计算法” 。 C． 在基于 IP-Reuse 的 SOC 系统集成芯片开发模式下，应用一系列以满足主要研发约 束为导向的软硬件划分与协同设计算法来进行软/硬架构设计。 2．软/硬件协同设计的作用： IP-SoC 系统架构规划的最主要部分是所谓软/硬件协同设计。 软/硬件协同设计的首 要任务是软/硬件任务划分，或边界划分。大体来说，软/硬件任务分配比例的改变 对各种研发约束因素条件的影响如表 1 所示。由表 1 可见，采用合理的软/硬件协 同设计方案，对以真正面向解决主要矛盾约束为设计导向的芯片设计至关重要！ 在以下各节中，我们将就如何针对不同的系统需求进行软硬件规划作具体介绍。 二、关于系统任务流图： 对于系统任务流图的科学数学形式，简单说： A． 一个系统任务流图由一系列节点和节点间的有向连线组成， 每个节点代表一个 系统子任务（FFT 、JPEG、Viterbi decoder 、etc ） ，两节点间的连线代表了数据 传递流向。 B． 任何一个系统任务都可表示为单任务流图的形式。 C． 多个、并行的系统任务可以由多个并行的系统任务流图来表示。 D． 如果，有多个不同的系统任务，但是每次只有一个被执行，则可用多分支系统 任务流图来表示。各系统任务之间为时间互斥关系。 三、单任务流图的软/硬件协同设计方法：
4
广泛地说， 一个多并行系统任务流图的软/硬件协同设计方法是一件非常复杂的事情 （NP 完全问题） 。一个多并行系统的芯片架构上通常需要包含多个微处理器及与之相应的互 连结构。采用多处理器的理由如下： 1． 每个处理器都需要通过软件编程来完成某种实际的任务，因此多处理器的采用从 本质上是在允许芯片的多用途性。以处理器群为主的芯片架构设计本质上是一个 2． 通用平台的架构设计。 多处理器从本质上成倍增加了系统任务的并行性，更适合运行一个多并行系统任 务流图。 任何事物都是双刃剑， 多处理器为子任务的并行分配提供了极大的空间和选择余地， 但 是也为到底采用一种怎样的算法来进行多并行系统任务流图面向处理器群的合理任务 分配和调度带来了难题。简单说，问题的数学模型如下： 现有数个系统任务流图需要并行执行， 每个任务流图的运行各自有其不同的性能要 求（deadline） ，如果用一个多处理器芯片来运行它，如何通过软件规划将每个单任 务流图中的每个子任务节点拓扑到 某一个合适的硬件处理器上来运行， 使整个多并行系统任务流图的各个 单 系 统 任 务 都 能 满 足 其性 能 要 求 （deadline） 。 对于每个单任务流图中的每个子任务节 点，主要考虑两点问题： 一是如何分配 （用哪一个处理器来运 行它） ， 二是如何调度 （何时在所选的处理器 上运行它） 。 考虑因素大致有如下几点： A． 哪个处理器对该节点的执行速 度最快；
SOC 设计领域的核心技术——软/硬件协同设计
文/汤磊 摘要： 基于 IP 库的 SOC 必将是今天与未来微电子设计领域的核心。它既是一种设计技术，也是一 种设计方法学。 一块 SOC 上一定会集成各种纯硬件 IP、 和作为软件载体的 IP（MCU、 DSP， etc ） 。因此，作为一种软/硬件平台，面向系统需求的软/硬件协同设计技术与方法一定是决 定 SOC 设计成败的最关键因素。针对这一问题，本文从阐述软/硬件协同设计对 SOC 芯片 开发的关键作用开始， 根据我们的研究与实践结果， 具体详细展开讨论了如何针对不同的系 统需求抽象进行软/硬件规划与协同设计。 关键词： 软/硬件协同设计、SOC、系统任务流图、硬件、软件。 一、导言——软/硬件协同设计对 SOC 芯片开发的关键作用： 1．研发约束因素间的矛盾与平衡： 满足预定的功能需求永远是芯片设计的最终目标。 在满足功能需求这一目标外， 还 有很多约束条件需要同时考虑。 我们需要在各种矛盾约束中寻求一种尽量达到平衡与和 谐的设计结果。 芯片设计最终必须能占领市场、取得利润，并要考虑到产品的可持续发展问题。制约芯 片设计方案的各种因素如图 1 所示。所有这些研发约束因素之间相互矛盾、彼此制约。 参照图 1，就第一层的宏观 3 因素之间的作用而言： A． 如果为了考虑产品的可持续发展问题而要在设计中着重考虑 “芯片的可重配置性与 多应用性” ，在“设计约束”要求不变的情况下，必然要耗费更多的“人力资源与