Wenhui's Rotten Pen
验证工程师与芯片验证（五）

验证工程师与芯片验证（五）

本文

芯片验证系列文章主要分为三部分：验证工程师与芯片验证、SV学习笔记、UVM学习笔记。此为 验证工程师与芯片验证 部分第五篇，主要介绍验证方法、UVM简介、UVM组件、UVM环境。

版本 说明
0.1 初版发布

参考

名称 作者 来源
《芯片验证漫游指南》 刘斌 书籍
《全面的功能验证：完整的工业流程》 Bruce Wile , John C. Goss , Wolfgang 书籍

专业术语与缩略语

缩写 全称 说明
DUT Device/Design Under Test 待测试器件/设计
RTL Register Transfer Level 寄存器传输级
ESL electric system level 电子系统级（比RTL抽象级别更高，主要用于系统建模）
CDC Cross-clock Domain Check 跨时钟域检查
EC Equivalence Check 等价性检查（形式化验证的一种方式）
PC Property Check 属性检查（形式化验证的一种方式）
HLS High Level synthesis 高阶综合
UVM Universal Verification Methodology 通用验证方法学

验证方法

写在前面

  • 目前验证方法和工具种类繁多，最好在系统了解验证方法和工具后，掌握 一整套工具箱 ，根据设计的特点选用合适的验证方法。
  • 目前的芯片设计，已经无法依赖 单一的工具、语言或方法 来达到验证的完备性。
  • 不同的语言、方法、工具以及脚本 没有绝对的优劣区分 ，比如仿真验证协同形式化验证一同完善功能覆盖率，也可能通过语言和脚本之间的整合来最终完成一项验证流程。
  • 作为一名有经验的验证工程师，需要在掌握现有的各种方法和工具的前提下，通过合理的选择，最后 保质高效低耗 地完成验证任务。

方法分类

  • 动态仿真（dynamic simulation）
  • 静态/形式检查（formal check）
  • 虚拟模型（virtual prototype）
  • 硬件加速（hardware acceleration）
  • 电源功耗（power consumption）
  • 性能评估（performance evaluation）

动态仿真

  • 该方式是通过 测试序列 和 激励生成器 驱动dut，伴随着仿真时间，进而判断 输出是否符合预期 。
  • 我们需要 仿真器 来配合这一项工作，验证人员也需要 查看比较结果和仿真波形 ，最终判断测试用例 是否通过 。
  • 如果按照激励生成方式和检查方式，我们可以将动态仿真进一步分为： 定向测试、随机测试、参考模型检查、断言检查 。

静态/形式检查

与动态仿真相对的是静态检查，它本身 不需要仿真激励 ，通过 工具的辅助 ，验证人员即可以发现设计中存在的问题。静态检查可以细分出更多种类，它们关注的领域也不相同，我们将这些方法概括为：

  • 语法检查（syntax check） ：
    1. 与编译器自带的功能一样，验证工具一旦需要建立模型，都需要编译器对目标语言提供语法检查。
    2. 仿真编译器会帮助检查语法错误，例如 拼写、声明、引用、例化、连接、定义 等常见语法错误。
    3. 不同仿真工具对语言标准的解释也可能存在少量偏差，以及严格度略有不同。
  • 语义检查（linting check） ：
    1. 语义检查和语法检查相比，是在 设计的可行性 上做 深度检查 。
    2. 语义检查使用专用工具来协助完成，例如spyglass，语义检查的范围包括： 常见的设计错误、影响覆盖率收敛的问题、可能会产生x值以及受其影响的设计部分 。
    3. 这些静态检查最大的便捷之处在于，可以 早期 发现一些 功能实现以外的设计问题 ，而且也有助于 完善设计代码 ，以便提高有效覆盖率以及RTL与网表的逻辑 一致性 。
  • 跨时钟域检查（CDC Cross-clock Domain Check） :
    1. 有些 复杂的设计 都拥有 多个时钟 ，且表现为 异步关系 ，不同模块被不同的时钟驱动，就会形成 不同的时钟域 。
    2. 拥有多时钟域的硬件，它的 跨时钟域 的逻辑通讯就需要考虑同步问题了。用来验证这些设计要求的过程被称为 跨时钟域检查 。
    3. 之所以需要同步是考虑到不同时钟域的 信号采样问题 ，当时钟域A的信号进入时钟域B被采样时， 相对于时钟B存在不同的延迟 ，这种随机性可能导致 建立时间或者保持时间无法满足 ，进而导致 不可预期 的功能失败。
    4. 这种跨时钟域问题无法通过RTL动态仿真检查出来，而通过 静态的跨时钟域检查 就可以分析这一问题。
    5. 通过该方法可以在设计早期来识别出跨时钟域的问题，CDC就是为了保证所有CDC信号都能够正确的同步，目前支持CDC检查的商业工具有Spyglass等。
  • 形式验证（formal verification） ：
    1. 等价性检查（EC， Equivalence Check）：用来保证两个电路行为是 等价 的，也可以用来检查不同抽象级的电路是否一致，例如RTL和网表。
    2. 属性检查（PC， Property Check）：又称为模型检查（MC，Model Check），电路的行为通过验证语言来描述其属性，随后通过静态方式来证明 所有状态空间 下都满足该条件，否则举出 反例 来证明设计行为 不符合属性描述 。

虚拟模型

  • 虚拟模型即 高抽象级的硬件模型 ， 软件模型 可基于硬件虚拟模型（SystemC/ESL）完成 早期开发 ，并且将反馈交给设计。这种反馈在以往的瀑布模式开发周期中是无法实现的，因为 软件往往需要等到硬件设计制造完成后才能展开 。
  • 通过虚拟模型，硬件可以 更早的获取软件反馈 而对设计进行修改。这种 硬件和软件更紧密的协作方式 ，可以体现更多的优势，比如利用虚拟模型获取 性能数据 可以对硬件早期结构提供参考意见，或者判断硬件和软件的协同任务是否可以满足 功耗目标 。
  • 在目前多核的手机移动平台上，一个增长的需求就是将不同的任务合理分配到多核上面来取得更好的性能，而这种软件层面的评估就可以在虚拟建模阶段完成。
  • 目前我们通过多项虚拟建模的技术，如 协同设计、协同仿真和验证 ，试图在 早期就发现设计缺陷 ，使得修改这些缺陷可以相对容易实施的阶段完成。
  • 虚拟模型在用SystemC实现时，通过 高阶综合（HLS）工具 可以将SystemC转为RTL或门级网表，同时可以将 虚拟模型集成到设计 中， 先行完成某些验证任务 ，待后续将其替换为RTL。

硬件加速

  • 动态仿真和静态检查方法具有各自的优势，然而他们的不具备一个优势就是 速度 。尤其是在SoC的设计体量越来越大的时候， 仿真速度 成为了制约验证进度的重要障碍。
  • 由于仿真速度的限制，一些真实的用例也无法在 RTL级仿真 很快地呈现结果，这种困难在硅后测试发现问题反馈给硬件团队时更加明显，因为通常这意味着硬件团队需要 消耗很长的仿真时间 进行分析，找到可能的问题点，拆分软件场景，进而在硬件仿真上尝试重现问题。
  • 仿真速度的限制使得无法通过仿真在早期测试软件，而这一任务一般交给 硬件加速仿真平台 。
  • 一般需要等到 硬件设计初步稳定 ，进而将其映射到可配置的硬件加速平台上面，这种方式相比于RTL仿真速度已经有了质的提升。
  • 目前业界主要的硬件加速方式分为两种， 即FPGA和专用的模拟器（仿真加速器） 。
  • FPGA主要是为软件开发提供平台，而模拟器则是为了 硬件和软件协同 验证和整个系统的测试（其本质就是FPGA硬件和仿真器软件的结合）。FPGA不可以设置断点，也无法看到大量的内部信号，而模拟器可以做到，同时速度优于RTL的动态仿真。（如Cadence的Palladium）

效能验证

  • 在移动时代，硬件提升性能的方式主要体现在以下几种：

    1. 提升原有 处理器性能、存储空间、数据总线带宽或者采取多核处理 方式。
    2. 增加额外的 协处理单元 ，或者 新的功能模块 。
    3. 在后端允许的情况下提高工作 时钟频率 。

  • 随着性能的提升， 能耗 也会逐步提高，这在过去的PC时代还不是一个显著问题，但是到了移动时代，就越发要求硬件在性能有提升的基础上，同时要考虑能耗是否也可以接受。

  • 硅前设计阶段进行能效验证，涉及的流程可分为两个部分：

    1. 功能验证： PA（Power Aware）仿真 ，通过与仿真器结合，模拟电源域的开关进行设计检查。
    2. 功耗预测与优化：通过 第三方功耗分析工具 ，结合仿真数据，进行功耗预测，并且给出分析结果。

  • 移动芯片节能技术是一项全方位的改进流程，从 工艺制程、电路、封装到模块设计、Soc设计、系统和应用软件开发 等等，整个环节都需要有效利用能量。下面这个表格是从芯片硬件和软件采用的节能技术（省去工艺制程）。

域 节能技术
硬件 多核与聚合结构、多电压域、电源门控时钟门控、保持寄存器
电源管理 稳压调节、提升屏显功耗方案、智能电源管理
软件 开发工具、动态电源时钟调节、算法程序优化

性能验证

  • 在性能验证中离不开 大量的运算或者数据传输 。硅前RTL验证的瓶颈之一在于仿真速度，而且一旦到了芯片级仿真，这一因素就更进一步放大了。
  • 在产品定义过程，对于系统的运算和数据传输都有要求，如果可以在 产品实现阶段尽早地得出性能有关的数据 ，这不但可以帮助提前验证硬件性能是否满足要求，在进度允许的情况下还可以 修改硬件设计完善其性能 。
  • 这种将 性能测试提前 的方式也可以使得硅前验证与硅后测试采用一致的测试用例，从而得出 可对比的性能数据 。
  • 性能验证是用来衡量一个系统在 特定的工作负载 下它的 响应能力和稳定性 ，同时性能报告也可以用来 分析和优化 系统的质量标准，例如可靠性和资源使用能力。
  • 性能验证是一门实用的 计算机科学工程方法 ，在软件功能测试中分类较多： 负载测试（load test）、压力测试（stress test）、浸泡测试（soak test）、尖峰冲击测试（spike test）、配置测试（configuration test）、隔断测试（isolation test） 等。
  • 目前硅前验证阶段， 性能验证还是一个新颖的概念 ，一方面由于业界对这一测试还 没有形成统一标准 ，另外也是由于性能验证更多的是在 衡量指标 ，而验证本身关注更多的是功能正确性。
  • 但同时，对一些性能要求严格的硬件设计，我们确实希望能够 更早期就得出一些数据 ，而且最好能够赶上给设计 做出反馈并加以完善 ，以此来降低开发成本。

UVM简介

写在前面

  • SystemVerilog 从2002年的3.0标准逐步发展到IEEE-1800 SystemVerilog 2012标准，是目前 IC验证的霸主 。
  • 高级的验证方法学在2011年后逐步融合，也就是VMM、OVM等逐步统一为 UVM（Universal Verification Methodology） 。
  • SV的核心特性是 面向对象、随机约束、线程通信 等，这些特性使建立验证环境十分便利。
  • 所谓验证方法学，并不是必须与某种语言绑定，而体现在验证的方法上，其目的是 提供一些可以复用的类 ，通过复用来 减轻项目中工作量 ，同时为验证新人 提供一套可靠地框架 ，这就是 验证方法学 。
  • UVM中的Universal（通用），也就是适用大多数验证项目，包括模块级到系统级，ASIC到FPGA，以及控制逻辑、数据通路到处理器验证的全部场景。
  • UVM的 框架构建类和测试类 能够帮助验证工程师减轻环境构建的负担，从而将更多精力集中在 如何指定验证计划和创建测试场景 。
  • 认识UVM应由浅入深：
    1. 认识UVM的类库和核心机制。
    2. 学习核心的UVM组件和层次结构。
    3. 了解常见的UVM组件间的通信方式。
    4. 深入UVM测试场景。
    5. UVM的寄存器模型应用。

SV与UVM的关系

  • SV是SystemVerilog，一门面向对象编程的语言，在Verilog基础上发展而来，兼容verilog的所有特性。

  • UVM不是一门语言，而是基于SytsmVerilog开发的类库，以及一套验证平台开发框架，称为验证方法学，被大部分EDA工具所支持。

  • 举例：SystemVerilog好比汉字，UVM好比基于汉字的诗词、成语、典故，当天空下雪时：

    1. SV+UVM：忽如一夜春风来，千树万树梨花开。
    2. Only SV：风景美如画，吟诗赠天下。奈何没文化，卧草雪好大。

UVM类库

UVM的类库大致分为以下几类：

  • 核心基类
  • 工厂类（factory）
  • 事务类（transaction）和序列类（sequence）
  • 结构创建类（structure creation）
  • 环境组件类（environment component）
  • 通信管道类（channel）
  • 信息报告类（message report）
  • 寄存器模型类（register model）
  • 线程同步类（thread synchronization）
  • 事务接口类（transaction interface）

UVM组件

  • 验证组件按照功能划分，可以分为 激励器（stimulator/driver）、监测器（monitor）和检查器（checker） 。
  • 这三个核心组件与验证环境的三个关键特性相对应，也就是 激励、监测和检查 。
  • 从UVM基类继承的一个核心分支，即 uvm_component类 ，它们是UVM类库中的重要成员，是 构成整个验证环境框架的基础 ，uvm_component类依据不同功能，又分为以下几个子类：
    1. uvm_driver
    2. uvm_monitor
    3. uvm_sequencer
    4. uvm_agent
    5. uvm_scoreboard
    6. uvm_env
    7. uvm_test

UVM环境

uvm环境中很重要的一点是 phase机制 。

  • 传统的硬件设计模型在仿真开始前，已经完成例化和连接了。
  • 而SV的 软件部分 对象例化是在 仿真开始后执行 的。虽然对象例化时只是通过 调用构建函数new() ，但是单单通过new()函数无法 实现验证环境的层次化 ，也就是保证例化的先后关系和各个 组件之间的连接 。
  • 如果需要实现高级功能，比如在 顶层到底层的配置 时，SV也无法在底层组件例化之前完成对底层的 配置逻辑 。
  • 因此，UVM验证环境构建时，引入 phase机制 ，通过该机制可以很清晰的 将UVM仿真阶段层次化 。这里层次化，不仅仅是 各个phase的执行顺序 ，还有 同一phase中的层次化组件之间phase也有先后关系 。
phase 函数/任务 执行顺序 功能 典型应用
build 函数 自顶向下 创建和配置测试平台的结构 创建组件和寄存器模型，设置或者获取设置
connect 函数 自底向上 建立组件之间的连接 连接TLM的接口，连接寄存器模型和adapter
end_of_elaboration 函数 自底向上 测试环境的微调 显示环境结构、打开文件，为组件添加额外配置
start_of_simulation 函数 自底向上 准备测试环境的仿真 显示环境结构、设置断点，设置初始运行时的配置值
run 任务 自底向上 激励设计 提供激励、采集数据、数据比较
extract 函数 自底向上 从测试环境中收集数据 从测试平台提取剩余数据，从设计观察最终状态
check 函数 自底向上 检查任何不期望的行为 检查不期望的数据
report 函数 自底向上 报告测试数据 报告测试结果，并将其写入文件中
final 函数 自顶向下 完成测试活动、结束仿真 关闭文件，结束联合仿真引擎
创建测试平台
phase机制

文章原创，可能存在部分错误，欢迎指正，联系邮箱 cao_arvin@163.com。

文章目录