不可不知的几种真实设计环境中的系统设计

　　对基于SoC系统设计正确方法的争论非常激烈。是传统的寄存器传送级（RTL）流程？还是C语言行为模型的高级综合？减少了代码生成的知识产权（IP）重用方法又怎样呢？

　　对于设计团队应该怎样从需求分析到制造实现，每个专家都有自己的观点。每一观点都基于自己的偏好，过去的经验，或者——EDA供应商本身会考虑产品供货情况。但是在很多真实环境中，所有这些观点可能都是不相干的。

　　原因很简单：大部分系统设计——据网站embedded.com最近的一项研究，55%的设计并不是新设计。它们实际上是对某类现有设计的修改。这一事实意味着，实际设计过程不仅仅取决于某些方法专家的建议，而且还要考虑需求的变化特性，以及设计团队能够得到的数据。结果可能是从形式驱动的修订过程，直至彻底的修改，甚至还有不可预测的改动等。通常是，结果实际对整个系统重新设计：不是因为改动的范围，而是因为没有重用规划，也没有能够管理改动的方法。

　　在本文中，我们将与方法专家和实际设计人员进行讨论，当系统需求变化时，到底会怎样，有没有一种一致的方法。然后，我们将在几种真实设计环境中应用这种工作方法，通过它来建议应采用怎样的设计过程，怎样使其更好的工作。

　　一些分类

　　至少在三种不同的环境下会出现衍生设计（图1 ）。最明显的是，现有设计的一系列需求变化定义了新项目后：例如，新功能、新外设，或者新的性能指标等。

　　

　　图1.衍生设计分类

　　而至少还有其他两类。一类是使用平台设计，例如谷歌的Android平台。Cadence的系统开发包产品市场集团总监Frank Schirrmeister特别指出了德州仪器的开放多媒体应用平台（OMAP），这是一个很好的例子。他观察到，OMAP平台定义的扩展平台几乎含有应用领域中能够想到的所有系统。设计团队通过把未使用的模块拿到平台之外来产生某种例化，在某些情况下，重新优化得到的设计。

　　第三类是相关的：使用参考设计。这一过程实际上是衍生设计的一个例子，但却是重要的方法，它不同于自己修改现有设计，也不同于应用一个平台。

　　对于这三种情形，只有第一种可以被分类为衍生设计。基于平台的设计和基于参考的设计一般被认为是新设计。但所有这三种都有共同的特性。它们从一个已经完成的设计开始，然后，针对现有规范来对比新设计需求。它们找到与现有设计的不同，然后进行实施。

　　第一步：有哪些变化？

　　这些设计过程都从一些新需求开始。每一过程的第一步是找到新需求和现有设计之间的不同点。理论上，这是一个严格的过程。我们可以通过对比最初的需求文档和修改后的需求文档来找到这些不同。但是在很多情况下，设计团队无法使用现有设计最初的、当前的、正确的需求文档。我们将在本文的后面讨论这些情形。

　　我们理论过程的下一步是将每一需求变化分成行为、结构和参数三类。行为变化——系统功能的变化，这是最常见的，据embedded.com研究，它占据了衍生设计的一半以上。有趣的是，目前自动化设计工具为它们提供的支持很少，只是提供一些表格。

　　作为对比，结构变化指出了系统硬件或者软件的某些改变：例如，操作系统的变化，增加或者去除了硬件模块，或者改变了模块之间的互联等。在某些应用中，例如通信基础设施，系统I/O会经常变化。Altera设计工作专家Kevin Weldon评论说：“我们一直和客户一起工作，实现他们的目标工作频率。但是现在，我们看到更多的变化出现在I/O中。客户希望确定不会出现I/O阻塞。”

　　参数变化以可测量的指标标明变化量：例如，响应时间、带宽、供电电流，以及材料成本等。通过某些硬件和软件模块的需求文档直至其含义，很容易找到这些变化，但是很难跟踪。

　　找到相关性

　　在理想的环境中，从几种相容的观点看，存在一个最早的设计——这是我们从中获得新系统的设计。我们不仅仅会有形式需求文档，而且还有行为模型——可能同时以更抽象的C代码以及会话级版本的形式提供。我们还会有硬件和软件的模块级体系结构模型。对于实际实现，会有RTL和软件代码。

　　在这种环境中，下一步是观察。我们通过修改行为模型来满足行为需求的变化。结构需求的变化会触发对IP或者互联，甚至是软件功能的调整。参数变化会导致实施层面代码的修订。

　　在每种情况下，我们都会有可追溯和设计无关文件，以确定我们进行的调整会怎样影响设计的其他部分（图2 ），因此，例如，如果我们修改数据结构的定义或者设计中某一部分信号的带宽，那么，我们就会知道，这些修改会影响设计中的哪些区域。工具会帮助我们保存从需求到实现的所有文档。

　　

　　图2.可追溯性简化了需求向工作声明的转换

　　每次调整后，我们会在适当的抽象级重新进行仿真，以验证修改后的设计现在能否满足新需求。然后，把这种修改传递到后面的底层抽象层，重新优化，直到我们的新设计通过了验证。

　　Schirrmeister指出，这种理想化的过程非常依赖于两组其他的数据，但不能保证可以使用这些数据。首先是使用场景。在正确的使用场景中，我们可以限制对修改后的设计进行验证，特别是对用户比较重要的模式和输入。如果没有使用模型，我们需要确定新设计在所有可能的实际环境下都满足现有以及修改后的需求。

　　其次是足够的测试台，针对整个系统和关键子系统。在实际中，测试台体现了人类语言文档无法表示的需求。很多设计团队认识到这方面的不足，重新建立系统测试台，这一项目规模与系统设计本身一样大——如果不能提供第三方SoC等关键元器件的数据，其规模会更大。