SoC设计验证技术发展综述

SoC设计验证技术发展综述

原著:张志敏 傅 亮
中国科学院计算技术研究所<信息技术快报>

引 言

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

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

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

SoC验证研究内容

SoC验证工作比较繁杂。
Janick Bergeron给“验证”下的定义是“证明一个设计的功能是否正确的过程”。
SoC的验证工作贯穿整个设计流程，从行为级HDL 设计，一直到芯片设计定案之前都需要做足够多的验证工作，当前验证工作已经占整个设计工作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验证工作提供重要质量保证，它规划如何来验证一个设计，主要包括以下内容：

         对模块和顶层的测试策略

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

        用到的验证工具和流程

        仿真环境的定义和搭建

        关键的验证点

        验证工作结束的标准

一个高质量的验证计划使得验证工程师可以更早地开发标准测试程序环境。
这种并行的开发验证环境，能尽早给验证团队一个明确的目标，也是保证验证可重用（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 、RTOS 及应用测试程序（包括驱动程序）。
首先做功能验证，验证是否满足要求；其次做软硬件性能验证；
第三做系统级基准测试（自顶向下验证策略），抽取特定功能，编制测试向量/程序，定义对错条件，覆盖所有功能，形成基准测试程序（反复迭代），用于模拟仿真。

3.2.3 模拟仿真

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

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

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

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

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

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

3.2.4 FPGA验证

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

FPGA 验证成为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）技术，会更加易于发现设计中的错误。