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

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

       第一步：有哪些变化?

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

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

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

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

       找到相关性

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

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

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

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

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