本文阐述了当今流行的验证技术(形式验证、随机、定向、约束随机、断言、
(属性检查)和语言(SystemC、C/C++、SystemVerilog、Open-VERA、E等等)，还
探讨了各种验证技术在数字ASIC传统设计流程中的场合(应采用何种技术和语言)
和时机(设计者何时需要运用某项特定的技术或语言)。 

    功能验证在设计周期中占了最大的一部分，这是一个人所共知的事实。然
而，面对如此众多用于缓解该问题的现有技术，我们真正应该采用的是哪一项
(或哪几项)？得到的答案通常并不简单明了，而且往往令人感觉含混不清和成
本昂贵！ 

    抽象级越高，设计就越容易；同理，抽象级越高，就越容易犯较大的错误。
如果产生架构缺陷，就有可能损害整个芯片，这与发生在逻辑门连接表级上的
导线误连接是截然不同的(后者可通过重新连线的方法得到修复)。 

    以Verilog为例，它为设计者提供了一个较为简易的接口，以便在一个相当
抽象的等级上进行设计。然而，如果设计者并不知晓在多个设计周期中获得的
语言的细微差别，那么就非常容易犯错。许多论文重点阐述了Verilog误用的不
良后果。当设计曾经是瓶颈时，Verilog独立地使设计生产率取得了指数性的提
高(如采用原理图捕获)，并首先推进了复杂芯片的开发！在众多的验证技术和
语言、检验成为瓶颈的今天，相同的争议仍然存在。

验证瓶颈 

    EDA行业通过引入工具来帮助提升设计生产率，进而达到缩短产品时间的目
的，并最终实现设计时间的缩减。设计时间与硅片复杂性之间存在某种函数关
系。硅片复杂性指的是工艺精细度调整以及新型材料或新型架构的引入对器件
互连的影响。在硅片结构中拥有复杂性的能力将导致系统复杂性的形成(由于特
征尺寸的缩小以及消费者对增加功能的需求而在相同的面积之内压缩进更多晶
体管的能力)。 

    随着设计方案构筑过程中所集成的晶体管数量的指数性增加，计算时间或
工程师数量的线性增加已不足以缩短设计时间。系统复杂性继续按照摩尔定律
增加，而功能复杂性(一个系统所具有的不同状态的数量)的增长速度则更加迅
猛。为解决这一问题，EDA行业提出了通过自动化来实现“设计抽象”(Design 
Abstraction)的概念。从能够在多个电路层上捕获设计的原理图捕获工具到基
于语言的解决方案等均已面市。 

    这种追随形势需要的设计手法仍然是适当的。EDA界即将推出并给予支持的
最新语言是SystemC和SystemVerilog，它们能够解决一些由目前所采用的技术
和工艺造成的系统复杂性问题。我们可以说，就目前的技术工艺而言，设计复
杂性已经得到了很好的理解，而且，设计瓶颈也因为采用EDA工具所实现的生产
率提高而在一定程度上得到了克服。 

    设计生产率的提升速度将继续低于复杂性的增速，此时与之相关的瓶颈已
并非设计时间，而是验证时间 

    由于下列原因所导致的设计抽象级的提高是形成验证瓶颈的罪魁祸首之一。 
    
    1. 在一个较高的抽象级上进行设计使得我们能够轻松地构筑高度复杂的
功能。设计复杂性的这种增加接着会导致验证工作量几乎翻番(如果设计者考
虑增加锁存器和逻辑门的数量，这就等于功能复杂性将加倍，而且其验证范围
也将因此翻番)。 

    2. 在设计、变换以及至终端产品的最终映射中采用较高的抽象级总会存
在信息损失和解释错误的情况。比如，采用HDL级设计并将之变换为逻辑门级
(映射至某一特定技术)的综合过程；在这一级上需要进行验证，以保证所实施
的变换正确无误，而且设计内容没有丢失。提高抽象级还会带来代码解释方面
的问题，代码解释是用来在仿真过程中对设计进行描述的，用于确保所编写的
代码如实地反映了功能规范。

    其他影响验证问题的因素包括： 

    1. 由于当今设计的异类特性(比如硬件-软件、模拟-数字的共存等)所导
致的功能复杂性的增加； 

    2. 对较高的系统可靠性的要求迫使验证工作必须确保芯片级功能可在系
统环境中圆满地执行，尤其是当某个芯片级缺陷具有多重影响时更应如此。 

    相关统计结果表明：验证问题是客观存在的，并正在耗费有关的公司的巨
额资金。设计差错导致的芯片缺陷：在由于逻辑和功能缺陷的缘故而导致需要
进行重新布线的设计当中，有82%存在着设计差错。这意味着在验证过程中并
未考虑一些极端场合，而且一直到最后的检查之前，bug都会隐匿在设计之中。
规范误差导致的芯片缺陷：在由于逻辑和功能缺陷的缘故而导致需要进行重新
布线的设计当中，有47%存在着规范不正确或不完整的情况。在由于逻辑和功能
缺陷的缘故而导致需要进行重新布线的设计当中，有32%对规范进行了改动。采
用复用IP和外来IP所引发的问题：14%的缺陷芯片在复用单元或外来IP中存在bug。
重新布线的影响：重新布线有可能给公司带来高达10万美元的损失。此外，它
还会推迟产品面市，并因采用这些缺陷芯片的系统所发生的故障而导致费用的
上扬。 

    为了对付验证瓶颈问题可以：
    
    1．提高设计师的生产率：这一领域大有优化空间。设计生产率已经通过改
善计算机性能、采用诸如微软公司的软件工具(如Excel)等个人工具而得到了提
高。虽然它们在捕获测试和验证计划中大有助益，但大部分时间却花在了测试场
合的编码、运行和调试上。

    2．提高验证生产率：这种方法明显具有用于提升生产率的潜力。 

    为了提高验证生产率，EDA行业采用了一种与解决设计瓶颈问题相似的“抽象”
概念。诸如Verilog和VHDL等高级语言被用来验证芯片；包括诸如任务、线程(分
叉、连接)等以及诸如“while”等控制结构。这提供了对数据的进一步控制，以
便在所有的功能隅角上实现设计的全面执行。然而，这些构件过去是不可综合的，
因此未被设计师用作实际设计代码的一部分。 

    随着复杂性的继续提高，人们创建并引入了能够在不同的抽象级上对复杂设
计进行验证的新型验证语言。伴随着这些新型语言的问世又出现了对其提供支持
的技术和工具。 

验证与确认(Validation)的比较 

    除了验证问题之外，芯片制造商还饱受确认时间的困扰。Kropf将“确认”定
义为“通过检查实现方案的工作行为来获得对规范的信心的过程”。对验证与确
认的比较，观点众多。一种观点是：“确认用于保证这是一种正确的设计，而验
证则用于保证设计是正确的”。另一种观点是：“验证是在硅片测试之前
(Verilog/VHDL仿真等)进行的，而确认则是在硅片测试之后(在实验室中，在电路
板上进行硅片测试)进行”。 

    不管是确认还是验证，为了确保硅片满足规范，有两件事是必需做到的： 
    
    1)芯片规范得到了正确的解释(一般是借助文档资料，有时也采用建模的方
法)； 

    2)这种解释被正确地捕获和执行(一般采用VHDL)、综合到硅片之中、并被封
装为芯片。 

    本文将第二步视作验证，而把第一步看作确认。图1给出了被业界用来确保
上述两个步骤得到满足的常见设计流程的概况。 

    视被执行功能的复杂性的不同，可以跳过其中的某些步骤，也可以增加更多
的步骤。例如，如果知道某个特定设计完全是面向硬件的，且不包括驱动器或软
件，便可从抽象级3直接跳至抽象级1(无需进行硬件-软件折衷)。PLL(锁相环)设
计似乎就是这样的一个例子。 

    应该注意，当逐渐走向较低的抽象级时，必须始终保持等效性，以确保最低
的抽象级能够满足系统规范的要求。 

当今的验证技术和发展趋势 

1. 动态功能验证 
   
    使用最为普遍的功能验证方法具有动态特性。之所以将其冠名为“动态”，
原因在于输入图形/激励信号是在一段时间内(若干个时钟周期)生成并应用于设
计的，而且，对应的结果被收集起来并与一个参考/黄金模型进行比较，以便与
规范相符。 

    一个仿真器被用来计算所有信号的全部数值，并将规定的预期值与计算值
加以比较。目前，业界可以选用的仿真器有两种。 

    1. 基于周期的仿真器：该仿真器完全不理会时钟内部发生的事件，而是在
每个周期中进行一次信号评估。由于执行时间较短，这类仿真器的运行速度往
往较快。 

    2. 基于事件的仿真器：这些仿真器捕获事件(在时钟内部或在时钟的边界
上)并通过设计进行传播，直到实现一个稳定状态为止。 

    动态仿真的一个主要的缺点是，在一个限时仿真行程当中，只能对芯片的典
型(而不是所有可能的)工作特性进行验证。造成这种情况的主要原因在于芯片是
针对已知测试空间(而不是未知测试环境)进行测试的，采用的是定向测试法。EDA
行业推出了诸如Open-VERA、E和SVL(SystemC Verification Library)等更加高
级的验证语言。这些语言引入了新的概念，比如约束随机激励、随机激励信号分
配和电抗性测试台。伴随着这些语言的运用出现了一些用于对其进行解释的工具，
就本场合而言，它们有可能是VERA、Specman和OSCI内核(即CCSS)。 

    除了引入了随机化功能之外，新型验证语言和工具还通过减少公司在构筑各
种用于激励信号发生的测试场合/方案所花费的时间量而实现了生产率的提高。
例如，测试方案可以采用最高的抽象级来编写，并能够通过采用功能强大的面向
对象型结构而“扩展”至任何较低的抽象级。 

    当采用动态验证时，设计者一般希望拥有一个以可量化项来覆盖和捕获的功
能空间的估计值： 

    1. 被验证的代码行的数量(行覆盖率)； 
    2. 被验证的逻辑表达式有多少？(表达式覆盖率) 
    3. 在一个FSM设计中达到了多少种状态(FSM覆盖率)； 
    4. 在一个仿真行程中进行双向变换的端口和寄存器的数量(变换覆盖率)； 
    5. 设计代码中被覆盖的逻辑通路的数量(通路覆盖率)； 

    这可以通过采用诸如代码覆盖和lint等工具来实现。设计者将“断言”用作
一个占位符，用来描述与某项设计相关联的假设和工作特性(包括暂时的特性)。
如果设计满足或未满足规范或假设，则断言将会在一个动态仿真过程中被触发。
断言也可在形式/静态功能验证环境中使用。 

2. 混合功能验证 

    在该方法中通常执行动态仿真，仿真结果被捕获并用作静态验证的输入。在
静态验证期间，逻辑方程/符号通过设计进行传播(而不象在动态仿真中那样传播
的是数值)。这种手法虽然不如形式验证详尽周全，但却可以被证实具有比纯动态
仿真更高的效率，因为它开始于动态仿真停止之时。 

3.静态功能验证 

    在静态功能验证中，没有向设计施加输入激励信号。而是将设计映射至一个
采用BDD(双择判决图)或其他数学表达式(它们规定了所有时间周期中的设计功能)
来说明其功能的图形结构上。利用这种图形结构来证实或反驳属性将能够验证这
些数学表达式。这是通过确定数学结构中的矛盾式(方法是顺着或逆着信号流来传
递数值)来完成的。 

现有工具采用以下两种方式来满足静态验证市场的需求 

     1. 采用断言：这些是在模型/设计自身当中规定并公式化的设计约束(运用
诸如SystemVerilog、Open-VERA、Verilog、VHDL等设计/验证语言)。 
     2. 采用属性：这些通过采用一种属性语言(比如PSL、Sugar)提供了属性的
规范。 

4. 等效性验证 

    为了确定逻辑门级表示与HDL实现是相同的，通过采用匹配点并比较这些点之
间的逻辑来执行一种所谓的“等效性检查”。生成一种数据结构，并将其与相同
输入特性曲线条件下的输出数值特性曲线进行比较。如果它们不同，则表示(在本
场合为逻辑门和RTL)是不等效的。当其中一种表示经过了某种类型的变换时，等
效性检查有时是在两个连接表(逻辑门级)或两个RTL实现之间执行的(图2)。 

    造成设计表示出现差异的一些实际原因如下： 

    1. 合成算法/启发式法：根据对合成工具的约束条件(区域、时间、功率)的
不同，合成工具将对逻辑运算进行优化，以推导出适当的逻辑门级表示。为此，
合成工具将采用启发式法和逻辑最小化算法。 

    2. 抽象级：有时可以采用HDL来实现设计，它有可能与设计者的意图存在一
定的差异，原因是语言的局限性，抑或是缺乏(或不具备)对合成工具解释特定语
言结构并将其变换为逻辑门级表示的方式进行预测的能力。 

    正确验证方法的选择标准 

    在准备将新技术引入自己的工具流程之前，芯片供应商应当考虑以下问题并
做出适当的折衷。 
    1. 在某个特定的产品线中，我们是市场的领先者还是追随者？ 
    2. CAD基础设施、工具和方法是集中式的还是分布式的？ 
    3. 新型验证技术的评估是针对第一代产品进行的吗？ 
    4. 新型验证技术对成本和产品面市时间的直接影响和间接影响是什么？ 
    5. 新型工具能否处理变动的设计能力？ 
    6. 工具的易用性如何？ 
    7. 可为新型工具提供什么水平的文档和支持？ 
    8. 新型工具和方法与公司内部现有的工具和方法之间是否具有互操作性？ 
    9. 新型工具的ROI(投资回报)是什么(包括服务、培训、咨询、计算和人力
资源)？ 
    10. 新型工具能否支持处于多个不同地理位置的设计？ 
    11. 对于有关公司而言，他们所需关注的最为重要的问题或许是：我们雇用
的设计师和验证工程师对新型工具是否有成见(设计师不愿意学习和采用新技术)？ 

1.产品角度 

    主要从事存储器芯片或存储器密集型(而不是逻辑密集型)芯片生产的公司
——比如SRAM和DRAM公司或许根本不需要进行大量的逻辑验证。这些器件大多
是定制的。虽然此类产品中有些规模会很大，但它们的逻辑复杂性并不高，因
而不支持在公司内部配备大量逻辑验证工具的计划。不过，存储器密集型设计
提出了其他的挑战，比如布线、工艺调整和功耗。那些制造纯ASIC芯片(其上不
运行软件)的公司可能无须进行硬件-软件折衷，或者也许不必实施用于捕获运
行于硬件之上的软件的测试。例如，只具有硬件的SERDES(并串/串并变换器)芯
片所要求的验证和建模方法与同时具有硬件和软件的SoC是不同的。对于拥有门
类宽泛的产品线的大型公司来说，验证方法必须包含不同产品的各种要求。 

2.系统角度 

    过去，逻辑芯片供应商不负责对芯片是否满足某一参考系统上的功能和性
能要求进行验证。如今的系统厂商在批量订货之前都要求芯片制造商进行系统
参考验证。这就要求芯片公司采用一种他们所不熟悉的附加抽象级来对芯片进
行建模和验证。这需要架构模型、参考模型、制定复杂的应用级测试和精细的
测试台配置。面对这些类型的难题，有关公司有两种选择，一是采用现有的语
言、技术和方法(这样做将耗费大量的时间和精力)，另一种就是大量采用新技
术(如VERA、Specman等)。此外，芯片销售商还必须确保所采用的参考模型和验
证套件是在一个与客户兼容的环境中执行的(比如，测试场合应该能够使用客户
的软件开发套件SDK以及客户所用的仿真器)。 

3.方法角度 

    在芯片集成之前，可以按照一个高置信度将静态功能验证和动态仿真结合
起来用于验证模块级功能度。采用动态仿真能够高效执行系统级验证，借助的
方法是确定我们正在连续不断地验证功能空间的主要隅角。首先执行随机仿真
(以便在验证的初始阶段捕捉到大量的缺陷)，并随后对随机仿真加以约束(以确
定在测试计划中所规定的测试空间已经在器件上被完全覆盖)的做法或许相对容
易一些。应考虑将约束驱动型验证在功能覆盖量度上进行细化。“功能覆盖率”
这一术语被用来描述一个对所覆盖的功能空间进行量化的参数，相反，“代码
覆盖率”则被用来对已经实现的设计被某一给定的测试套件所覆盖的程度进行
量化。定向仿真随后可被用来在验证周期的末端覆盖隅角测试空间。 

    断言和属性可在静态功能验证期间的背景中起作用(在模块级上)，并可在
动态仿真环境中被重用(在模块和系统级上)。如果模块将被转变成IP，则它们
也是有用的，因为断言将在IP被重用时持续不断地检查其属性。