入行数字IC验证后会做些什么?

半年前,公众号写了第一篇推文入行数字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了。


以上就是芯片验证工程师一年内可能接触的内容。

如果觉得有用,期待您的转发分享和在看!也可以加个关注,第一时间看见公众号的推送!

  • 3
    点赞
  • 15
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值