b型人格的性格特征:验证方法学浅谈 --- 验证工具

 Linting tool

Linting tool根据设计的RTL描述代码结构做静态分析，推断描述代码存在的逻辑错误，但无法决定描述代码是否能够现实设计要求的功能。linting tool可用于强制代码遵从编写规范，由于Linting工具是静态验证工具，因此运行速度会，可以节省时间。其缺点是多疑，误报率高，产生大量不存在的错误警告，因此要对不存在的错误警告仔细过滤，注意避免滤出真实的错误警告，变量名最好符合命名惯例，有助于过滤。由于Verilog不是强类型语言，使用Linting tool非常有用，可以检测race conditions 及数据宽度不匹配，可保证Verilog正确描述数据处理过程，避免造成数据的弃位及增位现象，这种错误通过仿真并不一定发现。因为verilog 语言的特点， 对Verilog描述的设计，Linting tool是一种有益的验证工具。因为VHDL 语言的特点，对VHDL使用Linting tool的作用不如对Verilog语言那么明显，但Linting tool还是能发现一些潜在的问题。

仿真器

仿真器通过忽略及简化设计的物理特性，对设计的实现进行模拟。仿真器通过执行RTL级的设计描述，模拟设计的物理实现，它无法确定设计真实的物理实现与设计描述之间的区别。仿真的结果取决于设计描述是否准确反映了设计的物理实现。仿真器不是一个静态工具，需要Stimulus和Reponse。Stimulus由模拟设计工作环境的testbench 产生，Reponse为仿真的输出，由设计者确定输出的有效性。

仿真器的类型分为3种类型，Event-driven Simulator（事件驱动仿真器）、Cycle-Based Simulator（基于周期的仿真器）、Co-Simulator（联合仿真器），分别介绍如下：

1．Event-driven Simulator

将信号的变化定义为一个事件，该事件驱动仿真执行，事件驱动仿真器能准确地模拟设计的时序特征，可模拟异步设计。时间驱动仿真器的工作过程如图9所示。

 2．Cycle-based simulator

基于周期的仿真器的特点是忽略设计的时序，假定所有flip_flop的setup和hold时间都满足要求，在一个时钟周期，信号仅更新一次，从而信号必须与时钟同步。仿真速度比事件驱动仿真器高。基于周期的仿真器的工作过程步骤是，首先编译电路，将组合逻辑压缩成单独的表达式，根据该表达式可确定flop的输入，然后执行仿真，遇到时钟的有效沿， flip_flop 的值被更新。基于周期的仿真器的缺点是不能仿真异步电路，不能进行验证设计的时序。

3．Co-Simulators

联合仿真器对同一设计各个部分，分别用不同的仿真器仿真，如即含有同步设计又含有异步设计的电路，可用Event-driven Simulator对异步设计仿真，用Cycle-based Simulator对异步设计仿真。联合仿真器中各个Simulator 的操作是locked-step的，类似于电路的pipeline 操作。其缺点是由于不同仿真器之间需要同步和相互通讯，Co-Simulators的仿真速度受到最慢Simulator的限制，因而影响仿真器的性能，而且在各仿真器传送的信息会产生多义性。

4．Hardware modeler

硬件模拟器创建一个物理芯片的逻辑模型，向仿真器提供该芯片的行为信息，芯片和仿真器的通信过是首先将物理芯片插入硬件仿真器，然后格式化来自仿真器的数据，作为该芯片的输入，最后将该芯片输出的数据，包含时序信息，送往仿真器。硬件模拟器可以提供很高的仿真速度，但是设备价格高昂。需要注意的是，硬件模拟器做的仍然是功能仿真，而不是时序仿真，因为芯片是降频运行的。

[attach]61[/attach]

图10为硬件模拟器系统框图

波形观察器

仿真调试的过程中波形观察器是必不可少的工具，它能提供信号状态和变化的详细信息，但是波形观察器不能用来判断一个设计是否通过验证，因为波形是不可重复的且无法用于递归仿真。波形观察器的优点是可以观察仿真的整个过程，有利于设计及testbench 的诊断，缺点是由于要输出波形，影响了仿真的速度，因此应尽可能限制在波形图中显示的信号数量及时间长度。波形观察器的另一个作用是波形比较，主要用于redesign，保证设计具有cycle-accurate的后向兼容性。在波形比较中，不能仅看表象，需仔细分析，确认波形之间存在的差别是有意义的。例如，有时我们仅关心波形transitions之间的相对位置，而不关心它的绝对位置。图11为波形观察器的工作流程

代码覆盖率

代码覆盖率（Code Coverage）可以指示Verilog代码描述的功能多少被验证。

代码覆盖率有三种计算方法，第一种是Statement coverage(block coverage)，即语句覆盖率，指示验证过程中，设计代码被执行的语句数量。有时，我们会添加一些没有具体设计意义的语句，仅用于监视代码执行过程中的异常或标注一些设计中的假设。这些语句可不参与Statement coverage的统计；

第二种是Path coverage，即分支覆盖率，在设计中往往通过分支控制语句来完成对功能的控制，我们将所有分支控制语句的控制状态进行组合，产生一定数量语句执行path，Path coverage指示所有的语句执行path是否都得以执行。

第三种是Expression Coverage，即表达式覆盖率，指示分支控制语句的控制条件是否全部有效。 需要注意的是百分之百的Code Coverage仅仅表示了代码都被执行了，不能证明设计的正确性。代码覆盖率可以用于衡量验证工作是否完成。