SoC设计验证技术发展综述

3.3.3 覆盖驱动验证

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

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

SoC设计验证技术发展综述

3.3.4 基于断言的验证方法

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

使用断言可以很方便的对一个给定输入的设计的期望行为进行精确的描述，从而可以很方便的描述输入/输出行为、总线协议以及设计中的一些复杂的关系。
基于断言的验证语言可以使用简单的语言结构来建立精确的时序表达式。这些表达式可以代表HDL或者HVL 中的事件（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 )、版图与原理图对照(LVS )和信号完整性分析。
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验证的工作是既复杂而又富有挑战性的工作。

SoC设计验证技术发展综述

感谢分享。。。