前言

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