SystemVerilog与功能验证-学习笔记——第一章:功能验证技术与方法学概要(一)

功能验证技术与方法学概要(一)- 功能验证与验证平台

  • 1.1 功能验证与验证平台
    • 1.1.1 专用芯片设计流程
    • 1.1.2 什么是验证
    • 1.1.3 验证平台可以做些什么
    • 1.1.4 功能验证流程

  本章从芯片设计流程入手,讨论功能验证在整个流程中的位置及其所涵盖的内容,并介绍目前流行的各种验证技术和验证方法学,最后介绍常用的验证语言SystemVerilog、E、PSL、SystemC、Vera。

1.1 功能验证与验证平台

  验证主要包括功能验证、物理验证、时序验证等,本书主要讲解功能验证,针对芯片设计对象的行为功能进行验证,确保设计能够按照实现预期的效果。通过验证语言。硬件描述语言或C语言等可搭建验证平台(testbench)。
  验证平台需要提高足够的自动化机制来提高每一个测试用例(test case)的功能覆盖率和减少创建测试用例的时间。但是这可能会增加测试平台的复杂度和投入的时间。

1.1.1 专用芯片设计流程

  在图1-1中,功能测试被看做一个独立的模块,实际中包含了定义测试用例、创建测试环境、运行测试用例、保证所有要求的用例被覆盖到等复杂的过程。
  从图中可以看出,验证从设定规范完成后就可以开始了,一种持续到版图完成,甚至很多情况下超出版图完成阶段。
SystemVerilog与功能验证-学习笔记——第一章:功能验证技术与方法学概要(一)_第1张图片

1.1.2 什么是验证

验证是确保设计和预期设计期望一致的过程,设计通常是通过一个或多个设计规范来定义的。对于专用芯片设计,在不同阶段有不同的验证形式:
(1)寄存器传输级(register transfer level,RTL)的功能验证。
(2)门级的仿真,为了验证综合后的网表是否和期望的功能一致。
(3)形式验证(等价性检查)来确保门级网表和RTL代码的一致性。
(4)时序验证,为了验证设计能否在特定的频率上运行,通常采用静态验证工具。
  文中提到的验证(verification)均为寄存器传输级(RTL)的功能验证。功能验证在专用集成芯片设计流程中关注设计的行为,几乎所有的功能都可以在 RTL层次被验证。
  图 12展示了一个高层次的功能验证视图。一个专用集成芯片设计可以被看成拥有一 系列输入和输出的集合,设计的输出是基于设计的输入和当前的状态。在功能验证的过程 中,工程师在被测设计(design under test,DUT)外搭建验证平台。验证平台被用来应用 一个或者多个测试激励,并将激励发送到设计的输入中。激励可以通过验证平台产生,或者通过手动创建。最后,输出将进行比较,看结果是否正确。结果检查可以通过验证平台、 脚本或者手工来实现。
SystemVerilog与功能验证-学习笔记——第一章:功能验证技术与方法学概要(一)_第2张图片

1.1.3 验证平台可以做些什么

  验证平台的主要功能如下:
(1)产生激励。
(2)把激励应用到被测设计中。
(3)检查结果和验证测试是否通过,也就是确保被测设计的输出和期望一致。

  1. 激励产生的途径
    SystemVerilog与功能验证-学习笔记——第一章:功能验证技术与方法学概要(一)_第3张图片
      如何区分二进制激励和用户激励很重要。二进制激励是驱动到被测设计的引脚中的1 和1序列,如图1-3所示;用户激励是一个来自用户的指令(对信号赋值驱动或者通过对函数或者任务的调用)让验证平台可以运行某些操作。在传统的验证平台中,二进制激励和用户激励可以是一致的。
    SystemVerilog与功能验证-学习笔记——第一章:功能验证技术与方法学概要(一)_第4张图片
      产生用户激励的途径有很多种,可以是直接的,也可以是随机的。如果激励是从用户 提供的确定输入,这就是所谓的直接测试(direct test)。如果激励是根据种子随机生成,这就是所谓的随机测试(random test)。
      传统验证平台激励过程:按照一定时间顺序把二进制序列送入到被测设计中。
      高级验证平台激励过程:激励在更高层次被用户抽象建模并封装。
      下面以一个存储器的读写来解释直接测试和事务级激励产生。
    ①直接测试
      传统手工创建直接测试,是通过驱动每个信号的数值来实现。
    ②事务级激励产生
      通过对激励和验证架构进行分层和高层 抽象建模,也就是所谓的事务级的验证(transaction based verification),如 本 例 中 的rd_mem,wr_mem这种封装好的任务后,激励生成器可以将其生成的高层激励(可以是一组数据的集合)传递给它,如图 1-4所示,这样可以大大提高激励产生的效率。SystemVerilog与功能验证-学习笔记——第一章:功能验证技术与方法学概要(一)_第5张图片
      在一个更加高级的验证平台中,激励可以根据用户指定的约束,完全通过验证平台自 动产生,这就所谓的约束随机激励产生(constrained random stimulus generation),如图 1-5所示。例如,用户要把包的大小约束在64比特和1522比特之间,并且在两者之间做一个权重配置方案。验证平台将可以自动生成和将随机包注入被测设计中。
    SystemVerilog与功能验证-学习笔记——第一章:功能验证技术与方法学概要(一)_第6张图片

  2. 应用二进制激励
      最终,验证平台将把一个或者多个激励序列注入被测设计中。验证平台通过高层次的 操作应用高层次的用户激励,二进制激励由验证平台生成并且通过对应的接口发送到被测 设计中。在验证平台中,实现这种功能的验证组件(verification component,VC) 被称为事务处理器(transactor)或者总线功能模型(Bus Function Model,BFM)。在本书中,我们采 用事务处理器作为表述。

  3. 结果检查
      生成和应用二进制激励到被测设计中是验证平台的主要任务。此外,验证的目的是检查输出是否与预期一致,也就是结果检查。检查结果的方法有:
    (1)**波形窗口检查:**适用于简单设计,可能出现人为错误,而且不精准。如果这个设计需要回归测试,那么一定程度上的自动化结果检查是必要的。
    (2)**通过自动化的后处理比较:**记录被测设计的输出,通过运行脚本来比对结果。结果后处理是常用的一种手段,既不需要添加太多代码,又不会影响仿真效果(过多的打印信息可能会导致仿真速度下降,因为对文件I/O操作过多)。复杂的设计中,必须考虑要打印的信息,以免太多造成过大的日志文件。可以考虑通过高层抽象来记录信息,以减少日志文件。
      结果后处理的因一个好处就是,结果可以由其他语言来实现后处理,如C/C++、perl。但是只能在测试结束之后才能进行,出错的话需要重新进行仿真,浪费很多时间。
    (3)**做一个实时的监察器可以及时自动检查:**实时的监控器需要投入额外的开发,然而 它们相当有用,特别是对于调试,一旦发生比对错误,它们可以通过设置错误标志或者打 印信息提醒用户;在任何时刻,仿真器和验证平台的状态对用户完全可见,而且在发生错 误的时刻,通过停止仿真可以缩短调试周期。
    目前较多应用后处理和实时两种处理方法,这取决于设计的复杂度和 接口的数目以及验证平台的应用层次。

1.1.4 功能验证流程

SystemVerilog与功能验证-学习笔记——第一章:功能验证技术与方法学概要(一)_第7张图片

  图1-6显示了功能验证流程。这个验证过程可以被分解成三个主要阶段:(1)制定验证策略和验证计划;(2)创建验证平台,运行和调试;(3)覆盖率分析和回归测试。
1.制定验证策略和验证计划阶段
制定验证策略和验证计划阶段主要处理以下三个问题。
(1)主要功能点和测试用例
  复杂设计需要的测试点非常多(即测试空间很大),可达上亿个,因此需要将测试空间缩小到一个可以管理的范围,并且不会损害其期望;针对这些功能点,我们将根据具体情 况拟定验证策略和测试用例,最后具体化到一个详细的、可执行的验证计划中,作为整个 验证工作的指导。
(2)验证平台的抽象层次
  验证平台的抽象层次将决定它主要的处理对象:比特、包或者更高层次的数据类型。 高层次的抽象建模可以让验证平台中低层次的功能自动化。
(3)激励生成和结果检查原则 这些原则定义了输入到验证平台的激励是如何提供的,结果是如何检查的,并判断测 试是通过还是失败。
2. 验证平台搭建阶段
  这是第二个阶段,也就是验证平台的搭建,书写测试用例和调试阶段。在这个阶段, 书写验证平台代码和测试用例。验证平台持续被扩展,因为测试用例不断被添加进来。其 中,验证平台的搭建要以可重用为基本原则,而且能够方便设计工程师和验证工程师添加 测试用例。
3. 回归测试和覆盖率收敛阶段
  一旦几乎全部测试用例被成功运行,验证就进入了回归测试 (regressiontest)和覆盖率 收敛阶段。回归测试要求能够周期的批处理运行,二是激励必须能够容易得到重现,成功 或者失败能够自动检查。覆盖率显示出该设计被测试的程度,是验证收敛的重要标准。
  在这个阶段,所有的测试应该在每天或者每周做回归而且周期性的运行。设计或者验 证工程师应该查看覆盖率,从而修改或者添加更多的测试用例。目标是达到 100%,或者尽 可能达到 100%。
  不同的设计有不同的验证流程。不存在一个对任何设计都为最好的验证流程。每个设 计都有其不同的地方,而且有自身的验证流程。例如简单的设计,激励产生和结果检查策略可能将不会被显示的定义。它们可能运行在总线层次的事务交易中,验证平台使用传统的直接测试,但是它也可能不做检查。对于复杂的设计,所有的激励生成方法或者结果检查规则都是预先定义好的。一般来说,对于这些设计的验证平台都 是在一个较高的抽象层次上操作。
  验证流程同样也可能取决于被验证设计的层次,也就是它将验证多大规模的代码。例 如,一个芯片可以分解为几个模块。为此,可以为每个模块搭建一个独立的验证平台,同 时可以有一个验证平台在芯片级做验证。某些设计,芯片可能是一个系统,可能存在几个 芯片级或者系统级的验证平台。
  每个模块级的验证平台主要的目的是帮助调试各个模块中的实现,使集成到芯片中更 加容易,然而芯片级的验证平台主要测试的是各个模块之间的交互功能。

参考书籍:SystemVerilog与功能验证

你可能感兴趣的:(IC,systemVerilog,验证)