1、SoC 设计验证技术发展综述- 原创 2010-03-09 19:24:42 字号：大 中 小2010 年 02 月 28 日引言 随着工艺能力和设计能力的快速发展，为了满足嵌入式系统市场对于成本、功能和功耗的要求，SoC(System on-a-Chip)设计技术已经成为一种发展趋势。众所周知，迄今为止在集成电路发展过程中，摩尔定律（单芯片上所能集成的晶体管数目每 18 个月翻一番）一直在起作用，因此 SoC 的规模和功能在不断急剧膨胀，使得设计验证日益重要，向业界提出了巨大挑战，已成为了整个 SoC 设计流程的瓶颈1。目前芯片一次投片成功率只有 35 左右，造成芯片重复投片的主要原因就是验
2、证不够充分。SoC 设计的验证需要投入的资源已占整个设计资源的 6080。1999 年当 VSIA1举行验证专题会时，许多世界级验证专家得出结论：验证是件困难的事（hard）,几周后更把结论更正为“Verification is not hard,it is very hard“。现在愈来愈达成共识：单一的设计工具难以解决验证问题，而需要一系列复杂的工具和技术，来减少设计错误数，使之 qvod 邻家特工 英文达到可接受的程度。 SoC 经过 6、7 年的发展，有了广阔的市场。SoC 验证研究领域在验证技术、验证方法学、测试码提取、验证描述语言、IP 核重用验证、验证流程及验证评估方面取得了长足
3、进步。但总体而言验证技术已经落后于设计和制造能力，模拟和验证工作成为整个 SoC 学科发展的制约瓶颈，给提高设计生产率造成了障碍。如何构建一种更快更好的设计验证方法学是当前 SoC 业界所关注的问题。 SoC 验证研究内容 SoC 验证工作比较繁杂。Janick Bergeron 给“验证“下的定义是“证明一个设计的功能是否正确的过程“。SoC 的验证工作贯穿整个设计流程，从行为级 HDL2设计，一直到芯片设计定案之前都需要做足够多的验证工作，当前验证工作已经占整个设计工作 70 左右。图 1 是 SoC“设计缺陷（BUG）“分布情况，其中功能缺陷超过 60。可见 SoC 验证工作重点应在功能
4、验证上。 SoC 验证研究内容很多，如：IP 核/模块级验证（Block-Level Verification）、系统级验证（System-Level Verification）、仿真验证（Simulation）、软硬件协同验证(Hardware/Software Co-verification)、等价性检查（Equivalent checking）、静态时序分析和时序验证（Static timing analysis & Timing Verification）、版图验证（Physical verification）等。随着验证技术的逐步发展，验证方法由最初的直接测试向量生成（Directe
5、d Test Vector Generation）,到约束随机测试(Constrainted Random Test),再到覆盖驱动验证(Coverage- driven Verification),一直到最新的基于断言的验证方法(Assertion-based Verification),各种验证方法在不断创新发展。 SoC 验证流程与技术 3.1 SoC 验证流程与计划 SoC 的验证工作始终贯穿整个设计流程。从阶段划分上说，SoC 验证可以分为功能验证、等价性验证、静态时序分析、动态时序分析和版图验证等几个主要阶段，如图 2 所示。 有了 SoC 验证流程还很不够，需要验证计划（Veri
6、fication Plan），这为 SoC 验证工作提供重要质量保证，它规划如何来验证一个设计，主要包括以下内容： 1 对模块和顶层的测试策略 2 组成标准测试程序（Testbench）的各个组件的定义和规范，如 BFM3、总线监视器（Bus monitor）等 3 用到的验证工具和流程 4 仿真环境的定义和搭建 5 关键的验证点 6 验证工作结束的标准 一个高质量的验证计划使得验证工程师可以更早地开发标准测试程序环境。这种并行的开发验证环境，能尽早给验证团队一个明确的目标，也是保证验证可重用（re-used）的关键。为了得到一个高质量的验证计划，验证工程师要正确和充分地理解设计需求和规范，要
7、与设计工程师及时地交互，这样才能保证验证计划的易读、易用和可重用。因此可以说一个好的验证计划可以有效提高验证效率，缩短开发周期，在SoC 开发中有着重要的意义。 3.2 功能验证内容 功能验证（Functional Verification）是验证中最复杂，工作量最大同时也是最灵活的部分，包括模块/IP 核级验证、系统级验证、模拟仿真等。 3.2.1 模块/IP 核级验证 任何 SoC 设计均由一系列模块组成。模块可能是自己开发，也可能是重用第三方的 IP 核。不论哪种情况，在系统集成前做 IP 核验证工作是必需的。模块/IP 核级验证流程如图 3 所示，软性检查(Link Checking)
8、主要检查代码语法、可综合性、变量未初始化、结构化可支持性和端口失配性等；规范模型检查(Formal Model Checking)主要做设计特征遗漏性检查，以在早期发现错误状况，尤其对控制流设计效果明显，通过设计文档非正式说明、与设计者非正式沟通等途径抽取特征疑问，逐一验证，消除缺陷；功能验证(Functional Verification)主要利用基准测试向量基于事件或基于时钟进行功能验证，如黑盒测试、白盒测试和灰盒测试（gray-box）等；协议检查(Protocol Checking)主要验证是否违犯总线协议或模块互连约定，按照协议逐一检查并比较结果；直接随机测试(Directed Ra
9、ndom Testing)通过随机产生数据、地址、控制等信号检查功能正确性，减少模拟仿真工作量；代码覆盖率分析(Code Coverage )主要根据模拟仿真时统计代码被执行数，可以按陈述句、信号拴（Toggle）、状态机、可达状态、可触态、条件分支、通路和信号等进行统计分析，以提高设计可信度。 3.2.2 系统级验证 系统级验证主要确认芯片体系结构满足所赋予的功能/性能要求。系统级设计阶段将用户需求转换成功能/性能要求，并实现行为/功能设计，然后映射到相应的体系结构上（设计输入、硬 IP 核、软 IP 核、软/硬件划分、性能分析、总体优化、性价比评估等反复叠代），最后进行系统级验证，如图 4
10、 所示。 在系统级验证中，往往要构建虚拟目标系统，如中科 SoC 芯片在实施验证时，将其所有对外接口挂接许多虚拟 IP 核，同时编制了 BIOS4、RTOS5及应用测试程序（包括驱动程序）。首先做功能验证，验证是否满足要求；其次做软硬件性能验证；第三做系统级基准测试（自顶向下验证策略），抽取特定功能，编制测试向量/程序，定义对错条件，覆盖所有功能，形成基准测试程序（反复迭代），用于模拟仿真。 3.2.3 模拟仿真 在复杂 SoC 设计开发中，模拟仿真占整个验证工程师团队工作量的 40701，由于成本和市场压力，寻找灵巧的仿真技术显得十分迫切。 功能仿真：主要关注模块-模块（IP 核-IP 核）
11、间互连验证、系统总线协调性验证和标准规范兼容性验证等，由于复杂度高，可通过事件驱动和加速技术，如硬件加速器、模拟发生器和快速建模试验等来加速和简化仿真工作。基准测试包：首先搭建 SoC 整体架构，然后将每一模块（IP 核）经基准测试包挂接到系统总线上。这些基准测试包有利于缺陷的识别工作，但它们不是设计工作的一部分，而是为了验证而引入的。基准测试包测试向量来自于 IP 核供应商、直接随机产生、手工编制或由系统级测试捕获。 事件驱动仿真：使用比较普遍，像 NC_Verilog、VCS 等均支持，但受芯片规模和性能限制。首先设计代码被仿真工具所接受，其次编制基准测试向量（波形或 RTL6），第三运行
12、仿真，第四通过单步调试，错误定位、改正后可再次仿真。 时钟驱动仿真：在每一时钟结束时计算电路稳态响应，不考虑时序方面的问题，时序需要静态时序分析工具来验证是否满足要求。时钟驱动仿真比事件驱动仿真速度要快 10100 倍，适合大规模电路仿真。 基于传输仿真：传输操作是指传输虚拟部件（TVM7）和设计模块间的数据或控制传递，简单的如访存读操作，复杂的如结构化数据包传递。首先获取或编制 TVM，其次确定测试内容，第三步编译和连接，第四步进行仿真，第五步作输出分析，最后做功能覆盖分析。 3.2.4 FPGA 验证 随着半导体制造技术不断的前进和相应的设计规模以及复杂度飞速的增长，使得传统的软件仿真工具
13、已不可能完全解决功能验证的问题。而且一些需要处理大量实时数据的应用（如视频）也越来越多，因此要求能够在接近实时的条件下进行功能验证2。 FPGA8验证成为 SoC 设计流程中重要的一个环节,一方面作为硬件验证工具，可以将所设计的 RTL 级代码综合实现后写入 FPGA 芯片进行调试检错；另一方面可以进行软件部分的并行开发，在验证板上检测驱动程序、启动操作系统。FPGA 验证的流程相当于一个 FPGA 设计的主要流程，它主要分为设计输入、综合、功能仿真（前仿真）、实现、时序仿真（后仿真）、配置下载、下载后板级调试检错这几个步骤。总的来说，FPGA 验证是整个 SoC 设计中一个重要而且有效的验证
14、步骤，用来改进 RTL 级设计代码，验证功能的正确和完整性，提高 SoC 流片成功率。3.3 功能验证方法 3.3.1 直接测试向量生成 直接测试向量生成（Directed Test Vector Generation）遵守 WYTWYVO 原则，即 What-You-Thought-of-is-What-You-Verify-Only，所以需要产生大量的测试向量才能覆盖尽可能多的各种传输组合。这不但要耗费大量的时间和精力，而且很难达到满意的覆盖率。另外这种方法还需要手工检查结果，只适合比较简单的模块或系统，已经逐渐淡出。 3.3.2 约束随机测试 直接测试向量往往需要手工加入，这样难免会遗漏
15、一些考虑不到的情况，因此有学者提出了随机测试（Random Test）的方法。这种方法让测试向量随机生成，因此在足够长的时间内可以产生大量的随机向量，这样可以比较容易地覆盖到一些考虑不到的情况。 但随着验证技术的发展，验证工程师发现这种完全随机的验证方法一般需要比较长的时间才有可能达到令人满意的覆盖率，而且有些设备的传输类型只有几种，这样就导致把时间浪费在了一些根本不需要产生的测试向量上，所以又提出了约束随机测试(Constrained Random Test)这种新的验证方法，这种方法可以有效的缩短验证时间，在短时间内达到令人满意的覆盖率。 由于约束随机测试可以约束验证环境中各个层次上的属性
16、，所以这种方法可以更真实地反映一个实际的系统。使用约束，特别是带权值（在整个测试中出现的比例）的约束可以很容易地按事先确定的比例产生验证工作所需要的具有某些特殊属性值的一类或几类测试向量，而且如果加入记分板（Scoreboard）技术和自检测（Self -check）技术，会更加易于发现设计中的错误。 3.3.3 覆盖驱动验证 覆盖率一般表示一个设计的验证进行到什么程度，也是一个决定功能验证是否完成的重要量化标准之一。覆盖主要指的是代码覆盖（Code Coverage）和功能覆盖（Functional Coverage）。代码覆盖可以在仿真时由仿真器直接给出，主要用来检查 RTL 代码哪些没有
17、被执行到。使用代码覆盖可以有效地找出冗余代码，但是并不能很方便地找出功能上的缺陷。 使用功能覆盖则可以帮助我们找出功能上的缺陷。一般说来，对一个设计覆盖点的定义和条件约束是在验证计划中提前定义好的，然后在验证环境中具体编程实现，把功能验证应用在约束随机环境中可以有效检查是否所有需要出现的情况都已经遍历。功能验证与面向对象编程技术结合可以在验证过程中有效地增减覆盖点。这些覆盖点既可以是接口上的信号，也可以是模块内部的信号，因此既可以用在黑盒验证也可以用在白盒验证中。通过在验证程序中定义错误状态可以很方便地找出功能上的缺陷。 3.3.4 基于断言的验证方法 在验证过程中，一般很难找出跨多个时钟周期
18、、顺序相关的一系列操作的时序和功能是否有不符合规范的地方，为此研究出基于断言的验证方法(Assertion -based Verification)来推动验证技术发展。这种方法要用基于断言的验证语言，比如 OpenVeraAssertion 语言（OVA）、SystemVerilog Assertion 语言（SVA）、Property Specification 语言（PSL）等。 使用断言可以很方便的对一个给定输入的设计的期望行为进行精确的描述，从而可以很方便的描述输入/输出行为、总线协议以及设计中的一些复杂的关系。基于断言的验证语言可以使用简单的语言结构来建立精确的时序表达式。这些表达式
19、可以代表 HDL 或者 HVL9中的事件（events）、序列（sequences）和事务（transactions）等。通过检查这些表达式是否发生，可以很简单地进行功能覆盖的检查，并且这种覆盖率分析是针对跨多个时序周期的一个事件序列或者整个传输的，所以比传统的覆盖驱动验证的抽象层次要高。 传统覆盖分析要专门为覆盖分析而写大量的代码，而断言的覆盖分析可以直接使用在协议检查或者事件描述中用到的那些时序表达式，因此编码会更加灵活、简洁。在验证环境中使用基于断言的验证语言书写的模块（一般为 Checker 和 Monitor）的可重用性优于用 HDL 和 HVL 写的模块，此外要结合仿真器在仿真环境
20、中进行验证的工作，不过这些代码可以直接应用到形式验证（Formal Verifi- cation）上。 3.4 形式验证 形式验证（Formal Verification）主要是用来在覆盖所有可能的输入情况下检查是否与给定的规范一致。形式验证主要包括两部分：一是等价性检查（equivalence checking），二是模型检查（model checking）。等价性检查主要是检查两个门级网表（gate-level netlist）之间是否一致，保证网表处理后不会改变电路的功能，或者保证网表能正确地实现 RTL 代码所描述的功能，或者保证两种 RTL 描述逻辑一致。这种方法主要是用来寻找实现（
21、implementation）中的缺陷，而不是设计中的缺陷。因此这种方法很难发现同时存在于两种要比较的描述中的固有缺陷 3。 模型检查主要是检查 RTL 代码是否满足规范中规定的一些特性（properties）。在规定这些特性时一般使用特性规范语言（Properties Specification Languages），目前一般也使用基于断言的验证语言。由于这种方法可以在不需要仿真的前提下检查设计中所有可能出现的情况是否满足规定的特性，所以使用这种方法不会遗漏任何的边界情况（corner-case）。但是随着设计复杂度的增加和特性的增多，状态空间（state space）会成指数级增长，为了克
22、服这一困难出现了一种新的验证方法-半形式验证（semi-formal verification），如 Synopsys 公司的 Magellan 工具。这种方法把仿真技术的低复杂性和形式方法的完整性结合了起来。 3.5 时序验证 时序验证是用来避免时序异常的验证方法，主要包括静态时序分析（Static Timing Analysis）和动态时序分析（Dynamic Timing Analysis）。 静态时序分析(STA)根据设计规范的要求通过检查所有可能路径的时序，不需要通过仿真或测试向量就可以有效地覆盖门级网表中的每一条路径，在同步电路设计中快速地找出时序上的异常4 。静态时序分析可识别的
23、时序故障包括：建立/保持和恢复/移除检查(包括反向建立/保持)、最小和最大跳变、时钟脉冲宽度和时钟畸变、门级时钟的瞬时脉冲检测、总线竞争与总线悬浮错误、不受约束的逻辑通道，还能计算经过导通晶体管、传输门和双向锁存的延迟，并能自动对关键路径、约束性冲突、异步时钟域和某些瓶颈逻辑进行识别与分类。时序分析工具目前主要有 Primetime、Time Craft、Time Director 和 SST Velocity 等。 动态时序分析主要指的是门级（或对版图参数提取结果）仿真。这种方法主要应用在异步逻辑、多周期路径、错误路径的验证中。随着设计向 130nm 以下的工艺发展，只用静态分析工具将无法精
24、确验证串扰等动态效应。通过动态时序分析与静态时序分析相结合可以验证时序逻辑的建立保持时间，并利用动态技术来解决串扰效应、动态模拟时钟网络。 3.6 物理验证（Physical verification） 物理验证主要是进行设计规则检测(DRC10)、版图与原理图对照(LVS11)和信号完整性分析。SoC设计要求采用一种不受设计类型约束的物理验证工具，如 Hercules，来完成这两项任务，为制造复杂 SoC提供灵活性和保证。. 随着加工工艺的不断提高，带来了大量的信号完整性问题。互连线变得又细又高，线间距也越来越小，互连路径与相邻连线间存在的耦合电容成倍增加，因耦合产生的噪声与伪信号等串扰效应
25、可能成为影响集成电路延迟的重要因素。此外，电流在经过电路时会产生阻性电压降（IR drop）导致后面的门电路因电压降低而使其延迟增加，甚至达不到门槛电压。因此在 STA 计算延迟时必须考虑串扰和电压降等对电路延迟带来的影响。这使时序验证越来越复杂，也越来越重要。 SoC 验证技术发展方向 在对 IP 核进行验证时，传统的方法是，IP 核提供者在提供 IP 核的同时也要提供该 IP 核的测试向量和测试环境，使用这些测试向量和测试环境来验证测试结果是否正确。这种方法的缺陷在于，虽然这个IP 核本身设计是正确的，但是在一个 SoC 中，每个 IP 核并不是独立存在的，它与其他的 IP 核之间必然存在
26、数据交互和总线竞争，没有其他 IP 核协同验证是很难接近真实情况的，这样的验证也是不完备的5 。在 SoC 的实际设计过程中，设计上的问题很多都是在对 SoC 进行系统仿真验证的时候才暴露出来，主要体现在 IP 核与 IP 核之间信号时序的不匹配。这样的错误的定位和更正所需工作量都比较大，造成验证效率低下。在一个实际系统中，经常会有几个 IP 核同时发出请求让总线仲裁。但是由于 C 语言和汇编语言不支持并行的操作，因此使用这些语言书写的测试程序只能串行地去控制每个 IP 核，因而很难模拟这种多个 IP 核并发的情况。而使用 FPGA 进行系统级测试时，由于 FPGA 对外输出有限，系统工作起来
27、只能通过有限的输入输出引脚来辅助定位，对于设计中的错误较难定位和纠正。 SoC 验证与其他数字芯片相比最大的不同在于：因为 SoC 中需要集成大量的 IP 核，而且由于 IP 核经常是来自于不同的供应商，使得它们的验证更加困难。有时候甚至需要对 IP 核进行部分修改才能适合具体 SoC 的要求。因此 IP 核协同验证成为 IP 核验证中的一个难点。IP 核提供商所提供的测试向量和测试环境很难重用在多个 IP 核协同验证的环境下。供应商有时不提供 IP 核的 RTL 描述，只是给出行为级的描述和接口时序文档。这样的 IP 核不能烧入 FPGA 进行系统级验证，这就要求我们能提供一个系统的验证环境
28、来解决多个 IP 核协同验证的问题。同时，如果每一次系统级验证都要重新搭建验证环境、编写验证代码，从时间上和人力上都是无法接受的。由于 SoC 设计中系统结构和大量 IP 核存在着可重用性，在 SoC验证中也可以尽量重用以前的验证代码，使之适应新的设计要求，从而提高验证效率。 为了解决上述设计中的问题，可采用灵活可配置的集合了多种验证手段的系统验证平台，如图 3 所示的中科 SoC 验证平台。该平台综合使用直接测试、约束随机测试、形式化属性检查和覆盖驱动验证等多种方法，进行一定量的仿真工作，通过观察时序属性检测报告、数据检查报告、覆盖数据报告和波形来判断是否完成了验证工作。 这类验证平台有以下
29、优点： 1 解决了 IP 核集成时多个 IP 核协同验证的问题； 2 克服了传统验证方法中测试程序只能串行控制各个模块的缺点； 3 建立了一个统一的可配置的系统测试环境，不需要像传统验证方法那样为每个 IP 核建立各自的测试环境，提高了验证代码的可重用性； 4 不但可以验证 RTL 级的 IP 核，也可以验证行为级和门级的 IP 核； 5 平台中综合使用了直接测试、约束随机测试、形式化属性检查和覆盖驱动验证等多种验证方法，使得验证更直观，效率更高。 结束语 随着半导体制造技术不断的快速发展，SoC 设计规模以及复杂度飞速地的增长。尤其是在进入深亚微米工艺后，SoC 设计和开发遇到了大量的信号完
30、整性和设计完备性问题，为了验证整个芯片的正确性必须要做大量的验证工作，而芯片的上市压力又要求验证工作必须在尽可能短的时间内完成，SoC 验证正越来越成为整个设计流程中的关键部分，灵活可配置的集合了多种验证手段的系统验证平台日益重要。为此，业界一直在努力开发新的工具和方法，比如新出现的硬件仿真加速器（Hardware Emulator Accelerator），同时不断完善 SoC 设计验证平台建设。SoC 验证的工作是既复杂而又富有挑战性的工作。参考文献 51 Prakash Rashinkar, Peter Paterson,System on a Chip Verification: Me
31、thodology and Techniques, Kluwer Academic Publishers, 2001 62 http:/www.acro- 73 Prakash Rashinkar,Peter Paterson,etc.,SYSTEM_ON-A-CHIP VERIFICATION Methodology and Techniques, KLUWER ACADEMIC PUBLISHERS, 2001 84 马凤翔 孙义和 。数字芯片设计的断言验证。中国集成电路杂志网 2004.3.24 95 黎声华 邹雪城 莫迟., 静态时序分析在数字集成电路设计中的应用。电子技术应用 106
32、张宇弘，何乐年等。基于 SOC 典型结构的系统验证环境。微电子学，2002.1. 117F.Sforza,L.Battu“A Design for Verification Methodology“ Quality Electronic Design, 2001 International Symposium 128Mark Litterick, Joachim Geishauser。“Robust Vera Coding for Gate-Level SoC Verification“SNUG Europe 2004 139OpenVeraTM Language Reference Manual : Assertions, Version 1.3, Synopsys, March 2003 1410 Constrained-Random Test Generation and Functional Coverage with Vera, synopsys 1511 A Survey:System-on-a-Chip Design and Verification Ali Habibi and Sofine Tahar 1612 Rindert Schutten “A layered approach for SoC verification “ SNUG 2002
