基于ESL并采用System C和System Verilog的设计流程

　ESL解决方案的目标在于提供让设计人员能够在一种抽象层次上对芯片进行描述和分析的工具和方法，在这种抽象层次上，设计人员可以对芯片特性进行功能性的描述，而没有必要求助于硬件（RTL）实现的具体细节。

当今，芯片设计需要进行深入的系统级仿真，以确保设计的体系架构合适均衡。在绝大多数情况下，所进行的这些仿真还要求在芯片的仿真模型上运行大量的软件， 以覆盖所需的功能。为了让这些仿真具有合适的执行性能，架构设计正在向电子系统级（ESL）解决方案发展。本文探讨了一种基于SystemC和 SystemVerilog的设计流程如何满足极为复杂的硬/软件系统级芯片（SoC）的设计周期和降低风险的目标。

　　复杂性催生ESL方法学

为了探讨ESL在设计流程中的作用，我们首先看一下当今的主要设计原则。下面的图1所示是一个十分典型的芯片。目前，这类SoC的一大部分是采用IP 模块进行组装的。这些模块部分来源于以前的设计，其它是从内部IP库获取的，或者是由外部IP提供商所许可使用的。当然，SoC中还包含了需要重新创建以 加入关键性功能的模块。

据普遍预计，对于下一代90纳米和65纳米

设计而言， IP的使用将进一步增加。SoC还将包含多个可编程部件，例如中央处理器（CPU）和数字信号处理器（DSP）。有了这些部件和众多的（甚至更大的）IP 模块，为了SoC设计的成功，在性能、功耗和芯片制造成本之间通过快速组装、仿真和分析各项体系结构方案寻求最佳平衡的能力正在变得越来越关键。

除了硬件设计任务以外，软件设计任务也正在成为SoC设计流程中一个不可或缺的组成部分。传统上，软件设计任务标准情况下只在芯片的硬件原型已经提供 后才执行。例如，在无线领域，这种方式经常导致产品推出时间计划的延迟，原因是“软件尚未完成”。为了解决这个问题，一种“虚拟原型”的概念出现了。虚拟 原型是目标芯片的一种高速（20MHz以上）事务处理级模型，这个模型让软件开发工作在硬件原型完成前数个月前就可以开始了。

　　新兴的SoC设计流程

图2所描述的设计流程有利于引导SoC开发人员尽力解决这些难题。这一设计流程以ESL流程为起点，包含三项紧密相关的行动——产品规格确定、体系架 构设计以及软件执行平台的开发。这个ESL流程的一项关键要求是它催生了一种硬件和软件并行开发的流程，为需要设计的新逻辑模块提供了详尽的规格，并提供 事务处理级的虚拟原型，而软件开发任务就可以在这一原型上执行。

ESL阶段之后是RTL设计/验证和软件开发任务的并行执行，这样在创建了硬件原型（要求提供RTL）的同时，也能够提供必需的软件。

与此类似，在芯片物理设计完成，代工厂即将交货之时，绝大多数或全部的所需软件均已经准备好并经过验证，从而确保大幅缩短最后的硬件/软件集成阶段。

　　事务处理级建模——ESL的关键

事务处理级建模提供了用于构建上述虚拟原型的关键技术。系统的事务处理级模型描述了系统各个功能单元之间的抽象操作（事务处理）。典型情况下，这些事务处理是各个功能单元之间交换的整个的数据结构（或对象）上读取/写入或发送/接收操作。

事务处理级模型的仿真速度比RTL模型快出若干个数量级。首先，它不对每一个硬件信号的功能进行建模，而是在抽象数据类型（可能代表了许多单个信号） 上操作的模型，从而实质性地加快了仿真的速度。第二，通过使用抽象数据类型来代表RTL内多时钟周期的数据传输，甚至可以让仿真的速度增加更快。因此，将 这些因素结合起来，TLM模型比同等的RTL模型的运行速度快出100倍至1000倍以上都是常见的，这个速度已经快到足以运行相当大的软件。

当今，在RT上的抽象层次已经十分明确，但TLM尚未达到这样的程度。实际上，适当的TL抽象层次经常取决于应用领域和运行仿真的首要目的。某些应用 要求周期上的精确性，例如对具体的高速缓存器特性的分析。而某些应用甚至可能要求在开发流程中与RTL模型建立部分关联，而其它应用（典型为软件开发任 务）只需要功能上的精确度。

目前，SystemC和SystemVerilog均得到了广泛应用，并由IEEE和其它工业组织进行了标准化，得到了由各家EDA供应商提供的工具的广泛支持。而将SystemC和SystemVerilog组合起来，能够最大范围地解决可能出现的对事务处理级的建模问题以及满足工程师的偏好，并提供一套从ESL至RTL验证的完整解决方案。

　　SystemC

SystemC是一种灵活的基于对象的结构化建模语言，设计用于对包括TLM在内的多种抽象层级进行建模。SystemC以C++库来实现，其中将并发性结合进传统C++语言框架中。

虽然SystemC语言相对较新，但SystemC的采用具有重要的意义。原因之一是，在SystemC成为标准以前， 许多公司和大学已经在采用以前的各自专有C/C++库在事务处理级上对系统进行建模。这样，SystemC就向这些设计人员提供了一种实现他们的事务处理 级方法学的工作标准方式，并提供了一种更为便捷的途径交换系统级IP和知识。第二个原因是，SystemC使各种（基于C语言的）工具和仿真器相对较为容 易的集成，例如，集成微处理器核心用的指令集仿真器（ISS），并具备借助C++大量的专家，采用这一语言方便地来加快工作。

关于SystemC的典型使用情况，根据最近有关SystemC的出版物以及各项调查中得知，例如SystemC用户中的绝大多数正使用这种语言来执行建模（68%）、体系架构开发（68%）、事务处理级建模（56%）和硬件/软件协同仿真（56%）。

SystemC最初在OSCI（开放SystemC发起组织）中发展而来，它的语言参考手册（LRM）最近已经获批成为IEEE 1666标准（见参考文献[1]）。

SystemVerilog

SystemVerilog是一种相当新的语言，它建立在Verilog语言的基础上，并新近成为下一代硬件设计和验证的语言。SystemVerilog结合了来自

Verilog、VHDL、C++的概念，还有验证平台语言和断言语言，也就是说，它将硬件描述语言（HDL）与现代的高层级验证语言（HVL）结合了起 来。由于拥有这样的概念以及它与Verilog的向上兼容性，使其对于进行当今高度复杂的设计验证的验证工程师具有相当大的吸引力。能够采用 SystemVerilog进行验证的另一项成功因素是方法学手册和架构的更早可用性，例如在SystemVerilog的验证方法手册（VMM）(见参 考文献[2])中所描述的验证平台方法（这一方法是由ARM和Synopsys合作开发的）。

上述这些特点，以及SystemVerilog是一项得到了所有主要EDA供应商支持的IEEE标准的事实，使得SystemVerilog实质上成为了硬件设计和验证的首选语言。

　　SystemC与SystemVerilog特点比较

就SystemC和SystemVerilog这两种语言而言， SystemC扩展了C++在硬件方面的适用范围，而SystemVerilog扩展了Verilog在基于对象和验证平台方面的适用范围。而这两种语言 均支持诸如信号、事件、接口和面向对象的概念，但每一种语言又均拥有自己明确的应用重点：
●SystemC对于体系架构开发编写抽象事务处理级（TL）模型、或执行建模来说最为有效，特别是对于具有很强C++实力的团队和有基于C/C++ IP 集成要求（如处理器仿真器），以及为早期软件开发设计的虚拟原型来说，更是如此。
●SystemVerilog对于RTL、抽象模型和先进的验证平台的开发来说最有效率，因为它具备了执行这方面任务所需的基础架构，例如受限制随机激励生成、功能覆盖或断言。
●SystemVerilog显然是描述最终的RTL设计本身的首选语言，不仅在于其描述真实硬件和断言的能力，还在于对工具支持方面的考虑。

这并不意味着每种语言不可以用在不同的应用中。 实际上，SystemC可以用于验证平台和描述RTL结构，而SystemVerilog也可以用于编写高层事务处理级模型。但是，每一种语言都用于自己 的重点应用时，它们可以达到最佳的效率。这点对于复杂的项目特别适用，在这种项目中，不同的任务分属于不同的组，通常有不同的技能要求。注重实效的解决方 案以及符合设计团队的多种技术要求的方法是同时使用SystemC和SystemVerilog来开发和验证当今设计流程需要的虚拟原型的事务处理级模 型。

　　集成的仿真环境

将SystemC和SystemVerilog集成在同一个解决方案中，归根结底是需要提供混合SystemC和SystemVerilog的仿真和 调试环境。这项集成的核心在于能够直接从SystemVerilog任务中调用SystemC成员的能力，反之亦然，可以从SystemC成员中直接调用 SystemVerilog任务。很明显，这样就要求在SystemC和SystemVerilog的时间概念之间达到同步。

为了建立SystemC和SystemVerilog的高效集成解决方案，让诸如信号和事务处理这样的基层概念在语言设计中，尽管已经在各自的语言中 进行了各自方面的优化，在语义上又能够跨越语言分界实现有效的映射。实际上，SystemC和SystemVerilog的标准化组织，OSCI和 Accellera，已经认识到在这两种语言之间建立有效接口连接机制的需求。

SystemC和SystemVerilog集成的核心支持了混合层级结合的建模，而有能力创建部分处于事务处理级和部分处于具体硬 件级的仿真模型。因此，集成让SystemC和SystemVerilog能够在不同的抽象层级上进行通讯。

一个典型的应用实例是将一个SystemVerilog RTL模块集成到整个系统的一个SystemC模型中，例如，为了实现早期集成检查。由于SystemC典型情况下应用在事务处理级，就有必要使用一个作为抽象层级之间桥梁的适配器（图3）。

这些适配器的目的在于将事务处理转换成信号操作，而反之亦然。这样，就可以让设计的一部分在事务处理层次上进行仿真，而另一些部分在具体硬件层级上进行仿真。采用这种方法，设计人员拥有对于仿真具体层级的完全控制。

这些适配器可以用SystemC或以SystemVerilog（图3）来编写。使用一项SystemC适配器是相当直接的方式，并且以将 SystemC信号映射到SystemVerilog信号为基础，反之亦然。而以SystemVerilog来缩写转换器时，典型情况下能够提供更高的性 能，但要求在SystemC与SystemVerilog之间建立事务处理级接口。

　　SystemC与SystemVerilog之间的事务处理级接口

在System

C中，将通讯与功能区隔开来的目的导致了接口概念的形成。在SystemVerilog中，与接口类似的概念也进行了设计。虽然 SystemVerilog接口和SystemC接口并不完全一致，它们在语言上具有足够的匹配度，能够提供这两种语言之间的有效事务处理级连接。 SystemVerilog接口是一种能够将信号捆绑在一起的结构，并且具有与SystemC接口完全一样的接口方法。通过使用 SystemVerilog基于DPI的服务层，验证引擎可以直接将SystemC接口映射在SystemVerilog接口上，从而可以从 SystemVerilog验证平台中直接调用SystemC事务处理级模型。

例1所示为在参考文献[3]中所述的以SystemC编写的simple_bus的模块接口部分。它描述了接口方法burst_read。而 simple_bus的整个代码可以在任何SystemC 2.x版本的安装版本中找到。但是，simple_bus是如何实现此接口方法的，例如，使用了什么样的总线带宽或使用了哪一类型的仲裁，对于该接口方法 的调用者来说都是不可见的，因此，可以在体系结构开发中很方便地进行改变。

例2所示为simple-bus的一个SystemVerilog接口部分，这个总线可以直接映射到如例1所示的SystemC接口。为了确保 SystemVerilog接口向SystemC成员的正确映射，其实现通过一个SystemVerilog的直接过程接口（DPI）服务层来完成。

这样就可以实现如例3所示的从SystemVerilog验证平台中直接调用SystemC对象的接口方法。

有了这种能力，验证团队就可以充分利用SystemVerilog的验证平台技术来验证SystemC事务处理级模型，并可以使用SystemC事务 处理级模型作为硬件验证流程的参考模型，这点在图4中进行了概略的描述。此外，SystemVerilog功能覆盖和断言可以用于实现完整的由覆盖率驱动 的事务处理级模型的验证解决方案，为SystemC模型提供新型和前所未有的验证能力。

Synopsys的Discovery验证平台是这类集成验证环境最好的实例之一，它同时集成了对SystemC和SystemVerilog的支 持。它提供了高性能的RTL验证，包括仿真和形式分析、体系架构开发以及提供一个对广泛的测试平台所需的基础支持，来处理事务处理级建模的验证。

通过观察目前的SoC设计，我们可以大致了解为什么ESL工具和方法在控制设计成本和帮助准时发布产品方面起到了关键性的作用，并且了解到那些影响到SoC性能和成本的关键性决策是在项目早期通过采用事务处理级建模方法建立的虚拟原型做出的。

SystemC是一种非常适合于创建、仿真和分析设计的事务处理级模型的语言。SystemVerilog是理想的硬件实现语言。SystemC和 SystemVerilog的良好结合能支持混合（事务处理和硬件）模型。此外，这项结合让SystemVerilog的强大验证能力能够在事务处理级模 型的验证工作中充分发挥，而相同的验证平台还可以适用于硬件验证工作。

SystemC和SystemVerilog结合起来提供了当今先进芯片所需的一套从ESL至RTL设计流程的真正的、基于标准的解决方案。通过将 SystemC和SystemVerilog结合到一个单一的验证环境中，可以高效地建立和验证分析体系结构所需要的事务处理级虚拟原型，并在设计工作的 早期开发内嵌的软件。