文章目录
- 前言
- 一、覆盖率
- 二、验证计划
- 1、验证计划模板
- 2、验证计划评估
- 三、验证方法
- 1、动态仿真/dynamic simulation
- 2、静态检查/formal check
- 3、虚拟模型
- 4、硬件加速/hardware acceleration
- 5、效能验证
- 6、性能验证
- 四、验证分类
- 1、验证工具
- 2、验证复杂度/可见度/透明度
- 3、验证的芯片种类
- 4、验证工具
- 5、验证层次
- 五、芯片验证的流程
- 1、芯片规格
- 2、测试点分解
- 3、验证方案
- 4、验证计划
- 5、搭建验证平台
- 6、测试用例开发
- 7、回归测试
- 8、覆盖率分析
- 9、验证报告
- 10、后仿
- 自测题
前言
2023.3.11 学习打卡 小雨
2023.4.4
一、覆盖率
初期:发送测试的基本数据,限定范围要窄;
中期:性能稳定,扩大测试范围;
后期:边界情况测试
二、验证计划
1、验证计划模板
- 设计功能简要描述
- 硬件实现框图
- 待验证的功能点
- 验证环境搭建
- 测试用例构成
- 编译脚本和回归测试
- 覆盖率分析
2、验证计划评估
- 回归测试通过率(regressioin pass rate):缺陷修复或者新增性能,要使得原来的功能还能够正常使用
- 代码覆盖率(code coverage)
- 断言覆盖率(assertion coverage)
- 功能覆盖率(function coverage)
- 缺陷曲线(bug curve):越早发现问题越好
三、验证方法
1、动态仿真/dynamic simulation
- 该方式是通过测试序列和激励生成器给入待验设计适当的激励,伴随着仿真时间,进而判断输出是否符合预期。
- 我们需要
仿真器
来配合这一项工作,验证人员也需要查看比较结果和仿真波形,最终来判定测试用例是否通过。 - 如果按照激励生成方式和检查方式,我们可以将动态仿真进一步划分为:
定向测试(directed test):适合于子系统级和芯片系统级的验证
随机测试(random test):适合于模块级和子系统级的验证
参考模型检查(reference model check)
断言检查(assertion check)
2、静态检查/formal check
与动态仿真相对的是静态检查,它本身不需要仿真、波形激励,通过工具的辅助,验证人员即可以发现设计中存在的问题。
语法检查
:编译器compiler语法检查语义检查
:linting check,在设计可行性上进行深入检查(可能产生X值,覆盖率收敛问题,常见设计错误)。在早期可以发现功能实现以外的设计问题。跨时钟域检查
:cross-clock domain check/CDC,信号采样问题,同步处理,门级阶段可能才会暴露出来,但是要在RTL级利用工具来检查,越往后修复成本更高。检查工具0-In、spyglass
形式验证
:综合的网表与RTL对比做形式验证。保证综合过程没有逻辑错误。保证综合后的网表是想要的。包含以下两种:
等价检查
(EC,Equivalence Check) :用来保证两个电路的行为是等价的,可以用来检查不同抽象级的电路是否一致,例如RTL级和网表。
属性检查
(PC,Property Check):又称为模型检查(MC,Model
Check)。电路的行为通过验证语言来描述其属性(property),随后通过静态方式来证明在所有状态空间下都满足该条件,否则举出反例(counterexample)来证明设计行为不符合属性描述(property description) 。
3、虚拟模型
高抽象级的硬件模型system C(可以综合)
软件模型可依赖虚拟模型在早期开发,硬件可以更早获得软件反馈而对设计进行修改,判断硬件和软件的协同任务是否可以满足功耗要求。协同设计、仿真、验证。可以集成到UVM里面,做reference model。也可以放在设计里面做替代。
和RTL还是有区别的。
4、硬件加速/hardware acceleration
动态仿真和静态检查的缺陷就是速度
,仿真速度限制
FPGA
:主要针对小型设计或单独的IP,为软件开发提高平台,不可以设置断点调试,看不到内部信号专用模拟器emulator
:面向更大、更复杂的SoC设计,为了硬件和软件协同验证和整个系统的测试,方便调试,速度快速度
:FPGA>emulator>仿真器
5、效能验证
(1)性能提升,功耗逐渐提高。在移动时代,硬件提升性能
的方式主要表现为以下几种:
- 提升原有处理器性能、存储器空间、数据总线带宽或者采取多核处理方式。
- 增加额外的协处理单元,或者新的功能模块(例如Video/GPU单元)。
- 在后端允许的情况下提高工作时钟频率。
- 提升工艺制程。
(2)我们这里主要针对硅前设计阶段进行效能验证,涉及的流程可分为两个部分:
功能验证
:主要采用PA
(Power Aware)(主要包括有UPF (UnifiedPower Format)或者CPF (Comment Power Format) )方式,通过与仿真器结合,模拟电源域的开关进行设计检查。功耗预测与优化
:通过第三方功耗分析工具,结合仿真数据(FSDB/VCD/SAIF),进行功耗预测,并且给出分析结果。
(3)在门级预测功耗更准确,更接近流片结果。RTL级也可以仿真。
(4)总功耗
总功耗 = 静态功耗 + 动态功耗 = 静态功耗 + 开关功耗 + 短路功耗
P=VI(漏电)+CV2F(频率,负载电容)+VI(短路)
静态功耗
:主要是漏电流所引起的功耗。漏电流与工艺相关,温度越高,漏电流越大。为了满足工作频率高的要求,通常会降低晶体管的阈值电压,使得晶体管能够高速翻转,但阈值电压太低,晶体管不能完全关断,将会产生很大的静态功耗
动态功耗
:指负载电容充放电引起的功耗。动态功耗占总功耗的80%,降低动态功耗是降低整个系统功耗的关键因素。包括翻转/开关功耗和短路功耗。
翻转功耗是数字电路要完成功能计算所必须消耗的功耗,称为有效功耗
。占比大。
短路功耗是CMOS在翻转过程中PMOS管和NMOS管同时导通时消耗的功耗,成为无效功耗
。占比小动态功耗与节点电容、工作频率、工作电压的平方成正比,三者越大,功耗越大。
(5)低功耗的方法
6、性能验证
动态仿真伴随着性能和效能验证。
衡量一个系统在特定工作负载下的响应能力和稳定性,离不开大量的运算和数据传输。将性能测试提前可以使得硅前验证和硅后测试采用相同的测试用例。
四、验证分类
1、验证工具
仿真验证和形式验证
2、验证复杂度/可见度/透明度
白盒、灰盒、黑盒验证
黑盒验证
:验证的输入只有输入信号,输出信号和相应的功能。不需要关心内部信号和架构,验证代码对DUT内部的更改不太敏感。常用于大规模的系统级验证。白盒验证
:验证的输入有输入信号,输出信号,内部信号,所有的信号时序和相应的功能。需要了解实际的实现方式,能够阅读RTL设计代码。常用于模块级别验证。灰盒验证
:黑盒验证和白盒验证的结合体,这使得验证环境的开发更加灵活。常用于子系统级别验证。- 最好采用黑盒或者灰盒,黑盒更加通用,复用性好,
黑盒需要参考模型,白盒可以不需要参考模型
3、验证的芯片种类
CPU验证、GPU验证、TPU验证、NPU验证、SoC验证
4、验证工具
EDA验证、FPGA原型验证、Emulator验证
EDA验证
:即功能验证,根据开发的不同阶段分为前仿验证
和后仿验证
。主要工具有VCS、Verdi、NC-Verilog、ModelSim等等。EDA验证是通过软件仿真来验证电路设计的功能行为
,是比较理想情况下的,没有考虑电路内部逻辑与互连的延时。优点是波形直观,能够快速找出功能bug,性价比高,缺点是仿真速度慢,难以对整个芯片系统进行验证。FPGA原型验证
:即编译设计代码,并且综合为真实的硬件电路对应FPGA板子上去,通过真实的硬件电路进行仿真(FPGA原型)。FPGA原型验证,将RTL代码移植到FPGA来验证IC系统的功能和性能
。基本流程:将ASIC代码转换成FPGA代码,编译与对设计拆分,综合,布局布线,生成比特流文件bitfile。优点是降低了软硬件协同验证的成本,加速了硬件验证和软件开发;缺点是编译较慢,设计拆分时易出错,比较难定位bug。Emulator验证
:为介于simulator和FPGA prototyping间的产物,同时拥有二者的优点,如方便debug波形、可使用force/release命令、检查覆盖率、打印display信息、同时运行速度快很多,最大的缺点就是太贵了,需要时间和人力去搭建环境和维护。Cadence的Palladium、Mentor Graphics的Veloce,以及Synopsys的ZeBu等平台。
5、验证层次
模块验证、子系统验证、系统验证
模块验证
:侧重点在模块本身功能的验证
,验证计划的重点是feature和验证架构,然后列出testcase,模块能够覆盖的绝不到下一级验证去覆盖。主要内容有:检查参数设置、寄存器读写、协议检查、中断和复位、状态机跳转、工作模式覆盖、RAM的读写功能边界等等。子系统验证
:侧重点在系统的互联性,更加关注系统的工作模式和复杂场景应用。主要内容有:中断的产生、DMA功能、IP的模式功能、Memory读写等等。系统验证
:侧重点在软硬件协同仿真
,关键系统路径的覆盖,芯片工作模式和测试模式以及数据通路和性能等。主要内容有:基本IP功能、CLK/RESET、IO MUX 、多个IP同时工作、程序的启动、工作模式和应用场景测试。
五、芯片验证的流程
1、芯片规格
根据市场产品需求,规定芯片需要达到的功能和性能,产品和架构师根据客户提出的规格spec,商定出具体设计解决方案和实现的架构,划分出各个模块的文档。
2、测试点分解
根据spec文档,分解出具体的测试点。可以分为场景类、功能类、性能类等等,分解的颗粒度尽量细致,直到完备无漏,一个测试点被一个case覆盖的原则分解
3、验证方案
整个芯片的验证方案一般由验证负责人规划,将设计分成多个子系统,再将子系统分成多个模块:具体验证策略、EDA工具和IT资源、项目进度安排、未覆盖的功能,风险评估
4、验证计划
定制验证策略,评估验证计划,细化testbench搭建、debug、case开发等时间,大概分为:
spec阅读和测试点分解时间
开发环境和调试冒烟测试时间
开发case,完成全部case时间
回归测试和验证报告的时间
5、搭建验证平台
一般由激励生成器、驱动器、采样器、参考模型和计分板组成
从简单的功能开始,测试可以通过验证环境之后,再扩展其他功能
经常遇到编译报错、语法错误、预期错误,需要逐一解决
分析报错是由验证环境引起的,还是设计代码错误造成的
6、测试用例开发
冒烟测试:基本的寄存器读写测试,确保数据流已通
直接用例:根据spec中program流程配置的典型测试
随机用例:用于变量随机,覆盖更多边界,注重约束条件的配置
增补用例:以提高覆盖测试点为目标,增补相应的测试用例
7、回归测试
基本功能回归:基本功能与基本场景覆盖
高级功能回归:高级功能和边界测试覆盖
覆盖率收集回归:高级功能测试完成之后,开始收集覆盖率
8、覆盖率分析
行覆盖率
条件覆盖率
跳转覆盖率
分支覆盖率
断言覆盖率
状态机覆盖率
功能覆盖率
9、验证报告
应用场景验证
模块复用说明
覆盖率分析
风险评估
待改进方案
10、后仿
慢慢跑着就行了,基本signoff了。
自测题
【注意】如果cross a和b,假定a中有4个bin,b中有5个bin,cross之后一定有20个bin吗?
不一定。如果a中的bin没有将所有可能的值涵盖完,那么cross时,会自动添加这些值的bin