SoC设计验证技术发展综述

引 言

随着工艺能力和设计能力的快速发展，为了满足嵌入式系统市场对于成本、功能和功耗的要求，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验证工作比较繁杂。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验证流程与技术

 

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

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

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

2． 组成标准测试程序（Testbench）的各个组件的定义和规范，如BFM[3]、总线监视器（Bus monitor）等

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

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

5． 关键的验证点

6． 验证工作结束的标准

一个高质量的验证计划使得验证工程师可以更早地开发标准测试程序环境。这种并行的开发验证环境，能尽早给验证团队一个明确的目标，也是保证验证可重用（re-used）的关键。为了得到一个高质量的验证计划，验证工程师要正确和充分地理解设计需求和规范，要与设计工程师及时地交互，这样才能保证验证计划的易读、易用和可重用。因此可以说一个好的验证计划可以有效提高验证效率，缩短开发周期，在SoC开发中有着重要的意义。

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

3.2.1 模块/IP核级验证
任何SoC设计均由一系列模块组成。模块可能是自己开发，也可能是重用第三方的IP核。不论哪种情况，在系统集成前做IP核验证工作是必需的。模块/IP核级验证流程如图3所示，软性检查(Link Checking)主要检查代码语法、可综合性、变量未初始化、结构化可支持性和端口失配性等；规范模型检查(Formal Model Checking)主要做设计特征遗漏性检查，以在早期发现错误状况，尤其对控制流设计效果明显，通过设计文档非正式说明、与设计者非正式沟通等途径抽取特征疑问，逐一验证，消除缺陷；功能验证(Functional Verification)主要利用基准测试向量基于事件或基于时钟进行功能验证，如黑盒测试、白盒测试和灰盒测试（gray-box）等；协议检查(Protocol Checking)主要验证是否违犯总线协议或模块互连约定，按照协议逐一检查并比较结果；直接随机测试(Directed Random Testing)通过随机产生数据、地址、控制等信号检查功能正确性，减少模拟仿真工作量；代码覆盖率分析(Code Coverage )主要根据模拟仿真时统计代码被执行数，可以按陈述句、信号拴（Toggle）、状态机、可达状态、可触态、条件分支、通路和信号等进行统计分析，以提高设计可信度。


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

在系统级验证中，往往要构建虚拟目标系统，如中科SoC芯片在实施验证时，将其所有对外接口挂接许多虚拟IP核，同时编制了BIOS[4]、RTOS[5]及应用测试程序（包括驱动程序）。首先做功能验证，验证是否满足要求；其次做软硬件性能验证；第三做系统级基准测试（自顶向下验证策略），抽取特定功能，编制测试向量/程序，定义对错条件，覆盖所有功能，形成基准测试程序（反复迭代），用于模拟仿真。


3.2.3 模拟仿真
在复杂SoC设计开发中，模拟仿真占整个验证工程师团队工作量的40~70[1]，由于成本和市场压力，寻找灵巧的仿真技术显得十分迫切。

功能仿真：主要关注模块-模块（IP核-IP核）间互连验证、系统总线协调性验证和标准规范兼容性验证等，由于复杂度高，可通过事件驱动和加速技术，如硬件加速器、模拟发生器和快速建模试验等来加速和简化仿真工作。

基准测试包：首先搭建SoC整体架构，然后将每一模块（IP核）经基准测试包挂接到系统总线上。这些基准测试包有利于缺陷的识别工作，但它们不是设计工作的一部分，而是为了验证而引入的。基准测试包测试向量来自于IP核供应商、直接随机产生、手工编制或由系统级测试捕获。

事件驱动仿真：使用比较普遍，像NC_Verilog、VCS等均支持，但受芯片规模和性能限制。首先设计代码被仿真工具所接受，其次编制基准测试向量（波形或RTL[6]），第三运行仿真，第四通过单步调试，错误定位、改正后可再次仿真。

时钟驱动仿真：在每一时钟结束时计算电路稳态响应，不考虑时序方面的问题，时序需要静态时序分析工具来验证是否满足要求。时钟驱动仿真比事件驱动仿真速度要快10~100倍，适合大规模电路仿真。

基于传输仿真：传输操作是指传输虚拟部件（TVM[7]）和设计模块间的数据或控制传递，简单的如访存读操作，复杂的如结构化数据包传递。首先获取或编制TVM，其次确定测试内容，第三步编译和连接，第四步进行仿真，第五步作输出分析，最后做功能覆盖分析。

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

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

3.3 功能验证方法
3.3.1 直接测试向量生成
直接测试向量生成（Directed Test Vector Generation）遵守WYTWYVO原则，即What-You-Thought-of-is-What-You-Verify-Only，所以需要产生大量的测试向量才能覆盖尽可能多的各种传输组合。这不但要耗费大量的时间和精力，而且很难达到满意的覆盖率。另外这种方法还需要手工检查结果，只适合比较简单的模块或系统，已经逐渐淡出。

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

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

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

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

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

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

使用断言可以很方便的对一个给定输入的设计的期望行为进行精确的描述，从而可以很方便的描述输入/输出行为、总线协议以及设计中的一些复杂的关系。基于断言的验证语言可以使用简单的语言结构来建立精确的时序表达式。这些表达式可以代表HDL或者HVL[9]中的事件（events）、序列（sequences）和事务（transactions）等。通过检查这些表达式是否发生，可以很简单地进行功能覆盖的检查，并且这种覆盖率分析是针对跨多个时序周期的一个事件序列或者整个传输的，所以比传统的覆盖驱动验证的抽象层次要高。

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

3.4 形式验证
形式验证（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工具。这种方法把仿真技术的低复杂性和形式方法的完整性结合了起来。

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

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

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

3.6 物理验证（Physical verification）
物理验证主要是进行设计规则检测(DRC[10])、版图与原理图对照(LVS[11])和信号完整性分析。SoC设计要求采用一种不受设计类型约束的物理验证工具，如Hercules，来完成这两项任务，为制造复杂SoC提供灵活性和保证。.

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

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验证中也可以尽量重用以前的验证代码，使之适应新的设计要求，从而提高验证效率。

为了解决上述设计中的问题，可采用灵活可配置的集合了多种验证手段的系统验证平台，如图3所示的中科SoC验证平台。该平台综合使用直接测试、约束随机测试、形式化属性检查和覆盖驱动验证等多种方法，进行一定量的仿真工作，通过观察时序属性检测报告、数据检查报告、覆盖数据报告和波形来判断是否完成了验证工作。







这类验证平台有以下优点：

1． 解决了IP核集成时多个IP核协同验证的问题；

2． 克服了传统验证方法中测试程序只能串行控制各个模块的缺点；

3． 建立了一个统一的可配置的系统测试环境，不需要像传统验证方法那样为每个IP核建立各自的测试环境，提高了验证代码的可重用性；

4． 不但可以验证RTL级的IP核，也可以验证行为级和门级的IP核；

5． 平台中综合使用了直接测试、约束随机测试、形式化属性检查和覆盖驱动验证等多种验证方法，使得验证更直观，效率更高。

结束语

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

参考文献

[5][1] Prakash Rashinkar, Peter Paterson,System on a Chip Verification: Methodology and Techniques, Kluwer Academic Publishers, 2001

[6][2] http://www.acro-da.com/products/c.htm

[7][3] Prakash Rashinkar,Peter Paterson,etc.,SYSTEM_ON-A-CHIP VERIFICATION Methodology and Techniques, KLUWER ACADEMIC PUBLISHERS, 2001

[8][4] 马凤翔 孙义和 。数字芯片设计的断言验证。中国集成电路杂志网 2004.3.24

[9][5] 黎声华 邹雪城 莫迟., 静态时序分析在数字集成电路设计中的应用。电子技术应用

[10][6]张宇弘，何乐年等。基于SOC典型结构的系统验证环境。微电子学，2002.1.

[11][7]F.Sforza,L.Battu“A Design for Verification Methodology” Quality Electronic Design, 2001 International Symposium

[12][8]Mark Litterick, Joachim Geishauser。“Robust Vera Coding for Gate-Level SoC Verification”SNUG Europe 2004

[13][9]OpenVeraTM Language Reference Manual : Assertions, Version 1.3, Synopsys, March 2003

[14][10] Constrained-Random Test Generation and Functional Coverage with Vera, synopsys

[15][11] A Survey:System-on-a-Chip Design and Verification Ali Habibi and Sofine Tahar

[16][12] Rindert Schutten “A layered approach for SoC verification ” SNUG 2002

作者简介：

张志敏
中科院计算技术研究所系统结构研究室 副主任、研究员、博士导师

傅 亮
中科院计算技术研究所系统结构研究室 博士研究生