数字集成电路论文ESL方法学的SOC设计与验证技术综述

数字集成电路论文

题目：ESL方法学的SOC设计与验证技术综述

系名称：信息工程

专业：电子科学与技术

班级：一班

学号：

姓名：

年月日

本文讨论电子系统级(ESL)设计和验证方法学在系统级芯片(SoC)设计中的应用。ESL 设计是能够让SoC 设计工程师以紧密耦合方式开发、优化和验证复杂系统架构和嵌入式软件的一套方法学，它还提供下游寄存器传输级(RTL)实现的验证基础。已有许多世界领先的系统和半导体公司采用ESL 设计。他们利用ESL 开发具有丰富软件的多处理器器件，这些器件为创新终端产品获得成功提供必需的先进功能性和高性能。

为什么中国的电子产业将会对ESL 感兴趣？因为中国领先的电子公司正在经历一场对他们竞争力非常关键的转型。通过采纳技术创新策略，中国将成为纯粹的知识产权(IP)提供者，而不是纯粹的IP 消费者。那些拥有知识产权的公司将持有通向IP 库的钥匙。

为成功地执行创新策略，中国公司必须采用创新领先公司所使用的先进设计方法学。ESL 设计正是这样一种方法学。它已经被诸多国际系统和半导体公司采用。在中国，大唐已率先在中国3G 手机技术－TD-SCDMA 开发中采用ESL 设计，清华大学及其一些产业合作单位也采用ESL 方法学开发先进的地面数字多媒体广播应用。

ESL 发展的背景

电子系统级（ESL ，Electronic System Level ）设计方法和ESL 工具相对来说是一种较新的方法学和工具。虽然这种方法学的提出和工具的开发在20世纪90年代已经开始，但由于相关工具无法配合及市场需求较少，在过去几年EDA 产业一直居于不太起眼的位置。随着90nm 技术的出现，上亿门规模电路的开发及系统的复杂度得剧增，ESL 设计逐渐受到重视，但真正能够执行设计流程所需的ESL 工具，直到最近几年才开始陆续上市。

ESL 设计指系统级的设计方法，是从算法建模演变而来的。ESL 设计已经演变为嵌入式系统软、硬件设计、验证、调试的一种补充方法学。这些嵌入式系统包括SoC 系统、FPGA 系统、板上系统、多板级系统。

ESL 设计以抽象方式来描述SoC 系统，给软、硬件工程师提供一个虚拟原型平台，用以进行硬件系统结构的探察和软件程序的开发。在ESL 设计中，系统的描述和仿真的速度快，使设计工程师有充裕的时间分析设计内容。ESL 设计不仅能应用在设计初期与系统架构规划阶段，也能支持整个硬件与软件协同设计的流程。

引言

随着工艺能力和设计能力的快速发展，为了满足嵌入式系统市场对于成本、功能和功耗的要求，SoC(System on-a-Chip)设计技术已经成为一种发展趋势。众所周知，迄今为止在集成电路发展过程中，摩尔定律（单芯片上所能集成的晶体管数目每18个月翻一番）一直在起作用，因此SoC 的规模和功能在不断急剧膨胀，使得设计验证日益重要，向业界提出了巨大挑战，已成为了整个SoC 设计流程的瓶颈[1]

。

目前芯片一次投片成功率只有35%左右，造成芯片重复投片的主要原因就是验证不够充分。SoC 设计的验证需要投入的资源已占整个设计资源的60%~80%。1999年当VSIA 1举行验证专题会时，许多世界级验证专家得出结论：验证是件困难的事（hard ）,几周后更把结论更正为“Verification is not hard,it is very hard”。现在愈来愈达成共识：单一的设计工具难以解决验证问题，而需要一系列复杂的工具和技术，来减少设计错误数，使之达到可接受的程度。

SoC经过6、7年的发展，有了广阔的市场。SoC验证研究领域在验证技术、验证方法学、测试码提取、验证描述语言、IP核重用验证、验证流程及验证评估方面取得了长足进步。但总体而言验证技术已经落后于设计和制造能力，模拟和验证工作成为整个SoC学科发展的制约瓶颈，给提高设计生产率造成了障碍。如何构建一种更快更好的设计验证方法学是当前SoC业界所关注的问题。

SoC概述

什么是SoC

SoC即系统级芯片，是一种专门用来描述高集成度器件的术语，也称SLI(System Level Integration)。SoC将系统的主要功能综合到一块芯片中，本质上是在作一种复杂的IC设计。SoC是集成电路设计和工艺的发展产物，它可以将整个系统集成在一个芯片上。

1995年美国的调查和咨询公司Dataquest对SoC的定义是，包括一个或多个计算引擎（微处理器/微控制器/数字信号处理器）、至少10万门得逻辑和相当数量的存储器。随着时间的不断推移和相关技术的不断完善，SoC的定义也在不断发展完善。现在的SoC中，要在芯片上整体实现CPU、DSP、数字电路、模拟电路、存储器及片上可编程逻辑等多种电路，综合实现图像处理、语音处理、通信协议、通信机能、数据处理等功能。

SoC按用途的不同可以分为两种类型，一种是专用SoC芯片，是专用集成电路（ASIC）向系统级集成的发展。另一种是通用型SoC芯片，将绝大部分部件，如MCU、DSP、RAM、I/O等集成在芯片上，同时提供用户设计所需的逻辑资源和软件编程所需的软件资源。

SoC的构成

在目前的集成电路设计理念中，IP是构成SoC的基本单元。所谓IP可以理解为是满足特定规范，并能在设计中复用的功能模块，又称IP核（IPCore）

从IP的角度出发，SoC可以定义为基于IP模块的复用技术，以嵌入式系统为核心，把整个系统集成在单个（或少数几个）芯片上，从而完成整个系统功能的复杂的集成电路。目前的SoC集成了诸如处理器、存储器及输入/输出端口等多种IP。

SoC设计方法的发展与挑战

未来的SoC中将会用到更多的处理器，以便更加灵活的支持不断出现的新应用。设计方法也会改进来应对新的挑战，它会对设计工具提出新的要求，产生新的设计技术。

1.系统级设计

SoC的设计应该是一个软件、硬件协同设计的过程，这也是一个SoC系统一个非常重要的标志。然而，传统的集成电路设计方法一般都是将系统级设计分为两个阶段：系统级软件开发阶段和电路级硬件设计阶段。需要特别指出的是，软件开发和硬件设计往往是相对独立进行的。在系统级，软件开发人员使用如C/C++等的高级编程语言进行系统描述和算法仿真，并分析系统在软件层面的各项指标，撰写系统设计书，然后移交给硬件设计工程师。在电路级，硬件设计师首先要花大量的时间理解系统设计书，之后才能利用VHDL或Verilog 硬件描述语言进行电路设计。在此手工转换的过程中，可能还会引入人为的错误因素。另外，为了验证软件开发的正确性，必须等到硬件全部完成之后才能开始软件测试和系统集成，大大延长了设计的进程。传统的设计方法使得软件和硬件之间很难进行早期的平衡和优化，并

有可能严重影响开发成本和开发周期。根据有关统计从系统级设计到电路级设计所花费的时间一般是系统级设计所花时间的3倍左右。因此在系统级设计与电路级设计之间架设一座桥梁，提高设计效率，保证设计成功，已经成为集成电路设计领域极为迫切的任务。

在更高抽象层次上的建模，如系统级建模，可以使硬件及软件工程师在同一个平台上设计。业界领先的公司采用电子系统级设计方法是因为它利用系统级建模，使设计工程师能够及早进行软件开发，实现快速设计和派生设计、快速硬件验证及快速硬件/软件验证。它还可以提供来验证下游RTL实现符合系统规范的功能测试平台。此外，ESL设计工具可以综合针对应用优化的定制处理器，以及快速开发和实现先进算法。

对于一个大型软件开发任务，尽可能早地开始软件开发很有必要，即使原有软件的复用程度很高。采用基于高级语言的ESL设计方法学，SoC架构工程师可以生成一个用来仿真的SoC行为模型，如果需要，还可以生成仿真SoC周期精确时序的高级模型。这个模型称为事物模型（TLM），它使软件设计工程师在RTL设计或者硅原型完成前的几个月就可以着手进行软件开发工作。

高层次的抽象使得多种验证可以更早地进行，减少了产品的面世时间，降低了产品的成本，并且可以更早地发现设计错误。

随着高级抽象层的事物级建模标准化，自动成设计的高层次综合技术正在向普及性发展。基于事物级建模的系统设计将成为重要的发展趋势之一。

2.基于可配置处理器设计与使用的SoC设计方法

当前普遍的SoC设计方法都是基于以一个或多个高性能通用RISC处理器核（如ARM、MIPS等）为核心，构成一整个片上系统体系架构。然而，通用处理器核的性能往往不能满足如信号处理、视频图像、协议实现、信息安全等数据密集型处理任务。现有的典型设计方案，大多是在SoC片上加载一个算法加速单元，通过硬件连线逻辑的设计方法来实现。但也可以看到，这样的设计方法会导致芯片面积和成本的急剧上升，同时算法加速单元的效率也可能会由于处理器核本身功能上非专用的缺陷而受到限制。

从前面的系统级设计方法可以看到，要最有效地发挥SoC的性能，尽可能早地与软件结合确定设计方案是一种行之有效的方法。而如果能够对软件设计出专用性强、算法实现效率高的特殊处理期核，则会更方便的实现SoC的高效性。于是，一种新型的处理器内核，可配置的、可扩展的微处理器核（Configurable Extensible Microprocessor Core）应用而生了。这样的处理器往往通过一个生成器或编译器直接生成，这种过程的特点是可以将高层次的应用需求以指令集、代码或者高级语言直接转换为高效的硬件设计和软件工具，从而极其方便地为设计者如何使用、整合、互联形成处理器提供了积极有效的帮助，也为以这样的一个或多个处理器为核心构成SoC提供了极大的参照便利，更重要的是能使其尽早结合软件应用来实现处理器和SoC性能的优化。

使用这些可配置、可扩展的专用处理器作为SoC系统中子系统的底层构件，完全可以根据软件的需求作合适的调整，省略其中不必要的硬件组成部分，使得部分合适的软件能对其专用或共享，而其他软件程序则可以根据自身要求再“裁减”一套新的处理器核。从这点可以看出，处理器的效率肯定会得到大幅度的改善。

诚然，现今也有许多也有相当多的设计者使用多个高性能通用微处理器构成SoC，同样也能提高性能。但需要指出的是，这样环境下，至少一个处理器核的功能肯定得不到完全发挥，其内部对应用而无言应用的逻辑会使整个速度和功耗指标收到损失。但是专用可配置处理器在这点的优势上较为明显，自动生成的微处理器核只包含应有所需要的功能，因此基础指令集中一定不含有应用目标中不会使用和无关的功能，由此相应带来的面积、功耗和速

度等方面的负担也会得到相应的减少。因此，使用可配置、可扩展的专用处理器作为SoC 的功能模块，会成为SoC设计中的一种必然选择。

3.未来的SoC

高集成度的SoC设计只是这个问题中重要答案的一部分。在广泛的产品类型中，设计者努力争取将系统所有的重要数字功能，如网络开关、打印机、电话、数字电视等做在一个芯片上。同样，SoC设计也力争将所有的重量级功能，如高效通信信号处理、图像和视频信号处理、加密和其他应用加速功能，集到一个芯片上。

以前，绝大多数这样的功能都是靠使用专用的硬件加速器来实现。这就是得设计周期长、成本高，而且产品寿命短。以电子系统级设计为代表的先进的SoC设计方法的出现，使得多个处理器或DPS和可配置的处理器为中心的复杂SoC设计变得简单。而灵活的软件方案可以更有效地解决这个多变、复杂的应用问题。可以预测，以多个处理器和可配置的处理器为中心的复杂SoC必将成为未来的主流。

4.SoC的设计流程

用SoC 技术设计系统芯片，一般先要进行软硬件划分，将设计基本分为两部分：芯片硬件设计和软件协同设计。芯片硬件设计包括：

1．功能设计阶段。

设计人员产品的应用场合，设定一些诸如功能、操作速度、接口规格、环境温度及消耗功率等规格，以做为将来电路设计时的依据。更可进一步规划软件模块及硬件模块该如何划分，哪些功能该整合于SOC 内，哪些功能可以设计在电路板上。

2．设计描述和行为级验证

能设计完成后，可以依据功能将SOC 划分为若干功能模块，并决定实现这些功能将要使用的IP 核。此阶段将接影响了SOC 内部的架构及各模块间互

动的讯号，及未来产品的可靠性。决定模块之后，可以用VHDL 或Verilog 等硬件描述语言实现各模块的设计。接着，利用VHDL 或Verilog 的电路仿真器，对设计进行功能验证（functionsimulation ，或行为验证 behavioral simulation ）。注意，这种功能仿真没有考虑电路实际的延迟，但无法获得精确的结果。

3．逻辑综合

确定设计描述正确后，可以使用逻辑综合工具（synthesizer ）进行综合。综合过程中，需要选择适当的逻辑器件库（logic cell library ），作为合成逻辑电路时的参考依据。硬件语言设计描述文件的编写风格是决定综合工具执行效率的一个重要因素。事实上，综合工具支持的HDL 语法均是有限的，一些过于抽象的语法只适于做为系统评估时的仿真模型，而不能被综合工具接受。逻辑综合得到门级网表。

4．门级验证（Gate-Level Netlist Verification ）

门级功能验证是寄存器传输级验证。主要的工作是要确认经综合后的电路是否符合功能需求，该工作一般利用门电路级验证工具完成。注意，此阶段仿真需要考虑门电路的延迟。

5．布局和布线

布局指将设计好的功能模块合理地安排在芯片上，规划好它们的位置。布线则指完成各模块之间互连的连线。注意，各模块之间的连线通常比较长，因此，产生的延迟会严重影响SOC 的性能，尤其在0.25 微米制程以上，这种现象更为显著。

SoC 验证研究内容

SoC 验证工作比较繁杂。Janick Bergeron 给“验证”下的定义是“证明一个设计的功能是否正确的过程”。SoC 的验证工作贯穿整个设计流程，从行为级HDL 2

设计，一直到芯片设计定案之前都需要做足够多的验证工作，当前验证工作已经占整个设计工作70%左右。图1是SoC“设计缺陷（BUG ）”分布情况，其中功能缺陷超过60%。可见SoC 验证工作重点应在功能验证上。

SoC 验证研究内容很多，如：IP 核/模块级验证（Block-Level Verification ）、系统级验证（System-Level Verification ）、仿真验证（Simulation ）、软硬件协同验证(Hardware/Software Co-verification)、等价性检查（Equivalent checking ）、静态时序分析和时序验证（Static timing analysis & Timing Verification ）、版图验证（Physical verification ）等。随着验证技术的逐步发展，验证方法由最初的直接测试向量生成（Directed Test Vector Generation ）,到约束随机

测试(Constrainted Random Test),再到覆盖驱动验证(Coverage- driven Verification),一直到最新的基于断言的验证方法(Assertion-based Verification),各种验证方法在不断创新发展。

SoC 验证流程与技术

SoC 验证流程与计划

SoC 的验证工作始终贯穿整个设计流程。从阶段划分上说，SoC 验证可以分为功能验证、等价性验证、静态时序分析、动态时序分析和版图验证等几个主要阶段，如图2所示。

有了SoC 验证流程还很不够，需要验证计划（Verification Plan ），这为SoC 验证工作提供重要质量保证，它规划如何来验证一个设计，主要包括以下内容：

1． 对模块和顶层的测试策略

2． 组成标准测试程序（Testbench ）的各个组件的定义和规范，如BFM 3

、总线监视器

（Bus monitor ）等

3． 用到的验证工具和流程

4． 仿真环境的定义和搭建

5． 关键的验证点

6． 验证工作结束的标准

SoC 验证流程图

功能验证内容

功能验证（Functional Verification ）是验证中最复杂，工作量最大同时也是最灵活的部分，包括模块/IP 核级验证、系统级验证、模拟仿真等。

模块/IP 核级验证

任何SoC设计均由一系列模块组成。模块可能是自己开发，也可能是重用第三方的IP 核。不论哪种情况，在系统集成前做IP核验证工作是必需的。模块/IP核级验证流程如图3所示，软性检查(Link Checking)主要检查代码语法、可综合性、变量未初始化、结构化可支持性和端口失配性等；规范模型检查(Formal Model Checking)主要做设计特征遗漏性检查，以在早期发现错误状况，尤其对控制流设计效果明显，通过设计文档非正式说明、与设计者非正式沟通等途径抽取特征疑问，逐一验证，消除缺陷；功能验证(Functional V erification)

主要利用基准测试向量基于事件或基于时钟进行功能验证，如黑盒测试、白盒测试和灰盒测试（gray-box）等；协议检查(Protocol Checking)主要验证是否违犯总线协议或模块互连约定，按照协议逐一检查并比较结果；直接随机测试(Directed Random Testing)通过随机产生数据、地址、控制等信号检查功能正确性，减少模拟仿真工作量；代码覆盖率分析(Code Coverage )主要根据模拟仿真时统计代码被执行数，可以按陈述句、信号拴（Toggle）、状态机、可达状态、可触态、条件分支、通路和信号等进行统计分析，以提高设计可信度。

系统级验证

系统级验证主要确认芯片体系结构满足所赋予的功能/性能要求。系统级设计阶段将用户需求转换成功能/性能要求，并实现行为/功能设计，然后映射到相应的体系结构上（设计输入、硬IP核、软IP核、软/硬件划分、性能分析、总体优化、性价比评估等反复叠代），最后进行系统级验证，如图4所示。

在系统级验证中，往往要构建虚拟目标系统，如中科SoC芯片在实施验证时，将其所有对

外接口挂接许多虚拟IP核，同时编制了BIOS 4

、RTOS

5

及应用测试程序（包括驱动程序）。

首先做功能验证，验证是否满足要求；其次做软硬件性能验证；第三做系统级基准测试（自顶向下验证策略），抽取特定功能，编制测试向量/程序，定义对错条件，覆盖所有功能，形成基准测试程序（反复迭代），用于模拟仿真。

协议验证

为了验证协议行为，必须明确地定义所有可能发生的操作类型。强烈建议，将所有操作类型列出表格，并且对于每一种操作类型至少开发一个类型至少开发一个测试。在大多数SoC设计中，不是所有（协议支持的）可能的操作类型都是允许的。操作类型通常被限制在很小的数目，因此确定所有支持的操作类型并为它们开发各种测试不是一个巨大的任务。为

了将来在任何操作中使用多组数据进行协议行为的自动化测试，在片上总线中可以使用简单和规则的结构，如总线监视器。

通过在总线控制器中构建总线监视器，用于验证事务处理协议的可观测性和可控制性都得到增强。内嵌总线监视器允许对适当次序下的精确操作进行控制和观测，并且有利于调试。但是应注意，当在总线控制器中构建了总线监视器时，需要总线功能模型而不是全功能模型。

在模块化设计中，接口模块的行为描述和RTL 级描述可以与核的内部逻辑分开，以易于总线监视器接口之间的交流，并在行为级和RTL 级进行仿真。

在这个方法中，除被测试的核之外，每一个核的总线功能模型都取代了其物理网表。对于每个接口模块，使用各种核的总线功能模型及被测核的行为的或RTL 模型，建立一个RTL 级得测试平台以生成测试序列。该测试平台中确定性的测试数据（激励）应根据使用者希望的操作数据给出。使用这种方法，可以进行全局总线上的接口与事务处理协议的仿真，当数据从一个核直接传输到另一个核而不经过全局总线时，也可以进行点到点的接口仿真。

这种方法的一个局限，就是对于所有可能的数据值和每个接口收到的所有数据序列，都无法确保其行为正确；因此，随机数据也应该作为激励的一部分。使用随机数据需要特殊考虑，使核的逻辑不会被强行进入非法状态，并且在核的输入端不出现非法数据序列。为此，或者在随机数据产生时使用过滤器，或者在接口处设置一个可以抑制非法数据的检查器。

响应检查应由人工方式进行，因为即使测试使用确定的数据，也很难表征期望的数值；因此，自动检查只限于一般结果，例如检查非法的输出操作和状态机循环。

FPGA 验证

随着半导体制造技术不断的前进和相应的设计规模以及复杂度飞速的增长，使得传统的软件仿真工具已不可能完全解决功能验证的问题。而且一些需要处理大量实时数据的应用（如视频）也越来越多，因此要求能够在接近实时的条件下进行功能验证[2]。

FPGA 8验证成为SoC 设计流程中重要的一个环节,一方面作为硬件验证工具，可以将所设计的RTL 级代码综合实现后写入FPGA 芯片进行调试检错；另一方面可以进行软件部分的并行开发，在验证板上检测驱动程序、启动操作系统。FPGA 验证的流程相当于一个FPGA 设计的主要流程，它主要分为设计输入、综合、功能仿真（前仿真）、实现、时序仿真（后仿真）、配置下载、下载后板级调试检错这几个步骤。总的来说，FPGA 验证是整个SoC 设计中一个重要而且有效的验证步骤，用来改进RTL 级设计代码，验证功能的正确和完整性，提高SoC 流片成功率。

功能验证方法

直接测试向量生成

直接测试向量生成（Directed Test V ector Generation ）遵守WYTWYVO 原则，即

What-Y ou-Thought-of-is-What-Y ou-V erify-Only ，所以需要产生大量的测试向量才能覆盖尽可能多的各种传输组合。这不但要耗费大量的时间和精力，而且很难达到满意的覆盖率。另外

这种方法还需要手工检查结果，只适合比较简单的模块或系统，已经逐渐淡出。

约束随机测试

直接测试向量往往需要手工加入，这样难免会遗漏一些考虑不到的情况，因此有学者提出了随机测试（Random Test）的方法。这种方法让测试向量随机生成，因此在足够长的时间内可以产生大量的随机向量，这样可以比较容易地覆盖到一些考虑不到的情况。

但随着验证技术的发展，验证工程师发现这种完全随机的验证方法一般需要比较长的时间才有可能达到令人满意的覆盖率，而且有些设备的传输类型只有几种，这样就导致把时间浪费在了一些根本不需要产生的测试向量上，所以又提出了约束随机测试(Constrained Random Test)这种新的验证方法，这种方法可以有效的缩短验证时间，在短时间内达到令人满意的覆盖率。

由于约束随机测试可以约束验证环境中各个层次上的属性，所以这种方法可以更真实地反映一个实际的系统。使用约束，特别是带权值（在整个测试中出现的比例）的约束可以很容易地按事先确定的比例产生验证工作所需要的具有某些特殊属性值的一类或几类测试向量，而且如果加入记分板（Scoreboard）技术和自检测（Self -check）技术，会更加易于发现设计中的错误。

覆盖驱动验证

覆盖率一般表示一个设计的验证进行到什么程度，也是一个决定功能验证是否完成的重要量化标准之一。覆盖主要指的是代码覆盖（Code Coverage）和功能覆盖（Functional Coverage）。代码覆盖可以在仿真时由仿真器直接给出，主要用来检查RTL代码哪些没有被执行到。使用代码覆盖可以有效地找出冗余代码，但是并不能很方便地找出功能上的缺陷。

使用功能覆盖则可以帮助我们找出功能上的缺陷。一般说来，对一个设计覆盖点的定义和条件约束是在验证计划中提前定义好的，然后在验证环境中具体编程实现，把功能验证应用在约束随机环境中可以有效检查是否所有需要出现的情况都已经遍历。功能验证与面向对象编程技术结合可以在验证过程中有效地增减覆盖点。这些覆盖点既可以是接口上的信号，也可以是模块内部的信号，因此既可以用在黑盒验证也可以用在白盒验证中。通过在验证程序中定义错误状态可以很方便地找出功能上的缺陷。

基于断言的验证方法

在验证过程中，一般很难找出跨多个时钟周期、顺序相关的一系列操作的时序和功能是否有不符合规范的地方，为此研究出基于断言的验证方法(Assertion -based V erification)来推动验证技术发展。这种方法要用基于断言的验证语言，比如OpenV eraAssertion语言（OV A）、SystemV erilog Assertion语言（SV A）、Property Specification 语言（PSL）等。

使用断言可以很方便的对一个给定输入的设计的期望行为进行精确的描述，从而可以很方便的描述输入/输出行为、总线协议以及设计中的一些复杂的关系。基于断言的验证语言

9可以使用简单的语言结构来建立精确的时序表达式。这些表达式可以代表HDL或者HVL

中的事件（events）、序列（sequences）和事务（transactions）等。通过检查这些表达式是否发生，可以很简单地进行功能覆盖的检查，并且这种覆盖率分析是针对跨多个时序周期的一

个事件序列或者整个传输的，所以比传统的覆盖驱动验证的抽象层次要高。

传统覆盖分析要专门为覆盖分析而写大量的代码，而断言的覆盖分析可以直接使用在协议检查或者事件描述中用到的那些时序表达式，因此编码会更加灵活、简洁。在验证环境中使用基于断言的验证语言书写的模块（一般为Checker 和Monitor ）的可重用性优于用HDL 和HVL 写的模块，此外要结合仿真器在仿真环境中进行验证的工作，不过这些代码可以直接应用到形式验证（Formal V erifi- cation ）上。

形式验证

形式验证（Formal Verification ）主要是用来在覆盖所有可能的输入情况下检查是否与给定的规范一致。形式验证主要包括两部分：一是等价性检查（equivalence checking ），二是模型检查（model checking ）。等价性检查主要是检查两个门级网表（gate-level netlist ）之间是否一致，保证网表处理后不会改变电路的功能，或者保证网表能正确地实现RTL 代码所描述的功能，或者保证两种RTL 描述逻辑一致。这种方法主要是用来寻找实现（implementation ）中的缺陷，而不是设计中的缺陷。因此这种方法很难发现同时存在于两种要比较的描述中的固有缺陷 [3]。

模型检查主要是检查RTL 代码是否满足规范中规定的一些特性（properties ）。在规定这些特性时一般使用特性规范语言（Properties Specification Languages ），目前一般也使用基于断言的验证语言。由于这种方法可以在不需要仿真的前提下检查设计中所有可能出现的情况是否满足规定的特性，所以使用这种方法不会遗漏任何的边界情况（corner-case ）。但是随着设计复杂度的增加和特性的增多，状态空间（state space ）会成指数级增长，为了克服这一困难出现了一种新的验证方法——半形式验证（semi-formal verification ），如Synopsys 公司的Magellan 工具。这种方法把仿真技术的低复杂性和形式方法的完整性结合了起来。 时序验证

时序验证是用来避免时序异常的验证方法，主要包括静态时序分析（Static Timing Analysis ）和动态时序分析（Dynamic Timing Analysis ）。

静态时序分析(STA)根据设计规范的要求通过检查所有可能路径的时序，不需要通过仿真或测试向量就可以有效地覆盖门级网表中的每一条路径，在同步电路设计中快速地找出时序上的异常[4] 。静态时序分析可识别的时序故障包括：建立/保持和恢复/移除检查(包括反向建立/保持)、最小和最大跳变、时钟脉冲宽度和时钟畸变、门级时钟的瞬时脉冲检测、总线竞争与总线悬浮错误、不受约束的逻辑通道，还能计算经过导通晶体管、传输门和双向锁存的延迟，并能自动对关键路径、约束性冲突、异步时钟域和某些瓶颈逻辑进行识别与分类。时序分析工具目前主要有Primetime 、Time Craft 、Time Director 和SST Velocity 等。

动态时序分析主要指的是门级（或对版图参数提取结果）仿真。这种方法主要应用在异步逻辑、多周期路径、错误路径的验证中。随着设计向130nm 以下的工艺发展，只用静态分析工具将无法精确验证串扰等动态效应。通过动态时序分析与静态时序分析相结合可以验证时序逻辑的建立－保持时间，并利用动态技术来解决串扰效应、动态模拟时钟网络。

物理验证（Physical verification ）

物理验证主要是进行设计规则检测(DRC 10)、版图与原理图对照(LVS 11

)和信号完整性分

析。SoC 设计要求采用一种不受设计类型约束的物理验证工具，如Hercules ，来完成这两项任务，为制造复杂SoC 提供灵活性和保证。.

随着加工工艺的不断提高，带来了大量的信号完整性问题。互连线变得又细又高，线间距也越来越小，互连路径与相邻连线间存在的耦合电容成倍增加，因耦合产生的噪声与伪信号等串扰效应可能成为影响集成电路延迟的重要因素。此外，电流在经过电路时会产生阻性电压降（IR drop ）导致后面的门电路因电压降低而使其延迟增加，甚至达不到门槛电压。因此在STA 计算延迟时必须考虑串扰和电压降等对电路延迟带来的影响。这使时序验证越来越复杂，也越来越重要。

门级仿真

总线接口逻辑的门级网表应该进行功能和时序的验证。

形式验证可以用来验证门级网表的正确性。时序验证应使用验证流程，随后对延迟反标注的V erilog/VHDL 网表进行门级仿真。总线接口逻辑的门数一般比较少，因此，门级仿真可以有效地完成。

SoC 验证技术发展方向

在对IP 核进行验证时，传统的方法是，IP 核提供者在提供IP 核的同时也要提供该IP 核的测试向量和测试环境，使用这些测试向量和测试环境来验证测试结果是否正确。这种方法的缺陷在于，虽然这个IP 核本身设计是正确的，但是在一个SoC 中，每个IP 核并不是独立存在的，它与其他的IP 核之间必然存在数据交互和总线竞争，没有其他IP 核协同验证是很难接近真实情况的，这样的验证也是不完备的[5] 。在SoC 的实际设计过程中，设计上的问题很多都是在对SoC 进行系统仿真验证的时候才暴露出来，主要体现在IP 核与IP 核之间信号时序的不匹配。这样的错误的定位和更正所需工作量都比较大，造成验证效率低下。在一个实际系统中，经常会有几个IP 核同时发出请求让总线仲裁。但是由于C 语言和汇编语言不支持并行的操作，因此使用这些语言书写的测试程序只能串行地去控制每个IP 核，因而很难模拟这种多个IP 核并发的情况。而使用FPGA 进行系统级测试时，由于FPGA 对外输出有限，系统工作起来只能通过有限的输入输出引脚来辅助定位，对于设计中的错误较难定位和纠正。

SoC 验证与其他数字芯片相比最大的不同在于：因为SoC 中需要集成大量的IP 核，而且由于IP 核经常是来自于不同的供应商，使得它们的验证更加困难。有时候甚至需要对IP 核进行部分修改才能适合具体SoC 的要求。因此IP 核协同验证成为IP 核验证中的一个难点。IP 核提供商所提供的测试向量和测试环境很难重用在多个IP 核协同验证的环境下。供应商有时不提供IP 核的RTL 描述，只是给出行为级的描述和接口时序文档。这样的IP 核不能烧入FPGA 进行系统级验证，这就要求我们能提供一个系统的验证环境来解决多个IP 核协同验证的问题。同时，如果每一次系统级验证都要重新搭建验证环境、编写验证代码，从时间上和人力上都是无法接受的。由于SoC 设计中系统结构和大量IP 核存在着可重用性，在SoC 验证中也可以尽量重用以前的验证代码，使之适应新的设计要求，从而提高验证效率。

为了解决上述设计中的问题，可采用灵活可配置的集合了多种验证手段的系统验证平台，下图所示的中科SoC 验证平台。该平台综合使用直接测试、约束随机测试、形式化属

性检查和覆盖驱动验证等多种方法，进行一定量的仿真工作，通过观察时序属性检测报告、数据检查报告、覆盖数据报告和波形来判断是否完成了验证工作。

结语及SoC的发展前景

随着半导体制造技术不断的快速发展，SoC设计规模以及复杂度飞速地的增长。尤其是在进入深亚微米工艺后，SoC设计和开发遇到了大量的信号完整性和设计完备性问题，为了验证整个芯片的正确性必须要做大量的验证工作，而芯片的上市压力又要求验证工作必须在尽可能短的时间内完成，SoC验证正越来越成为整个设计流程中的关键部分，灵活可配置的集合了多种验证手段的系统验证平台日益重要。为此，业界一直在努力开发新的工具和方法，比如新出现的硬件仿真加速器（Hardware Emulator Accelerator），同时不断完善。

在德国慕尼黑举行的“欧洲设计自动化和测试大会（DA TE ）”的主题演讲中，韩国三星电子Jeong-Taek Kong（三星副总裁，半导体业务部门半导体研发中心CAE小组负责人）结合本公司的开发实例，讲述了SoC（芯片级系统）的相关课题，并对其未来发展做了展望。演讲的题目为“纳米时代的SoC：开发课题和无限潜能”。

Jeong-Taek Kong首先表示，半导体产业的发展过去主要受益于PC及便携产品，而现阶段的推动力则是IT产业，下一阶段的关键词将是“泛在（Ubiquitous）”。他指出，在当今纳米时代，1枚芯片上即可集成数亿个晶体管，设计技术人员已经能够通过半导体手段实现高级的系统理念，各类SoC令泛在社会的实现极具现实性。但SoC仍存在着如何降低耗电量和产品价格等诸多问题，从系统级设计，到制造技术，整个工序都必须取得突破。他强调说，尤其是EDA技术将是解决纳米元件物理性问题，以及系统复杂化问题的重要技术。

接着，他介绍了该公司开发的面向手机等领域的各种SoC产品。另外还对三星的技术开发实力夸奖了一番，他表示NAND型闪存尽管不属于SoC，却超越了摩尔法则，其集成度正以每年2倍的速度不断提高。同时他还指出，诸如质量不稳定和成品率下降等在工艺提高过程中所产生的问题正在日益显现，由此造成开发费用剧增。此外他还强调说，软件今后在开发费用中所占的比率将会不断增大。

随后，作为工艺发展过程中存在的重大问题，他举出了晶体管的后期单价（量产时）与最初6个月的初期单价（开发初期）之间的差距越来越大。从经济效益上来讲，这种差距包括技术性和战略性两个方面。在技术方面存在着设计效率、耗电量，以及DFM（可制造性设计,Design For Manufacturability）等课题；在战略性方面则存在着如何挖掘SoC关键性应用领域的问题，因此必须转变思维模式，进行创新。

在DFM方面，他还做了进一步的说明。介绍了通过引进统计学上的设计手法，提高成品率的案例。他表示将某种工艺的不稳定性数据反馈给设计人员这一点非常重要。在对低耗电量的研究方面，他举出了在移动产品领域使用MTCMOS，大幅降低泄漏电流的案例。此外，还介绍了通过TLM（Transaction Level Modeling）这种耗电量预测与优化手法，将耗电量降低56%的成功案例。对于设计效率方面的课题，他补充说ESL（Electronic System Level）设计必须要有进一步的发展。

他最后表示，大学、无工厂半导体开发商、EDA开发商和集成设备制造商（Integrated Device Manufacturer，IDM）之间的相互协作，对于SoC的顺利发展是必不可少的。他总结说，假如能把系统级设计、低耗电和验证等课题清理出来，并加以解决的话，SoC的未来将拥有无限的发展空间。

参考文献

[1] 柴远波张兴明著。现代SoC设计技术电子工业出版社2009.11

[2] 郭炜郭筝谢憧著。SoC设计方法与实现电子工业出版社2007.6

[3] Rochit Rajsuman 著于敦山盛世敏田泽译北京航空航天大学出版社2003.8

[4] 马光胜冯刚编著。SoC设计与IP核重用技术国防工业出版社2006.8

[5] 王道宪主编刘丽著。SoC原理、实现与应用国防工业出版社2005.2

[6] 赵鹏朱正学李金才著。SoC系统开发从实践到提高中国电力出版社2007.6

[7] 郭兵沈艳林永宏韩磊著。SoC技术原理与应用清华大学出版社2006.4