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

admin

对基于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等关键元器件的数据，其规模会更大。
       
        在真实环境中
       
        对于一些设计人员组织而言，我们的理想化实例不一定具有可行性。汽车、交通、民用航空等领域的设计团队需要面对ISO 26262或者DO 178B等标准，要求设计和测试台中的每一单元都能够追溯到需求文档的控制单元。这些设计团队能够找到设计中的哪一部分需要进行测试，甚至进行修改以符合需求的变化。他们可以指出哪些模块需要在测试台中进行修改。这一开始就需要很大的投入。
       
        但是在大部分实际设计中，很难实现形式需求的可追溯性。这种项目的可追溯性只存在于设计团队成员的大脑中。即使最初的设计人员还能够说出，是什么原因让他以某种方式来实现某一模块，但是，在有人向他提问之前，他可能已经离开公司了，或者不在这一行业中了。我们不得不质疑我们的理想场景怎样应用在这些真实环境中。
       
        在一个平台上
       
        考虑设计团队使用平台设计的情况。平台一般是由SoC供应商提供的，是系统设计的扩展，而Android是个明显的例外。您要针对这一体系结构进行的尝试都含在规范中。概念非常简单。建立您自己的需求，找到您不需要的部分平台，不用它们(图3 )。然后，根据需要来优化其他部分，以满足参数约束。
       
       
        图3.去掉部分平台，使平台设计满足特殊需求。
       
        但是这一概念也面临一些难题。首先，不一定有需求文档。因此，团队不得不猜测平台建立者的目的是什么，是否符合新需求。确定了不同点后，这就比较简单了。例如，Android能够适用于摄像机和麦克风。如果您并不需要这些，就可以把这些功能去掉。
       
        功能需求会更具挑战性。您可能需要一台摄像机来采集MPEG4视频。但是，您还需要四个ARM内核和一个DDR3 SDRAM接口吗?用户只是进行网页浏览，您还需要采集和压缩视频吗?使用模型和功能需求的缺乏会迫使您进行大量的系统级仿真，以发现哪些模块实际参与了您需要支持的工作。
        Schirrmeister观察到，“您要明确新需求到底意味着什么。我曾处理过一个项目，其视频处理器需要采用信箱格式。这听起来只是简单的增加输出格式。我们一开始没有认识到的是系统的工作方式，信箱格式使我们只有很少的时间对每一帧进行解码，因此，这对设计其他部分的性能要求很高。实际情况是理解需求变化的含义。”
       
        参数需求的挑战性更大。您不得不在RTL上采用芯片模型运行系统仿真，确定平台能否满足所需的规范要求。而且，几个层面的仿真模型、精确的使用模型以及大量的测试台都是实际设计平台的关键组成。
       
        修改上一次设计
       
        从平台开始进行工作，设计团队只需要把模块从平台中取出并进行优化，就可以确定能够满足需求。但如果是从以前的设计开始工作，或者难度更大的是，采用第三方参考设计开始工作，情况又会怎样呢?原理不变。但是在真实环境中，设计团队在现有设计上一般不会有跟踪需求，也可能没有良好的系统或者模块级仿真模型，或者完全适用的测试台。方法取决于技巧。
       
        挑战是从找到有哪些变化开始。Altera设计专家Stacy Martin认为：“这一过程一般没有什么顺序而言。团队查看规范，找到特性或者接口的不足，然后，解决这些问题。”
       
        现在要复杂一些。如果这些变化就含在现有实现的功能范围内，那就可以进行优化。也可能会超出现有设计的范围。或者，没有可信的需求文档时，设计人员应从系统级模型中正确的估算出性能，再次进行仿真以找到现有设计能够实现什么。实际上，团队应分析现有设计实现，以便重新生成该设计的需求。没有正确的使用模型和良好的测试台，在开始任何重新设计之前，团队会有很大的投入花在理解需求上。
       
        这是很大的挑战。Martin说：“设计团队尝试尽可能多的重新使用设计。但是，您尽力尝试重用后，发现有时候最好还是从头开始设计。”
       
        在真实环境中，实际上衍生设计有不同的方法。我们这里介绍的只是一小部分，这与设计人员找到需求变化的技巧有关。最初的设计人员在可重用性上的投入越大——在需求、行为、结构和实施层面上维持正确的设计版本；锁定使用模型；建立自适应测试台；这样，真实环境衍生设计就越能够接近其理想形式。
         
        产品线工程
       
        但真实环境总是在变化。目前，在军事、航空航天以及交通系统等某些应用中，需求可追溯性已经成为合同条款。非常复杂的系统设计以及高成本的一次性SoC设计投入也会有这种要求。在目前的很多行业中，成本和复杂度压力改变了系统设计的结构和方法。
       
        新机遇意味着新的芯片设计。但是，设计团队越来越多的倾向于不再进行新设计。团队维持并继续重新应用系列知识产权内核以及完整的测试台，偶尔尝试新的金属掩模，很少使用全新的模板。对于每一设计是中心硬件/软件IP衍生的应用，实际上都是产品线工程。
       
        是否成功取决于设计重用的自动化。IP装配程度也取决于能够严格追溯需求的方法，跟踪到测试台模块、硅片IP模块，以及软件模块，很容易从以前的系统级行为模型转到详细的硅片仿真和软件调试。这也是IBM的智能物理基础设施副总裁Meg Selfe的观点。
       
        Selfe说，产品线工程的基础设施跨过了三个领域——工具、过程和最佳实践。其中，令人吃惊的是，一般并不缺少工具。Selfe报告说：“我们通常和具有很多工具的组织一起工作。难点是，并不是通过一致的平台来连接工具，因此，流程中有人工步骤。人工步骤导致出现中断。”
       
        Selfe强调说，从传统的SoC设计转向产品线工程时——不仅要考虑下一设计需求，还要考虑企业是怎样运转的。Selfe建议，“确定在您的设计过程中要实现什么，找到原因，进行纠正。”
       
        她注意到，目前，可追溯设计流程最大的不足出现在需求和测试台之间。今后，在早期系统建模文化中，系统模型与其测试台之间的差异会越来越小。目标应用环境中完整的系统模型成为某一子系统详细模型的测试台。需求变化会与设计和测试台中所有受影响的模块相关联。测试覆盖标准会直接转换成对设计需求覆盖范围的精确估算。设计会在自动关注是否满足需求变化上加大投入，而不是重新建立设计中没有变化的部分，也不会复制IP中已有的功能。