众所周知，功能验证在芯片的整个设计周期中占用的时间最多。尽管目前有许多技术可用于减少验证时间，但最终应当如何选择？答案并不简单明了，而且经常令人迷惑并要付出高昂的代价。
一个项目中需要使用的工具和技术必须在设计周期的初期就确定下来，以便获得新验证方法费用预算的准确信息。经常有公司因为错误估计了运转这些新型工具和技术所需的设计和技术的复杂性而浪费大量的资金和资源。
2
3
例如，为设计者提供了一种相对容易的接口，以便他们在相当抽象的层次上进行设计。当设计曾经作为制约性的瓶颈时，为设计生产率带来了指数增长，并且大大推动了复杂芯片的发展。但是如果设计者不了解在复杂的设计周期中语言上的细微差别，就很容易犯错。在验证成为瓶颈的今天，同样的观点也适用于许多验证技术和语言。
本文将对时下流行的验证技术形式验证、随机、定向、有约束的随机、断言、属性检验与语言、、、、等进行全面评述，还将分析在传统的数字设计流程中应当在何时采用何种验证技术和语言。
60_70% 的时间都用于验证工作。如何使用新的工具和技术对设计中的复杂功能进行验证已经成为缩短总体的产品时间所需要面对的挑战。
由于以下原因，可以说验证瓶颈在某种程度上是设计抽象级逐步提高造成的结果：
HDL级设计并将其转换到门级的综合过程，需要进行验证以确保转换的正确性以及使设计意图完全得到体现。提高抽象级还带来了代码解释问题，在仿真时要通过这些代码对设计进行描述，以确保所写的代码真实反映了功能规范。
其它影响验证问题的因素还包括：
统计数据表明，验证问题现实存在，而且让公司付出了高昂的成本：
82%是由于逻辑与功能缺陷设计错误。这意味着验证过程没有覆盖边角情况，缺陷一直隐藏在设计过程中直到流片。
47%是由于逻辑与功能规范不正确或不完整，有是由于规范发生了改变。
IP和外来的问题：所有失败的芯片中，有是由于在重用或外来的中存在错误。
10万美元，还会延误产品的推出，由于使用这些有缺陷的芯片而导致的系统失败也会增加成本。
为了提高验证生产率，行业提出了一个与解决设计瓶颈类似的解决方案——抽象化的理念。诸如和等高层次的语言被用于验证芯片，这些语言包括各种指令如任务指令和线程指令语句，以及控制结构语句。这提供了更强的数据控制力，以便对所有边角设计进行充分验证。然而，这些指令不能被综合，因此不会被用作实际设计代码的一部分。
随着复杂度与日俱增，能够验证具有不同抽象级的复杂设计的新语言被创建出来，支持这些新的验证语言的技术和工具也随之诞生。
所有这一切意味着芯片厂商必须对新的工具作出评估，必须针对这些新的工具和技术对工程师进行培训，在公司的研发费用成本结构中必须包括新的工具和资源，公司在总体上必须在短时间内克服学习曲线问题，另外，还需要对这些工具进行风险评估，以及考虑新工具与已有技术的集成和协同工作的能力。
(Validation)
Kropf 将“确认”定义为“通过检查实现行为以获得对规范的信心的过程”。在验证和确认之间，有一种观点认为，“确认能够确保这是正确的设计，而验证则是确保这个设计是正确的”;另外一种观点认为，“验证指硅片成为成品之前的测试仿真等，确认指硅片成为成品之后的测试在实验室里测试电路板上的芯片”。
无论是确认还是验证，若要保证硅片满足规范要求，要完成以下两个步骤：通过文件或建模，芯片规范得到了正确的解释;以上解释得到了正确的理解与实现一般是通过，综合入硅片，并封装成为芯片。
本文认为第二步是验证，第一步是确认。目前业界流行的设计流程如图所示，此流程可保证以上两个步骤的要求得以满足。根据待实现功能的复杂程度不同，可以跳过一些步骤或者增加一些步骤。例如，如果某一项设计是纯粹面向硬件的，不涉及驱动或软件，那么可以从抽象级直接跳到抽象级，锁相环设计即为一例。
当设计按照抽象级逐步推进时，要注意必须一直保持等效性，以确保最低层的抽象级能满足系统规范的要求。例如：
C 模型被置于一个系统环境并能够满足规范中所描述的所有系统要求时，芯片规范一般是一个文本文件与其模型之间就达到了等效。这在实质上是功能等效。
C 模型与实现的输出，可以在规范的模型与其实现之间建立等效关系。在没有模型的情况下，可使用“期望数据模型”。这在实质上也是功能等效。
(综合后的之间通过应用“逻辑等效性检验”可以建立等效关系。这时，由于设计采取的形式是纯粹的逻辑门，而且功能能够被表示为逻辑表达式，因此，这在实质上是逻辑等效。
2所示。
动态功能验证
使用最为广泛的功能验证方法是动态的，之所以被称为动态是因为输入图形激励信号是在一段时间几个时钟周期内生成并应用于/黄金模型进行比较，以检验其与规范之间的一致性。
仿真器通常用于计算所有的信号值，并将其与指定的期望值进行比较。目前，有两类可供选择的仿真器：
随机定向功能验证
32 位操作数进行加和运算的简单加法器的测试空间就需要 Open-VERA、与验证库被推出。这些语言引入了诸如约束随机激励信号、随机激励信号分配与电抗性测试平台等概念。伴随着这些语言的运用，出现了一些用于对其进行解释的工具，如、与内核，。
除了引入随机化功能以外，新的验证语言和工具还通过减少公司在构建不同测试场合方案所花费的时间，来提高生产率。例如，测试方案可以采用最高的抽象级来编写，并能够通过采用功能强大的面向对象型结构而扩展至任何较低的抽象级。
当应用动态验证时，通常需要估计所覆盖的、可以量化的功能空间，包括：经过验证的代码行数行覆盖率，经过测试的逻辑表达式个数表达式覆盖率，一个设计中能够达到的状态数覆盖率，在一个仿真运行中可以双向变换的端口及寄存器数目变换覆盖率，以及设计代码中覆盖的逻辑通道数目通道覆盖率。以上可以使用及工具来实现。
断言
设计者将断言用作一个占位符，用来描述与设计相关联的假设及工作特性包括暂时的特性。如果设计满足或未满足规范或假设，则断言将会在一个动态仿真过程中被触发。断言还可在形式静态功能验证环境中使用。
混合功能验证
在该方法中通常执行动态仿真，仿真结果被用作静态验证的输入。在静态验证过程中，在设计中传播的是逻辑方程式符号，而不象在动态仿真中那样传递数值。这种方法虽然不像形式验证详尽周全，但却具有比纯动态仿真更高的效率。
静态功能验证
在静态功能验证中，不向设计施加输入激励，而是将设计映射在一个图形结构中，用双择判决图或其他数学表示方法来描述所有时间周期内的设计功能。利用这种图形结构来证实或反驳属性可以验证这些数学表达式，这是通过顺着或逆着信号流来传递数值，以确定数学结构中的矛盾式来完成的。
现有的工具通过以下两种方式来满足静态验证市场的需求：
/设计当中规范并公式化的设计约束使用、、和等设计验证语言。
(如和对属性进行规范。
等效性验证
为了确认门级表示法与实现是相同的，需要实施等效性检验，使用匹配点并比较这些匹配点之间的逻辑。检验中会生成一个数据结构并比较在相同的输入模式下得出的输出数值模式，如果这些输出数值模式不相同，那么表示法这里指门级和级就不是等效的。当表示法中的一个经过了某种类型的变换时，等效性检验有时会在两个门级网表或两个级实现之间进行。
造成设计表达式差异的一些实际原因包括：
(区域、时间、功率不同，综合工具会对逻辑运算进行优化，以得到适当的门级表式。为此，综合工具将采用探索式方法和逻辑最小化算法。
HDL来实现设计时，由于语言的局限性或是缺乏不具备对综合工具如何解释特定语言结构并将其变换为门级表式的预测能力，因此，实现有可能与设计者意图存在一定的差异。
影响验证技术的趋势和力量
技术视角
设计错误可能出现在模块接口处或是在模块内部，它们最终会集成在一起形成芯片。举例而言，那些在模块级没有被发现的缺陷在应用动态仿真时会在子系统或系统级上显露出来。使用静态功能验证，模块开发的每一步都会得到详尽的验证，从而确保子系统系统质量和可靠性从根本上得到提高。有人认为，使用静态形式功能验证，能够更快地找到更多的缺陷。
另一方面，使用静态功能验证也存在以下缺陷：
(一般只能处理的门电路;
(这主要是因为它们往往是基于一套探索程序，而不是任一算法。这意味着形式功能验证在一些情况下可能会比动态仿真花费更长的时间;
RTL形式。
除了上述技术上的挑战外，基于断言的形式功能验证的两个竞争标准对也带来了额外的问题。目前倾向于将静态功能验证方法用于验证足够成熟以备综合的模块，动态验证随机和定向用于严格验证集成前的模块。
目前，动态仿真还将继续主宰功能验证领域，直到形式验证工具提供一种更成熟的方法。
语言视角
可以观察到这样一个趋势，就是将设计和验证语言结合在一起。这将极大地促进生产率，改进系统可靠性以及提高设计质量，因为使用多种工具和语言引发的不明确和误解问题将得到消除。
在这一结合实现之前，公司要继续依赖现有的高级设计语言和，并选择是使用专有验证语言、等，还是过去流行的和。
(如。另外，它们也可用于架构建模及确认，当可以为应用事务模型的验证使用架构模型组件时，也可以使用。
新验证技术的评估是针对第
(ROI)如何？包括在服务、培训、咨询、计算和人力资源方面的投资
(即设计师不愿意学习和接受新的技术
公司在做出关于工具、语言和方法的决策时可以采用以下介绍的简单权衡方法。
产品视角
主要从事存储器芯片或存储器密集型相对于逻辑密集型而言芯片生产的公司讶和公司可能根本不需要进行大量的逻辑验证。这些芯片大多是定制的。虽然这些产品中有些规模会很大，但它们的逻辑复杂性并不高，因而不支持在公司内部配备大量逻辑验证工具的计划。不过，存储器密集型设计在其他方面提出了挑战，例如布线、工艺变化以及功率等。
那些制造纯芯片，在芯片上不运行任何软件的公司可能无须在硬件或是软件实现上进行权衡或是实施测试以捕获运行于硬件之上的软件。例如，只具有硬件的芯片所要求的验证和建模方法与同时具有硬件和软件的是不同的。
对于拥有多种产品线的大公司来说，验证方法必须满足各种产品的不同要求。
系统视角
过去，逻辑芯片供应商不负责对芯片是否满足参考系统的功能和性能要求进行验证，而如今的系统厂商在批量订货之前都要求芯片供应商实施系统参考验证。这就要求芯片公司在一个它们不熟悉的附加抽象级上对芯片进行建模和验证，这需要架构模型、参考模型、复杂应用级的测试以及精细的测试平台配置。面对这些不同类型的挑战，公司有两种选择，一是采用现有的语言、技术和方法，这将耗费大量的时间和精力;另一种就是采用新技术如、等。此外，芯片供应商还必须确保所使用的参考模型和验证套件是在一个与客户的相应模型和套件兼容的环境中完成的，例如，应用客户的软件开发套件和仿真器也能够进行同样的测试。
方法学视角
在芯片集成之前，可以将静态功能验证与动态仿真结合起来，在一个高置信度水平上验证模块级的功能。通过确认动态仿真正在持续验证功能空间的主要边角，可以有效地实施系统级验证。
首先执行随机仿真可以在验证的初始阶段发现大量的缺陷，然后对随机模拟加以约束以确定测试空间已经被完全覆盖的做法或许相对容易一些。应考虑在功能覆盖度量上对约束驱动型验证进行细化。功能覆盖率这一术语被用于描述对被覆盖的功能空间进行量化的参数，相反地，代码覆盖率则被用于量化一个给定的测试套件对已实现的设计进行覆盖的程度。定向仿真随后可被用于在验证周期末期覆盖边角测试空间。
断言和属性可在静态功能验证期间起作用在模块级上，并可在动态仿真环境中被重用在模块级和系统级上。如果模块转变为，那么断言和属性也是有用的，因为断言将在被重用时持续不断地检查其属性。
(90nm 和的器件将投产。目前，公司正在致力于解决诸如布线、串扰和软错误的设计问题。一旦这些设计瓶颈得到了解决且随着芯片厂商在越来越小的芯片上封装越来越多的逻辑，验证问题的出现就是意料中的事了。新型工具和方法的不断引进提高了设计生产率。提高设计和和验证、和的抽象化程度以满足日益增长的复杂度要求是不可避免的。目前从的推出能够看到设计和验证语言的融合趋势。
SystemC 和建模语言将继续为逻辑密集型产品提供架构验证。通过使用属性、断言以及推出形式验证工具，生产率得到了进一步提高。但目前工程师仍旧依赖并信任动态仿真，因为它能够验证大型和高度复杂的设计。最终的趋势可能是：形式验证占据主要地位，动态仿真仍用于完整性检查。
