真实环境中的系统设计

在真实环境中

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

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

在一个平台上

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


图3.去掉部分平台，使平台设计满足特殊需求。
Figure 3. Removing Parts to Adapt a Platform Design for Specific Requirements

但是这一概念也面临一些难题。首先，不一定有需求文档。因此，团队不得不猜测平台建立者的目的是什么，是否符合新需求。确定了不同点后，这就比较简单了。例如，Android能够适用于摄像机和麦克风。如果您并不需要这些，就可以把这些功能去掉。

功能需求会更具挑战性。您可能需要一台摄像机来采集MPEG4视频。但是，您还需要四个ARM®内核和一个DDR3 SDRAM接口吗?用户只是进行网页浏览，您还需要采集和压缩视频吗?使用模型和功能需求的缺乏会迫使您进行大量的系统级仿真，以发现哪些模块实际参与了您需要支持的工作。

Schirrmeister观察到，“您要明确新需求到底意味着什么。我曾处理过一个项目，其视频处理器需要采用信箱格式。这听起来只是简单的增加输出格式。我们一开始没有认识到的是系统的工作方式，信箱格式使我们只有很少的时间对每一帧进行解码，因此，这对设计其他部分的性能要求很高。实际情况是理解需求变化的含义。”

参数需求的挑战性更大。您不得不在RTL上采用芯片模型运行系统仿真，确定平台能否满足所需的规范要求。而且，几个层面的仿真模型、精确的使用模型以及大量的测试台都是实际设计平台的关键组成。

修改上一次设计

从平台开始进行工作，设计团队只需要把模块从平台中取出并进行优化，就可以确定能够满足需求。但如果是从以前的设计开始工作，或者难度更大的是，采用第三方参考设计开始工作，情况又会怎样呢?原理不变。但是在真实环境中，设计团队在现有设计上一般不会有跟踪需求，也可能没有良好的系统或者模块级仿真模型，或者完全适用的测试台。方法取决于技巧。

挑战是从找到有哪些变化开始。Altera设计专家Stacy Martin认为：“这一过程一般没有什么顺序而言。团队查看规范，找到特性或者接口的不足，然后，解决这些问题。”

现在要复杂一些。如果这些变化就含在现有实现的功能范围内，那就可以进行优化。也可能会超出现有设计的范围。或者，没有可信的需求文档时，设计人员应从系统级模型中正确的估算出性能，再次进行仿真以找到现有设计能够实现什么。实际上，团队应分析现有设计实现，以便重新生成该设计的需求。没有正确的使用模型和良好的测试台，在开始任何重新设计之前，团队会有很大的投入花在理解需求上。

这是很大的挑战。Martin说：“设计团队尝试尽可能多的重新使用设计。但是，您尽力尝试重用后，发现有时候最好还是从头开始设计。”

在真实环境中，实际上衍生设计有不同的方法。我们这里介绍的只是一小部分，这与设计人员找到需求变化的技巧有关。最初的设计人员在可重用性上的投入越大——在需求、行为、结构和实施层面上维持正确的设计版本；锁定使用模型；建立自适应测试台；这样，真实环境衍生设计就越能够接近其理想形式。

产品线工程

但真实环境总是在变化。目前，在军事、航空航天以及交通系统等某些应用中，需求可追溯性已经成为合同条款。非常复杂的系统设计以及高成本的一次性SoC设计投入也会有这种要求。在目前的很多行业中，成本和复杂度压力改变了系统设计的结构和方法。

新机遇意味着新的芯片设计。但是，设计团队越来越多的倾向于不再进行新设计。团队维持并继续重新应用系列知识产权内核以及完整的测试台，偶尔尝试新的金属掩模，很少使用全新的模板。对于每一设计是中心硬件/软件IP衍生的应用，实际上都是产品线工程。

是否成功取决于设计重用的自动化。IP装配程度也取决于能够严格追溯需求的方法，跟踪到测试台模块、硅片IP模块，以及软件模块，很容易从以前的系统级行为模型转到详细的硅片仿真和软件调试。这也是IBM的智能物理基础设施副总裁Meg Selfe的观点。

Selfe说，产品线工程的基础设施跨过了三个领域——工具、过程和最佳实践。其中，令人吃惊的是，一般并不缺少工具。Selfe报告说：“我们通常和具有很多工具的组织一起工作。难点是，并不是通过一致的平台来连接工具，因此，流程中有人工步骤。人工步骤导致出现中断。”

Selfe强调说，从传统的SoC设计转向产品线工程时——不仅要考虑下一设计需求，还要考虑企业是怎样运转的。Selfe建议，“确定在您的设计过程中要实现什么，找到原因，进行纠正。”

她注意到，目前，可追溯设计流程最大的不足出现在需求和测试台之间。今后，在早期系统建模文化中，系统模型与其测试台之间的差异会越来越小。目标应用环境中完整的系统模型成为某一子系统详细模型的测试台。需求变化会与设计和测试台中所有受影响的模块相关联。测试覆盖标准会直接转换成对设计需求覆盖范围的精确估算。设计会在自动关注是否满足需求变化上加大投入，而不是重新建立设计中没有变化的部分，也不会复制IP中已有的功能。