【数字IC验证快速入门】12、SystemVerilog TestBench（SVTB）入门

导读：作者有幸在中国电子信息领域的排头兵院校“电子科技大学”攻读研究生期间，接触到前沿的数字IC验证知识，旁听到诸如华为海思、清华紫光、联发科技等业界顶尖集成电路相关企业面授课程，对数字IC验证有了一些知识积累和学习心得。为帮助想入门前端IC验证的朋友，思忱一二后，特开此专栏，以期花最短的时间，走最少的弯路，学最多的IC验证技术知识。

一、专栏概述

专栏大纲

• 专栏涵盖数字集成电路的功能验证流程和技术
• 逻辑仿真，激励生成，结果检查，覆盖率，调试技术，断言技术
  • 通常验证的“结果检查”不去检查时序，仅仅检查逻辑功能。因为如果要去检查时序，随着DUT时序的变化，环境的时序也会去变化。
  • 通常在断言中去检查时序
• 应用所学验证知识解决数字电路系统中的功能验证问题

预备知识

• 熟悉Verilog或VHDL硬件描述语言
• Linux基础
• gvim基础

SystemVerilog大纲

• 1、验证计划和验证环境
  • Verification Plan 在项目开始是非常重要的！
• 2、SystemVerilog语言的验证属性
• 3、SystemVerilog Testbench
• 4、接口 Interface
• 5、面向对象编程 OOP
• 6、随机化 Randomization
• 7、线程 Threads
• 8、内部通信 Interprocess Communication
• 9、功能验证 Functional Coverage
• 10、断言 Assertions

参考书籍

• 1、SystemVerilog for Verification, third edition, Springer 2012.
• 2、SystemVerilog Assertions, Springer 2005

注：仅仅作为工具书，不要啃书，浪费精力，多去用！

二、SystemVerilog TestBench 功能

• 产生激励
  • 将激励分成了两层，一层是功能（源头），另一层是Driver。
  • 比如要产生报文，本层决定了报文Head是产生55AA还是0033？
  • 比如运输苹果，本层只负责打包！
• 驱动激励
  • Driver 专门去产生跟DUT接口相关的信号时序
  • Driver 相当于物理通道
  • 比如运输苹果，本层只负责运输，至于选择何种运输方式跟之前的打包是无关的！（可重用性更高）
• 采样响应
• 检查响应的正确性
• 根据验证目标评估验证进度
  • 收集覆盖率（代码 - 行、条件、FSM、Toggle；功能），来看看验证完备性

三、基于EDA的数字系统搞设计（SoC Design based on EDA）

• 超大规模SoC系统芯片设计依赖于：电子设计自动化工具（Electronic Design Automation，EDA）
  • 基于CMOS搭建电路无法制作大规模，所以就有了工具
  • RTL --（MAP） --> Netlist --（Implentation）–> GDSII
• 三大EDA厂商：Synopsys、Cadence、Mentor
• 数字逻辑仿真工具：VCS、IES、Questasim
• 数字逻辑仿真工具：DC、Genus
• 形式验证工具：Formality、Conformal
  • 形式验证是验证经过MAP之后的Netlist功能是否OK
  • 涉及到了STD CELL 数据分析更复杂一些，如果直接用EDA工具去验会很慢，这个过程也是个动态验证（验证用例随着时间在不停的走）
  • Formal 是静态验证，点（如RTL与门）对点（如Netlist与门）的验证逻辑功能，不会涉及到时序
• 静态时序分析工具：PrimeTime、Tempus
• 可测试性实现工具：Tessent
• 数字版图设计工具：ICC、Innovous、Olympus
• 数字物理验证工具：Calibre

四、数字芯片设计工艺

• 主流工艺：28nm CMOS
• 先进工艺：16/14nm 3D
• 2017：16/14nm 工艺
• 2018：10/7nm 工艺

注：x nm指的是CMOS晶体管的直径。

管子越小，体积越小，功耗也有相应的收益！

五、数字芯片设计流程中常使用的语言

• 硬件描述语言

  • VHDL（欧洲、印度）
  • Verilog（中国、美国）
  • SystemVerilog Design（很少用）

• 硬件验证语言

  • SystemVerilog Verification（OOP：面向对象；属性、行为；Random Constraint 带约束）
  • SystemVerilog Assertion（测时序、设计也会用；验证使用Assertion更多的是用它的Cover去弥补功能覆盖率的描述-这种情况通常SV不好描述）
  • SystemC（很少有）
  • C/C++（很少用）

• 脚本语言

  • Shell（Bash shell）
  • Makefile（Questasim）
  • Perl（前几年流行）
  • Python（流行、AI）
  • TCL（也是前几年流行）

六、数字芯片设计设计方法

• 自顶向下（架构）
• 自底向上（电路）
• 可重用
  • 参数化（如：位宽）
  • IP化（DIP - RTL的一个IP）
• 低功耗设计
  • Clock gating（用的较多）
  • Power gating（做MCU、手机芯片会用的较多；省电）
• 验证方法学
  • VMM、OVM、UVM
  • VIP
  • AIP

七、制定验证计划和分层的验证平台

7.1、内容

• Verification Plan 验证计划
• Verification Environment 验证环境
• Verification Guidelines 验证原则

7.2、验证策略

如何验证RTL设计代码？

• 需要哪些资源？
  • 硬盘空间有多大（通常TB级别）？CPU资源够不够？EDA License够不够？
• 需要验证哪些内容？
  • RTL特性？不同特性放到不同平台去实现。
  • EDA验哪些？FPGA验哪些？应用平台（EMV）验哪些？
  • 分解各个平台的测试点，规划测试用例
• 是否输入应用场景所对应的所有可能？
  • 输入符合实际应用场景
  • 其他的corner（边界）case
  • 其他的异常 case
• 如何发现错误？
  • 看波形和自动比较（原则上自动比较，有必要看波形）
• 如何衡量验证进度？
  • 覆盖率驱动的验证策略（代码覆盖率、功能覆盖率）
• 什么时间验证结束？
  • 覆盖率 100%（或验不到的点可以进行解释）

7.3、验证进度

• Regression：回归，把所有的用例集中起来一轮一轮的去跑，每次跑的随机种子不一样，灌输的激励也不一样，打到的验证点也不一样。

7.4、验证计划的内容

• 验证层次描述（单元 -> 模块 -> IP）
• 需要的工具：逻辑仿真工具、自行开发的工具、软硬件协同
• 风险和前提条件
• 验证功能点
• 特定的验证方法
  • 一般是覆盖率驱动验证策略（CDV，Coverage Driven Verification）
• 覆盖率要求：代码覆盖率 + 功能覆盖率
• 测试用例的应用场景：上电复位、数据传输、命令处理、容错处理
• 资源要求：人员、硬件、软件
  • 验证组长来考虑
• 时间安排：TestBench、TestCase（用例）、Regression（回归）

7.4.1、验证的层次

• 设计层次结构要明细：unit -> block -> ip -> SoC
• 将不同的电路层次结构组合成功能组件
  • 每个功能模块的复杂程度
    • 复杂功能需要较高的可控制性和可观察性
    • 简单功能不需要，可以在其他不同的层次结构进行控制和观察
  • 接口定义和设计规格要清晰
    • 可变接口的功能必须独立验证
    • 功能简单的稳定接口可以跟其他模块组合验证

7.4.2、需要的EDA工具

• 逻辑仿真工具：QuestaSim、IES、VCS
• 形式验证工具：Conformal、Formality
• 基于断言的工具（System Verilog）
• 调试工具：VSIM、Verdi、DVE
• 硬件加速仿真器：Veloce、Palladium（更大的FPGA阵列，可以吃进整个系统，运行速度通常在几十KHz，弱于FPGA，强于EDA；成本较高）
• 软硬件联合仿真：FPGA原型验证（FPGA通常模块级的功能，仿真速度快，运行速度最高可达200M）
• 高级验证语言：SystemVerilog、SystemC、C/C++
• 功能库文件（跟工艺库的有关系）
• VIP、AIP

7.4.3、风险和前提条件

• 工具风险
  • EDA工具的购买、EDA工具的问题
  • EDA工具的使用培训
  • 自行开发的工具存在问题
• RTL设计代码的及时发布
  • 先发布第一版的简单功能的RTL，之后再发布功能复杂的RTL代码
• 依赖于独立的验证团队
• 设计架构的收敛
  • 悬而未决的设计需求
• 资源是否充足（硬盘、CPU）

7.4.4、功能点划分

• 关键功能
  • 设计必须会使用的功能
• 次要功能
  • 针对流片而言，而非关键功能
    • 与性能相关的功能
    • 下个版本可以实现的功能
    • 软件可以实现的功能
  • 下一个验证层次中，非关键功能
    • 可以在不同层次，可并行验证的功能
    • 边角条件的情况
• 通用功能
  • 正常运行过程中不会发生的操作
  • 系统复位和时钟的生成
  • 错误处理
  • 系统调试
• 本层次不需要验证的功能
  • 在逻辑仿真过程中，可以在较低层次的验证，也可以在更高的层次验证的功能
  • 在该层次上不使用的功能

7.4.5、特定的验证方法

• 验证类型

  • 需要验证的功能（正常）
  • 内部结构（设计）
  • 错误现象（异常）
  • 资源可以用性

• 验证策略

  • 确定性仿真 - 简单设计
  • 随机化仿真 - 复杂设计（以时间换空间；打到人脑意想不到的点）
  • 形式化验证

• 随机验证

  • 因为循环导致hang（挂死）
  • 低概率应用场景
  • 特定的直接测试用例

• 抽象层次

• 检测策略

  • 白盒验证（SVA）
  • 灰盒验证
  • 黑盒验证（对比RM）

7.4.6、覆盖率需求

• 定义覆盖率目标：通过反馈机制来确定验证环境的激励生成质量（完备性 -> 覆盖率）
  • 所有的命令和响应类型
  • 特定的数据类型和数据的数值范围
  • 所有有效激励
  • 容错处理（异常场景）
• 统计覆盖率
• 分析覆盖率漏洞
• 必要情况下，编写定向测试用例

7.4.7、测试用例应用场景

• 列出所有的实际应用场景（分解测试点的原则）
  • 需要验证的配置项（配置寄存器）
  • 验证环境中的数据变量
  • 数据的重要属性（范围、有无符号）
  • 所有DUT输入端口的实际序列
  • 错误条件（Error handling）
  • 边界条件（Corner case）

7.4.8、资源要求

• 人力资源
  • 验证环境类型（复杂度）
    • 手动检查和比对参考模型需要更多的人手
    • 基于事务级的验证环境需要的人手少
  • 工程师的项目经验
• 计算资源
  • 测试用例的运行时间 乘以 测试案例的数量，决定硬件和软件的资源量（实际可能并不会这么机械操作）
    • CPU + 内存 + 磁盘
    • EDA工具License

7.4.9、时间安排（Schedule）

• 列出不同验证活动的时间安排
  • 验证团队提交的结果和内容
  • 验证主要工作、流程和标准
• 项目进度安排包括
  • 设计架构和文档的正式发布时间（Specification Delivery）
  • 验证平台开发（Verification Environment Development）
  • 第一版RTL设计代码的发布时间
  • 一个基本测试用例跑通时间（Base Flow）
  • 启动回归测试的时间（Regression Run）
  • 流片的时间（Release to Manufacturing）
• 项目时间安排需要考虑设计层次结构（each level of hierarchy）
• 当验证发现的RTL问题的几率降低时，验证工作必须进行到下一个层次（尤其是对于继承性的项目）
  • Bug Rate

• IC设计工程师回去做代码的检视（Code Review）
• 单元级验证（UT）、模块级验证（BT）、系统级验证（ST）
• 低层次的验证不利于发现更多的RTL代码问题，因为这些问题出现在整个设计周期的早期，每个设计工程师的验证或单元级的验证都是并行开发的。实践经验表明：当RTL出现的问题几率降低时，可以将验证工作从低层次迁移到更高的层次，比如从单元级验证迁移到模块级验证。

7.5、验证环境

• 验证平台的组件（TestBench Components）
  • 验证平台环绕在DUT周围
    • 产生激励（Generate stimulus）
    • 获取响应（Capture response）
    • 检查正确性（Check for correctness）
    • 通过覆盖率衡量验证进度（Measure progress through coverage matrix）
• 验证平台的属性（Features of an effective Testbench）
  • 可重用性，易于修改
    • 面向对象编程（Object oriented programming）
  • 分层的验证平台易于重用
    • 扁平化的验证平台难于修改和维护
    • 分层的验证平台将代码分隔成独立的模块，将通用的功能放在一段代码中
  • 迅速获取信息并快速达到较高的覆盖率
    • 随机化验证技术（Randomize！！）

• DUT

  • 是最终拿去生产的实际电路，通常是RTL级描述，使用Verilog描述语言编写
  • 综合 -> 网表 -> GDSII -> Chip

• TestBench

  • 行为级的描述，更多是软件的仿真

7.5.1、分层的验证平台

• 信号层（Signal layer）
  • DUT和TestBench的连接（interface，后面详细介绍）
• 命令层（Command layer）
  • 驱动器（Driver）
    • 将命令如send（）、read（）、write转换成信号，驱动DUT
  • 接收器（Receiver或Monitor）
    • 将DUT的输出信号转换成命令
  • 编写断言（Assertions）
    • 断言可以对基于时钟周期的系统行为进行建模
    • 大部分的比对不带时序，比较与RM结果。但是断言能看到时序！

注：代码看不懂，先不用细究！

• 功能层（Functional Layer）
  • 将事务级信息（transcations）转换成命令驱动到DUT，比如DMA readoperation
  • 代理器（Agent）
    • 暂存事务级信息，按照一定的顺序发送这些信息
    • 并不关注实际的时序，实际的时序是下层的Driver来关注！
  • 检查器（Checker）
    • 接收DUT的输出数据，并与期望的结果进行比对
  • 计分板（ScoreBoard）
    • 将比较结果反馈在计分板中

• 应用层（Scenario Layer）
  • 生成器（Generator）
    • 生成定向的数据
    • 定向测试
    • 带约束的随机测试

• push_back()是SV中队列（queue）支持的系统函数，可以在队尾插入对象（object）

附：理解各个层次的关系：

类比：发送一堆水果，而水果中包含苹果和香蕉

• Generator负责把苹果、香蕉采下来给Agent
• Agent负责把诸如先发送5个苹果再发送5个香蕉这个事情组织并打包好，打包好之后给Driver
• Driver负责选取交通方式，是火车来发，还是轮船来发
• DUT代表具体的交通工具，火车或轮船

从上面的描述中不难看出，由于分层，当某一层发生变化，只需要改变部分层，其它层还是可以重用的。

• 测试层（test）

  • 测试用例可以控制所有输入到验证环境中的所有内容
  • 为输入的激励信息设置约束
  • 组合多个测试用例

• 功能覆盖率（Functional Coverage）

  • 利用功能覆盖率的统计结果来调整约束，产生下一步的输入激励

附：理解各个层次的关系：

类比：把验证比作一场交响音乐会，Generator、Agent、Scoreboard、Checker、Driver、Receiver等比作不同的乐器，那么Test的作用就是指挥家，整个音乐会的源头！

7.5.2、分层的验证平台好处

• 更新验证环境的时间少
• 通过顶层文件可以很容易配置验证平台
• 测试期间所有的有效的配置（随机化策略关系较大）
  • 选择不同的设计配置可以进行回归测试
  • 带约束的随机化配置对象
• 提高可重用性、可维护性

八、小结

• 验证层次

  • unit 级（arith-alu/shift-alu/Preprocessor）
  • block 级（ALU）
  • IP 级（ALU+Preprocessor）

• 验证语言：SystemVerilog

• 验证工具：Questasim

• 覆盖率统计：功能覆盖率 + 代码覆盖率