芯片验证漫游指南-读书笔记

jerwey

已于 2022-06-15 16:58:30 修改

阅读量1.2k

点赞数

分类专栏： IC 文章标签： ic验证

于 2022-04-06 21:51:56 首次发布

本文链接：https://blog.csdn.net/jerwey/article/details/124000608

版权

本文详细探讨了芯片验证的策略，包括设计流程、验证层次、透明度和激励原则，强调了验证的组合自由度和组件独立性。接着介绍了验证方法，如动态仿真、静态检查和硬件加速，强调了基于TLM的随机验证和断言检查的重要性。此外，还讨论了验证环境的构建，特别是SystemVerilog（SV）在验证环境中的应用，包括数据类型、模块定义、接口和程序的使用。最后，文章提及了并发线程在验证中的应用，如fork-join机制。

摘要由CSDN通过智能技术生成

2 验证的策略

2.1 设计的流程

芯片功能的细分
人员的任务分配
TLM（事务级模型，transaction level Model），用于早期的设计和验证。如果足够准确，可以代替验证人员的参考模型，
2.1.1 TLM模型的需求和ESL开发
为了软件和硬件人员同时进行开发，需要系统结构人员构建一个高抽象级的系统。通过将功能描述成可运行的系统，让软硬件人员子在早期利用该系统可以并行开发的方式称为ESL（电子系统级，electronic system-level）开发。
2.1.2 传统的系统设计流程
瀑布形式。这种顺序开发的方式存在明显的边界。时间和组织边界。
2.1.3 ESL系统设计流程
在ESL 开发的协助下，其余的开发流程可以更早地与系统设
计一块进行开发，从整体上看，这种方式有助于缩短芯片开发的时间。除此之外，ESL 在前期产品定义的阶段有相对可量化的模型，有助于早期评估产品的功能、性能是否满足户要求，也能减轻十些低配置性能的风险以及降低过多设计的成本。
systemC可以满足TLM模型开发的一种语言。
2.1.4 语言抽象级比较
vhdl、verilog主要用作RTL仿真和数字电路的综合；SV用于功能验证，也可以描述硬件做RTL仿真和门级综合；SystemC偏向于系统级。
2.1.5 传统的系统集成视角
2.1.6 ESL系统集成视角
ESL系统开发方式在系统定义阶段建立TLM模型。TLM建模对系统人员有更高的技能要求。不但要求掌握SystemC开发，同时要有硬件描述的基础。他们的工作量同时包括功能描述文档和TLM模型，且TLM需准确翻译功能描述文档。

2.2 验证的层次

按层次划分：硅后系统级、芯片系统级、子系统级、模块级。
2.2.1 模块级
模块的验证：在模块一级完全验证的功能，无法在模块一级验证的功能。
2.2.2 子系统级
合格交付的子系统包括：
设计包；验证包；回归测试包；覆盖率收集脚本和数据；完整的文档（设计、验证、集成、后端）。

2.2.3 芯片系统级
此级别验证平台的复用性较高，因为：外围验证组件侧重于验证芯片的输入输出，更新少。
芯片系统级的验证侧重于不同子系统之间的信号交互和贴近实际场景的用例。
2.2.4 硅后系统级
硅后的实际用例用在硅前测试，能够发现实际使用中的问题。将硅后的驱动、固件和系统软件尽早在硅前引入验证过程，可以与硅前的验证方法形成互补。

2.3 验证的透明度

按照激励的生成方式和检查的功能点分布将验证分为：黑盒、白盒、灰盒验证。

2.4 激励的原则

激励源的原则是如何保证激励源最大的自由度。

2.4.1 接口类型

常见的接口类型：系统控制接口、标准总线接口、非标总线接口、测试接口、其他控制接口

2.4.2 序列颗粒度

基本颗粒层；高级颗粒层；宏颗粒层；用户自定义颗粒层；

2.4.3 可控性controllability

可控性是从不同颗粒层的控制角度出发的。
功能验证初期，应从基本颗粒层中选择激励方法，这里的验证点侧重于协议功能和时序检查。
随着设计趋于稳定，我们逐渐选择高级颗粒层和宏颗粒层，将验证精力转移到数据量的一致性传输和性能评估上，它们会同验证重点保持一致，主要提供跟数据量有关的可约束参数。

2.4.4 组件独立性

将一个设计的边界信号划分为不同的接口类型，并创建出对应的接口验证组件之后，我们就应该考忠各个组件之间的独立性了。
组件的独立性(component independency）实际上也是协调性的基本保障，因为有了独立性，各个组件之间才会最大程度地不受其他组件的制约，同时又可以通过有效的通信机制实现组件之间的同步协调。
我们接下来看看实现组件独立性要考虑的因素：

必须按照接口类型来划分组件，
对于系统控制信号组件，尽可能将信号的关系按照实际集成关系做控制。
对于总线接口（标准或者非标准），实现一对一的控制关系。
对于其他控制接口，应从实际相邻设计那里准确了解各信号的使能极性、脉冲有效还是电平有效、是否存在握手关系，时序等真实的设计信息，来模拟高层集成环境中的控制场景。同时由于这部分信号偏于杂乱
验证环境中的系统控制信号组件会与其他接口组什发生连接，例如提供必要的时钟和复位信息，那么这些连接也应遵循实际集成的情况，确保组件驱动端的时钟输入与设计的时钟输入端同步。

2.4.5 组合自由度

组合自由度(combination space）是对上述因素的整体评估。只有通过底层的精细划分，建立抽象级更高的颗粒度，通过独立组件之间的协调来给出激励，才能提供较高的组合自由度。在这里，除了组件的独立性外，需要考虑组件之间的协调方式。
一般将协调方式分为两种：

中心统筹式（centrally organized）。通过中心化的调道，将不同的任务统一分派给各个接口组件，产生不同的激励组合场景。
分布事件驱动式 (distributed event driven)。将激励控制权交给各个接口组件，通过接口组件之问的通信来实现分布式的事件驱动模式，即组件之间的通信通过事(event)、信箱（mailbox）、接口信号 (interface signal）等方式实现同步通信。

通过上达因素，我们可以评定出一个验证环境中各个接口组件之问的组合，是否可以击供足够的自由度，最终有可能穷历出预定的激励序列。

2.5 检查的方法

检查就是查看设计是否按照能描述做出期望的行为，识别所有错误的输出，发现设计缺陷。
我们是按照接口类型来划分激励的；对于检查，类型的划分方式则基于被检查逻辑的层次，这些层次包括：

模块的肉部设计细节
模块的输入输出
模块与相邻模块的互动信号
模块在芯片系统级的应用角色。

不同的检查层次，可以考志采用不同的检查方法。
。。。

2.6 集成的环境

验证集成环境分为：
验证平台；待验设计；运行环境；验证管理。

2.6.1 验证平台

激励分为：定向激励，随机激励。
检查分为：

线上检查。仿真过程中动态对比数据，并给出比较结果。
线下检查。仿真结束后对比结果数据。
断言检查。通过仿真或形式验证的方式利用断言检查设计的功能点

2.6.2 待验设计

根据功能描述的建模方式，硬件设计可以分为：

HDL硬件模型。安装硬件层次分为RTL和网表
虚拟原型

2.6.3 运行环境

运行环境将验证平台和待验设计进行融合。需考虑的因素有：

验证平台
待验模型
仿真全流程建立。全流程的建立一般由环境构造者通过脚本语言来管理。

2.6.4 验证管理

验证管理工具需考虑的因素有：

验证计划和进度管理。
文件版本控制管理。
项目环境配置管理。
缺陷率跟踪管理。

3 验证的方法

动态仿真
静态检查
硬件加速
电源功耗
性能评估

3.1 动态仿真

动态仿真划分为：

定向测试
随机测试
参考模型check
断言check

3.1.1 定向测试

定向测试用来构成基本测试表，在验证前期完成设计的基本功能检查。一般应用在模块测试的早期或者在系统级芯片测试场景中。
定向测试的数据比较可以是以下两种情况：

通过内置的C代码进行数据正确性的检查（模块验证环境中有处理器）
通过外置的参考模型或者其他检测器进行信号的一致性检查

3.1.2 随机测试

随机序列（random sequence）通过预先定义的约束每次随机产生合理的数值，进而通过激励产生器给出测试序列。
在这里插入图片描述
产生随机数的方法有很多种，目前常用的语言有SystemVerilog和e语言。

随机约束生成器一般可以通过静态约束或者动态反馈约束来给出每一轮的激励。对随机约束起到控制和反馈的因素，它们分别是：

静态随机约束：即默认的约束，一般是同激励一起定义的，不会随着测试而变化。
反馈的动态随机约束：在测试的过程中通过上一轮的结果来对下一轮随机序列给予反馈，通过额外的定向约束（biasing constraint）给出更小的随机域（random region）。
待验设计的功能验证开关：待验设计的功能点有时候可以通过测试序列来关联，进而从该序列是否要验证某一项功能来决定某一组随机约束是否生效。
激励的结构成员：随机激励的成员构成，一般分为接口成员（跟设计交互），和成员间的逻辑变量（决定成员之间数值关系的变量）。
验证环境的配置参数：验证环境如果是可以配置的，那么这些配置参数也可能会影响序列的产生。
验证环境中不同激励组件之间的同步通信：如果验证环境中包含多个激励组件，那么如果要实现这些随机组件之间的协同，我们就需要考虑它们之间实现同步通信（synchronization communication）来实现激励组合之间的合理性。

3.1.3 基于覆盖率驱动的随机验证

目前常使用的一种随机验证方式是基于覆盖率驱动的，而这种方式也同我们上面提到的影响随机生成的因素“反馈的动态随机约束”一样。从下图可以看出，与常用的随机约束验证方式不同的一点是，覆盖率收集器在每次测试中都会通过监视器来收集覆盖率（主要指功能覆盖率），将其与已有的覆盖率数据库进行合并，同时根据现有的覆盖率数据库来为下一次随机约束给出反馈。这些正向的反馈就是用来进一步缩窄随机约束域，使其能够定向产生一些序列来覆盖那些未知的功能测试点。
在这里插入图片描述