原因是多方面的，这些原因导致出现了各种各样的系统模型，如图1所示。有时候，仅仅是因为软件团队希望尽早开始设计工作。原理上，规划人员可以把软件分成与硬件无关规模较大的部分，以及与硬件功能相关而规模要小很多的部分。(Android等平台强化了这种不同，应用程序完全与硬件无关)。然后，设计人员能够在服务器自带工具上开发硬件相关代码，使用服务器功能替代目标系统的应用程序接口(API)。这种API替代本身就是一种系统建模。

 

图1.系统模型中的抽象层

 

    但是，随着系统设计的集成度越来越高，他们需要把详细的硬件行为放到应用层中，包括延时和能耗等。这种发展趋势导致一些经验丰富的设计人员开始怀疑硬件无关软件这种观念。Mike Dini是FPGA设计公司Dini集团的创始人，在今年的设计自动化大会(DAC)原型开发讨论组中阐述了“软件设计人员如果没有实际硬件就无法取得真正进步”这一令人注目的观点。相似的，Tensilica的资深产品专家Andrea Kroll在系统建模DAC讨论组中发表了自己的看法，“在华为，我们尝试了软件驱动的系统开发。但是，软件团队在没有硬件时，并不知道怎样开始工作。”这些怀疑观点导致设计团队在设计早期便构建详细的硬件模型，以便软件团队能够开始工作。

 

系统研究

 

    由于系统越来越复杂，规划人员很难预测最终产品会怎样工作。传统的表格模型甚至最好的SoC数据表都不足以回答关键问题：数据包吞吐量实际是多少?应用程序性能会满足用户的预期吗?能接受电池寿命或者散热吗?有时候，回答这类问题的唯一方法是开发非常详细的系统模型，利用模型来研究用户案例和体系结构替代方案。

 

    系统建模的第三种应用是系统验证，这种应用可能看起来不太引人注意。软件的优势是明显的。Xilinx研究实验室的Austin Lesea在DAC系统建模组中发表评论说：“您可以在C语言中进行大量的软件验证。当您需要周期精确标准时，问题就来了。”软件验证需要精确的可执行硬件模型。

 

    但是，需求已经超出了软件调试。Cadence资深设计师Stuart Swan在讨论组对此发表不同看法：“我们需要改变我们的观念。我们应该把更多的系统验证提高到更高的抽象级，重新使用更抽象的模型来生成底层模型。”这一方法要求在开发原型之前，在各种抽象级上验证系统模型功能，很多情况下，甚至是某些IC涉及到的寄存器传送级(RTL)。

 

    有些专家说，早期验证不仅仅是尽早找到设计错误，还有很重要的结果。测试台是会话发起器和校验器，进行随机测试，可以重用验证事物级模型开发的基本工具，将其应用于更详细的模型上，甚至是物理原型。通过这种方式，系统设计团队不仅避免了在设计期间多次重新开发相同的测试台，而且还可以在设计过程中尽早开始调试测试台。此时，团队进行详细的系统验证，测试台应该非常稳定。

但是，我并没有进行SoC开发

 

    您会说，所有这一切听起来很合理。但是，如果我们的设计团队购买了专用标准产品(ASSP)，而不是设计自己的SoC，情况会怎样?我们要使用模型，应该怎么办?这里有几种回答。

 

    对于系统设计团队，最直观的方法是编写非常抽象的事物级模型，他们只需要在数据表级理解ASSP及其周围的芯片。在这一等级足以理解系统的工作，并与系统进行通信，研究使用案例。对于以后更复杂的建模工作，这可以用作工作台。

 

    理想情况下，如果可以使用ASSP，很明显的下一步是硬件原型设计，采用芯片供应商已经设计好并调试过的开发套件来进行开发。如果没有开发套件，甚至连硅片也没有，或者系统设计还没准备好支持部分原型，那么，还有别的选择。

 

    正如ARM设计技术副总裁John Goodenough在建模讨论组中所建议的，一种选择是，在您的前一代SoC上使用开发套件，仔细的实现各种不同应用。取决于这些不同应用的差异程度，例如，从功能和用户案例研究到性能建模，甚至是某些驱动程序的开发等，可以一直使用这些原型。这有助于几代ASSP共享存储器和总线体系结构，只需要进行很小的改动，就能够加速设计实现。

 

虚拟原型

 

    那么，如果既没有您计划使用的ASSP，也没有非常相近的器件，该怎么办呢?当您已经快完成了硬件原型开发，但是需要提高对系统内部的可视化程度，您应该怎么办呢?芯片供应商通过系统级虚拟原型来回答这些问题，如图2所示。

图2.虚拟原型工具将不同级别的模型连接至统一的调试工作台中

 

    理想情况下，系统虚拟原型会是一组模型，在几种抽象级上精确的表示系统(请参考工具条：每一目标模型)。原型会提供已经开发好的调试和软件执行接口，提供很好的方法将组件加入到系统模型中。

 

    这一想法并非不切实际。Frank Schirrmeister是Cadence系统开发产品市场资深总监，他认为，越来越多的IC供应商构建了复杂SoC的虚拟模型，帮助客户围绕芯片模型开发全系统虚拟模型。在某些情况下，这些模型实际上成为IC数据表。Schirrmeister评论说，我们将模型提供给客户，这些模型通常包括事物级和加密RTL视图，硅片供应商的现场应用工程师还为客户提供帮助。芯片模型成为系统开发人员完整系统模型的一部分，也是硅片和系统设计团队之间的通信手段。实际上，当FPGA供应商Altera和Xilinx最近推出集成了CPU群的FPGA后，他们出于这一目的，都为新芯片提供了虚拟模型。

 

设计人员实际使用什么

 

     在DAC系统模型建模讨论组中，EDN的EDA编辑、主持人Brian Bailey询问小组成员，他们的系统建模实际是什么情况。答案反映了不同设计团队的各种需求，以及他们的各种观点。

 

     运动研究(RIM)公司的资深建模专家Frederic Risacher描述了大部分开发人员通常会面临的环境。我们不设计IC。Risacher解释说：“我们购买硅片，然后通过软件来突出我们的产品优势。”

 

     Risacher说，RIM不设计自己的硅片这一事实使得设计团队的建模策略比较复杂，但是基本上不会改变。工作不是从硬件建模开始，而是从软件开始。Risacher说：“至少在我们得到硅片之前的九个月，甚至是在得到虚拟原型之前，我们就开始开发过程和线程模型。然后，尽快开发功能精确、周期近似的硬件模型。”

 

      Risacher继续解释了RIM在这些模型上依靠其IC供应商。但是在这种关系上存在一个基本问题。芯片设计人员把他们的可综合RTL代码作为其IC的定义模型。但是，不能直接从RTL获得RIM需要的更抽象的模型。Risacher解释说：“因此，所有的都来自规范，而不是RTL。”

 

    RIM出于几种不同的目的来使用这些模型。在设计早期阶段，重点是理解软件对硬件的要求。Risacher提醒说：“硅片和用户需求之间的不同要求对硬件进行改动。您会尝试预测这些问题。”当系统设计整合到一起时，RIM团队转到更详细的模型，用于系统调整——例如，设置缓冲深度，还用于研究新想法。结果是功能强大的工具组，但是，存在管理难题。Risacher说：“我们在三种不同的领域中有四种不同的模型。这些模型的每一个都可以分别进行提取、验证和维持。

 

     Qualcomm的首席工程师Richard Higgins从硅片供应商的角度讲述了一个相似的案例。Higgins说；“我们使用系统模型来预测硬件的行为，尽早开始软件开发。”问题是，要实现这两个目标需要很多不同抽象级。Higgins解释说：“我们使用完整的系列模型，包括，结构、功能、行为和接口级抽象。此外，我们会有一些可执行SysML，还涉及到一些可综合SystemC。”

 

     和RIM相似，Qualcomm面临保持模型连续性这一难题，与硅片团队在RTL上有相同的看法。Higgins建议说，这方面最重要的最佳实践是，为所有不同的模型维持一个公共验证途径。但这很难。他说：“目前，还没有真正的体系结构和软件模型公共验证途径。”

 

    Tensilica的Kroll说，甚至IP开发人员也面临相似的问题。她说：“在开发IP子系统时，对于多核设计，我们在早期软件开发、互联分析和性能验证中使用系统模型。”这一工作需要从指令集仿真器到数据流发生器的所有一切，以便采用注释时序对硬件模块进行建模。Kroll建议说：“您应该知道使用模型的目的，确定各种抽象级的组合，以及您所需要的精度。”

总结

 

    几个不同设计团队的经验表明，即使是使用商用ASSP的系统设计团队，系统级建模都有很大的优势。使用模型，软件开发团队在能够使用硬件原型之前，尽早开始工作。这样，系统团队尽早查看系统行为、性能，以及能耗等，从而降低风险。使用系统模型，初步规划怎样构建系统测试台，可以尽早开始系统验证。

 

    “但玫瑰都有刺”。一些不知名的系统设计团队很难甚至不可能从ASSP供应商那里得到模型和支持。这些团队可能不得不从数据表描述中获得他们自己的IC模型。系统模型需要进行验证，正如系统本身自己那样。所有不同的系统模型应保持一致性，这非常重要。但这是很大的挑战，因为，不同的模型一般由不同的工程师手动得到，有时候还有不同的来源。不同的模型还存在于不同的工具环境中，一般不具有互操作性，可以由不同的团队使用。考虑到这些问题，建模工作不应受限于资源，本身也不应成为完整的设计工程，这一点非常重要。

 

    既能够发挥优点，又解决了难点问题，全面的系统建模计划并不是每一设计的最佳解决方案。但是，由于系统越来越复杂，更多的设计都会需要模型。尽早熟悉该技术是很明智的，而不应该等到您确定“我们应该对此进行建模”时才想起这一技术。