半年前，公众号写了第一篇推文《入行数字IC验证的一些建议》，介绍了IC小白可以如何一步一步地摸索入门数字IC验证，同时也在知乎发了这篇入门贴，并且衍生出很多额外基础的内容，收获了不少的浏览量以及肯定。点击合集（数字IC合集(超级全面，持续更新)）
在真实地工作一年后，对芯片验证的理解也有了更深的认识，故在此回忆总结这一年所看到的数字IC验证世界。
--------------------------------
我们知道芯片制造出来到用户手中之后是没办法再次更改的，流片失败的代价非常的昂贵，大公司还好有试错成本，小公司可能直接拜拜了。因此需要确保芯片在流片前，把设计所定义的功能都检验正确无误。
所以芯片验证的开始是从spec的定义开始的，有了它之后就可以定制相应的验证计划，随后才是根据DUT搭建testbench，编写定向和随机的测试用例进行仿真，跑regression后收集覆盖率，根据覆盖率的情况再决定是否增补testcase。直到coverage达到验收标准，功能验证才算结束了。
--------------------------------
芯片验证也会有很多分类，根据芯片类型的不同可以分为：CPU验证、GPU验证、TPU验证、NPU验证、SoC验证等等；
据工具的不同可以分为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等平台。
根据层次不同可以分为模块验证、子系统验证、系统验证：
模块验证：侧重点在模块本身功能的验证，验证计划的重点是feature和验证架构，然后列出testcase，模块能够覆盖的绝不到下一级验证去覆盖。主要内容有：检查参数设置、寄存器读写、协议检查、中断和复位、状态机跳转、工作模式覆盖、RAM的读写功能边界等等。
子系统验证：侧重点在系统的互联性，更加关注系统的工作模式和复杂场景应用。主要内容有：中断的产生、DMA功能、IP的模式功能、Memory读写等等。
系统验证：侧重点在软硬件协同仿真，关键系统路径的覆盖，芯片工作模式和测试模式以及数据通路和性能等。主要内容有：基本IP功能、CLK/RESET、IO MUX 、多个IP同时工作、程序的启动、工作模式和应用场景测试。
根据可见度可分为黑盒验证、灰盒验证和白盒验证等等。
黑盒验证：验证的输入只有输入信号，输出信号和相应的功能。不需要关心内部信号和架构，验证代码对DUT内部的更改不太敏感。常用于大规模的系统级验证。
白盒验证：验证的输入有输入信号，输出信号，内部信号，所有的信号时序和相应的功能。需要了解实际的实现方式，能够阅读RTL设计代码。常用于模块级别验证。
灰盒验证：黑盒验证和白盒验证的结合体，这使得验证环境的开发更加灵活。常用于子系统级别验证。
--------------------------------
芯片验证流程
1.芯片规格
-
根据市场产品需求，规定芯片需要达到的功能和性能
-
产品和架构师根据客户提出的规格spec，商定出具体设计解决方案和实现的架构，
-
划分出各个模块的文档。
2.测试点分解
-
根据spec文档，分解出具体的测试点
-
可以分为场景类、功能类、性能类等等
-
分解的颗粒度尽量细致，直到完备无漏
-
一个测试点被一个case覆盖的原则分解
3.验证方案
整个芯片的验证方案一般由验证负责人规划，将设计分成多个子系统，再将子系统分成多个模块：
-
具体验证策略
-
EDA工具和IT资源
-
项目进度安排
-
未覆盖的功能，风险评估
4.验证计划
定制验证策略，评估验证计划，细化testbench搭建、debug、case开发等时间，大概分为：
-
spec阅读和测试点分解时间
-
开发环境和调试冒烟测试时间
-
开发case，完成全部case时间
-
回归测试和验证报告的时间
5.搭建验证平台
-
一般由激励生成器、驱动器、采样器、参考模型和计分板组成
-
从简单的功能开始，测试可以通过验证环境之后，再扩展其他功能
-
经常遇到编译报错、语法错误、预期错误，需要逐一解决
-
分析报错是由验证环境引起的，还是设计代码错误造成的
6.测试用例开发
-
冒烟测试：基本的寄存器读写测试，确保数据流已通
-
直接用例：根据spec中program流程配置的典型测试
-
随机用例：用于变量随机，覆盖更多边界，注重约束条件的配置
-
增补用例：以提高覆盖测试点为目标，增补相应的测试用例
7.回归测试
-
基本功能回归：基本功能与基本场景覆盖
-
高级功能回归：高级功能和边界测试覆盖
-
覆盖率收集回归：高级功能测试完成之后，开始收集覆盖率
8.覆盖率分析
-
行覆盖率
-
条件覆盖率
-
跳转覆盖率
-
分支覆盖率
-
断言覆盖率
-
状态机覆盖率
-
功能覆盖率
9.验证报告
-
应用场景验证
-
模块复用说明
-
覆盖率分析
-
风险评估
-
待改进方案
10.后仿
慢慢跑着就行了，基本signoff了。
以上就是芯片验证工程师一年内可能接触的内容。
如果觉得有用，期待您的转发分享和在看！也可以加个关注，第一时间看见我的推送！