挑战是从找到有哪些变化开始。Altera设计专家Stacy Martin认为：“这一过程一般没有什么顺序而言。团队查看规范，找到特性或者接口的不足，然后，解决这些问题。”
现在要复杂一些。如果这些变化就含在现有实现的功能范围内，那就可以进行优化。也可能会超出现有设计的范围。或者，没有可信的需求文档时，设计人员应从系统级模型中正确的估算出性能，再次进行仿真以找到现有设计能够实现什么。实际上，团队应分析现有设计实现，以便重新生成该设计的需求。没有正确的使用模型和良好的测试台，在开始任何重新设计之前，团队会有很大的投入花在理解需求上。
这是很大的挑战。Martin说：“设计团队尝试尽可能多的重新使用设计。但是，您尽力尝试重用后，发现有时候最好还是从头开始设计。”
在真实环境中，实际上衍生设计有不同的方法。我们这里介绍的只是一小部分，这与设计人员找到需求变化的技巧有关。最初的设计人员在可重用性上的投入越大——在需求、行为、结构和实施层面上维持正确的设计版本;锁定使用模型;建立自适应测试台;这样，真实环境衍生设计就越能够接近其理想形式。
产品线工程
但真实环境总是在变化。目前，在军事、航空航天以及交通系统等某些应用中，需求可追溯性已经成为合同条款。非常复杂的系统设计以及高成本的一次性SoC设计投入也会有这种要求。在目前的很多行业中，成本和复杂度压力改变了系统设计的结构和方法。
新机遇意味着新的芯片设计。但是，设计团队越来越多的倾向于不再进行新设计。团队维持并继续重新应用系列知识产权内核以及完整的测试台，偶尔尝试新的金属掩模，很少使用全新的模板。对于每一设计是中心硬件/软件IP衍生的应用，实际上都是产品线工程。
是否成功取决于设计重用的自动化。IP装配程度也取决于能够严格追溯需求的方法，跟踪到测试台模块、硅片IP模块，以及软件模块，很容易从以前的系统级行为模型转到详细的硅片仿真和软件调试。这也是IBM的智能物理基础设施副总裁Meg Selfe的观点。
Selfe说，产品线工程的基础设施跨过了三个领域——工具、过程和最佳实践。其中，令人吃惊的是，一般并不缺少工具。Selfe报告说：“我们通常和具有很多工具的组织一起工作。难点是，并不是通过一致的平台来连接工具，因此，流程中有人工步骤。人工步骤导致出现中断。”
Selfe强调说，从传统的SoC设计转向产品线工程时——不仅要考虑下一设计需求，还要考虑企业是怎样运转的。Selfe建议，“确定在您的设计过程中要实现什么，找到原因，进行纠正。”
她注意到，目前，可追溯设计流程最大的不足出现在需求和测试台之间。今后，在早期系统建模文化中，系统模型与其测试台之间的差异会越来越小。目标应用环境中完整的系统模型成为某一子系统详细模型的测试台。需求变化会与设计和测试台中所有受影响的模块相关联。测试覆盖标准会直接转换成对设计需求覆盖范围的精确估算。设计会在自动关注是否满足需求变化上加大投入，而不是重新建立设计中没有变化的部分，也不会复制IP中已有的功能。
本文关键字：暂无联系方式嵌入式系统-技术，单片机-工控设备 - 嵌入式系统-技术
