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

找到相关性

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

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

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

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

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

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

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

在真实环境中

　　对于一些设计人员组织而言，我们的理想化实例不一定具有可行性。汽车、交通、民用航空等领域的设计团队需要面对ISO 26262或者DO 178B等标准，要求设计和测试台中的每一单元都能够追溯到需求文档的控制单元。这些设计团队能够找到设计中的哪一部分需要进行测试，甚至进行修改以符合需求的变化。他们可以指出哪些模块需要在测试台中进行修改。这一开始就需要很大的投入。

　　但是在大部分实际设计中，很难实现形式需求的可追溯性。这种项目的可追溯性只存在于设计团队成员的大脑中。即使最初的设计人员还能够说出，是什么原因让他以某种方式来实现某一模块，但是，在有人向他提问之前，他可能已经离开公司了，或者不在这一行业中了。我们不得不质疑我们的理想场景怎样应用在这些真实环境中。

在一个平台上

　　考虑设计团队使用平台设计的情况。平台一般是由SoC供应商提供的，是系统设计的扩展，而Android是个明显的例外。您要针对这一体系结构进行的尝试都含在规范中。概念非常简单。建立您自己的需求，找到您不需要的部分平台，不用它们（图3 ）。然后，根据需要来优化其他部分，以满足参数约束。