-
-
手机阅读
1 前言
随着EDA技术的不断提高，ASIC设计的复杂度也越来越高，设计验证工作在整个IC设计过程中占有的比重也越来越大，验证正逐渐成为设计的瓶颈。设计中大多数错误都是在功能验证阶段被发现的，越早发现设计错误，修改错误的代价越小，因此为了减小错误带来的损失，必须在功能验证阶段尽快发现更多的错误，所以对功能验证阶段的验证方法研究是极其重要，不可或缺的。更少的验证时间，更完备的验证结果，是目前芯片验证中的重点研究目标。因此研究高效的功能验证机制具有重大意义。
2 传统的一些功能验证方法
2.1模拟验证
模拟验证的过程是：首先编写测试（tests）生成需要的激励，然后将产生的输入激励同时赋予DUT和参考模型，记录DUT和参考模型对应的输出，通过比对输出是否一致，判断DUT的运作是否正确，同时将DUT的模拟运行状况（重要的变量和状态等）记录下来，通过覆盖率统计工具进行分析，可以获得验证的覆盖率。
模拟验证方法存在内在缺陷：即使通过DUT，输入都能得到正确的输出，也不能保证设计完全正确，因为输出结果与设计相符，也并不能确定运行的中间变量、状态等和设计预想的一样。因此单独采用模拟验证不能保证验证完整性，需要和别的验证方法结合使用。
模拟验证方法中激励生成机制可以分为人工编写和伪随机生成两种，激励伪随机生成的模拟验证被称为伪随机验证。在人工编写方式中，验证人员为输入信号一一编写赋值语句，赋值语句中的数值大多数情况下是特定值，也可能是简单的随机值。优点是针对性很强，生成的激励序列测试的都是值得关注的情况。伪随机生成方式则首先定义输入的数据结构，并根据需要对输入定义约束条件，然后由约束解析器生成满足所有约束条件的输入激励。优点是验证人员只需要完成少量的工作，就能生成大量的激励序列。
2.2形式验证
形式验证是一种无向量的验证方法。也就是说，它不使用传统的激励—响应机制，而是采用系统的、智能的数学分析来判断某个设计在所有的输入或状态条件下是否能按预期的情形工作。设计者可以有二种选择，即检查所期望的特性是否总是发生或者检查不期望的特性永远不会发生。
采用形式验证有助于在设计周期的较早阶段发现功能问题。形式验证的使用能确保较早地检测出绝大多数功能问题，从而能够更容易并以更少的代价来修复它们。笔者认为目前还没有很成熟的形式验证工具，验证的完整性难以保证，因此现阶段形式验证方法只能作为一种辅助验证手段，还不足以独立使用。
2.2基于断言的验证
基于断言的验证（Assertion-Based Verification）是一种半形式验证方法，其中断言（Assertion）是一种主动性的注释，能够监控信号、预测行为和禁止行为。
ABV对于编写RTL级代码的设计工程师来说最为有用,因为只有对设计内部的详细功能具有深入的了解才能写出有用的断言。基于断言的验证流程如图1所示：
3 新型的功能验证方法
通过对比上述的功能验证方法，笔者发现对于激励生成机制的研究是一个突破点。激励生成机制是当今学术界研究的热点之一，专家们提出了许多生成机制，比较典型的有AVPGEN和DPRTPG。AVPGEN中采用SIGL(symbolic instruction graph language)语言来描述模版，其中包括抽象约束，然后根据模版和约束生成激励。DPRTPG （Dynamic Pseudo Random Test Program Generator）是在传统RTPG （Random Test Program Generator）的基础上发展起来的。它的独特性在于利用运行n-1条指令后的模型状态来产生下一条指令。
并且目前不管是工业界还是EDA界，对伪随机激励的产生功能也是非常重视的。EDA厂商开发了许多辅助工具集，典型的有TestBuilder和Specman Elite。TestBuilder是Cadence公司在C++的类库的基础上开发研制的，支持TBV （Transaction-Based Verification）；实现了不同语言编写的模块间的混合模拟；自动扩展用户定义的数据类型，并产生伪随机数据。TestBuilder 提供面向对象技术，能够高效地生成复杂的Testbench，并方便地实现了自我检查。Specman Elite 由Verisity公司开发研制，并且开发了一种专门用于验证的语言：e语言，在Specman Elite中就是采用e语言来描述数据结构、约束条件等，然后由约束解析器根据数据结构和约束生成伪随机数据。
3．1 度量功能验证进度的机制
模拟是功能验证的主要手段，模拟加速器、伪随机激励生成、模拟服务器群等技术的发展使得模拟运行的速度和效率大幅提高，但这些手段只能说明设计已被验证，不能说明对设计到底验证得怎么样。为了评价功能验证工作的进展情况，需要采用一定的度量手段。
验证工程师们通常采用很少的几种覆盖度量尺度来评价验证进度，比如触发覆盖，语句覆盖等等。然而，这些度量方法不足以保证设计的功能已经被完全验证到。
为了更有效地度量验证功能验证的进度，应该将多种覆盖度量方法结合起来，包括代码覆盖，功能覆盖和断言覆盖，这些度量方法是高度互补的。
代码覆盖反映了HDL代码被运行的彻底程度。为了得到代码覆盖率，首先要对源代码进行分解，分解的过程就是在源代码的关键位置加上断点，记录该位置是否存在特殊结构。分解的方法因工具的不同而有别，有的可能用到文件的输入输出功能(如Verilog中的$write语句或VHDL中的textio.write子程序)，还有的可能用到模拟器自带的特殊功能。接下来用测试平台来对这些分解的代码进行模拟(这些测试平台本身并不需要分解)，全部的追踪信息都放进一个数据库，最后根据这个数据库进行分析，得到覆盖率信息。功能覆盖是从系统的角度来认识设计。功能覆盖可以指示哪些功能被测试到，哪些还没有。例如：是否覆盖了所有典型情况，错误情况，边界情况等等。功能覆盖不但能够判断是否覆盖了状态机的所有状态，还能考察是否在各个状态都中断过，状态的变化情况，状态和输入的组合情况等等。断言作为协议的检查者用于模拟期间，用断言描述语言在注释中定义，模拟时工具会自动检查是否出现违背断言的情况，并统计断言被测试的情况，最后得到断言覆盖率。当被用于模拟时，断言是潜在的，因为在一个测试或者一系列测试中可能不会出现断言寻找的情况。
3．2 验证完成依据
制订指标的目的主要是为了让验证人员把握功能验证的进展情况，有针对性地编写提高覆盖率的测试。并不是说一旦代码覆盖率达到100%，功能覆盖率达到95%，对模块的功能验证就可以结束。代码覆盖率和功能覆盖率都达到较高值，并不意味着验证已经完全，它只是必要条件，而不是充分条件。在某些实际验证中，代码覆盖率达到100%，功能覆盖率也很高，但继续生成激励进行测试仍然找到不少错误。原因是：验证人员永远无法保证功能点的定义是完全的，因此功能覆盖率大小不具备严格的数值含义，应该主要考虑功能覆盖率有没有提高余地。
总的来说，为了确保验证是比较完善的，首先要求代码覆盖率和功能覆盖率都达到前面制订的指标；然后再生成大量的伪随机激励进行测试，如果还是没有发现错误，并且运行大量的激励（本文测试时定为10万个左右）都不能再使功能覆盖率增加（功能点的定义已经比较全面），就认为功能验证比较完善了。
4 验证指标和流程的结合
笔者研究了如何将验证指标和网络接口的伪随机验证流程结合起来，用制订的指标指导伪随机验证工作的进行。改进后的伪随机验证过程分为以下几步：
第一步：制订测试计划和覆盖计划
完善的测试计划和覆盖计划对于确保完整的验证是一个好的开始。可以依靠经验和创造性来识别容易出现错误的地方。最明智的做法是：在制订测试计划的过程中，征求具有广泛验证经验的工程师和网络接口设计者的意见。值得注意的是没有测试计划能够包括所有可能出错的情况，这就显示了产生有指导的随机激励的重要性，因为一些设计人员没想到的导致出现错误的情况，可能会被随机生成的激励测试到。然而，一个好的测试计划对于提高验证效率仍然是极其重要的。覆盖计划为获取功能点提供了基础。
第二步：建立验证环境
在建立验证环境阶段主要完成以下工作：
描述数据结构。
获得网络接口模型（DUT）和参考模型。
编写驱动模块，实现将生成的伪随机激励加载到DUT和参考模型。
编写检验模块，实现DUT和参考模型处理结果的自动检查。
描述功能点。
第三步：编写测试并模拟测试生成的伪随机激励
编写测试，测试中主要是对数据结构中域的各种约束，约束解析器根据数据结构和测试中的约束定义，生成伪随机激励；驱动模块将生成的激励序列作适当处理后，加载到网络接口RTL模型和参考模型，通过对比两者的输出是否一致，来判断设计中是否有错；如果设计中定义了断言，还可通过考察模拟中断言有没有被违背来判断有无错误；网络接口模型模拟运行过程中，功能覆盖率统计工具根据模运行情况得到功能覆盖率。
分析功能覆盖率。如果功能覆盖率较低，编写新的测试，定义相关约束，生成有针对性的伪随机激励序列，提高功能覆盖率。重复地分析功能覆盖报告和编写填补未覆盖区域的附加测试，直到功能覆盖率达到制订的指标。
第四步：统计代码覆盖率
重新模拟所有已经生成的激励序列，得到代码覆盖率。如果覆盖率统计工具能够同时统计代码覆盖率和功能覆盖率，则可以将第三步和第四步合在一起。
第五步：完善功能点描述
如果代码覆盖率较低，分析模拟情况，找出测试空白区域，考虑功能点是否有缺漏，增加功能点定义。再编写新的测试，定义新的约束条件，生成激励序列测试设计，统计功能点增加后的功能覆盖率。
第六步：完成验证
重复前面几步，不断通过分析代码覆盖率来完善功能点定义；针对功能覆盖率的不足，生成有针对性的激励序列来提高功能覆盖率。直到代码覆盖率和功能覆盖率都达到指标，再继续生成激励来测试，如果一直没有错误，并且模拟大量激励都不能使功能覆盖率有增加，就可以认为功能验证基本完成。