ASIC验证概述

0.前言
1.验证流程（flow）
2.验证平台的组成
3.验证方法之黑白灰盒
4.通用型目录结构

0.前言

一个ASIC完整的设计流程如下图，包括需求-架构-RTL 设计-验证-综合-STA-DFT-物理验证。其中，验证处于IC设计前端，主要用于验证RTL代码的功能是否正确完备。

1.验证流程（flow）

（1）制定验证策略和计划

（2）确定验证平台
确定验证语言：基于Verilog/systemVerilog
确定验证层次：高级语言C/C++/Matlab等
确认验证方法学：ERM/OVM/VMM/UVM
确认验证方法：基于ABV/CDV/MDV的测试
（3）提取testcase
每个需求对应一到多个testcase，反映为验证的颗粒度；
有些需求，如复位、使能在其他用例也能测试到，可以不用单独测试；
验证方法学本质就是个组合问题：面对输入数据，还是面对内部功能；
验证原则：从简单到复杂，从定向到随机。
（4）覆盖率分析和回归测试
查看覆盖率报告：功能覆盖率/代码覆盖率等
回归测试：testcase是否完备

2.验证平台的组成

（1）driver：产生测试的输入信号，由不同的testcase决定；
（2）DUT：design under test。即例化的ASIC功能模块；
（3）monitor：采样DUT的输出
（4）refm：作为参考模型。先采样激励信号，用C等高层次工具模拟功能结果，与monitor采样得到的结果做对比；
（5）scb：即scoreboard，比分扳。记录monitor与refm比对结果的正误的个数。
在testbench中以task的形式定义各个模块。搭建好验证环境后，以上模块不需要改变，只需读入不同的testcase，产生不同的激励。
为了测试用例的可复用性，一般会用makefile、perl、python等脚本语言集成好，供用户直接调用。

3.验证方法之黑白灰盒

（1）黑盒验证：内部不可见，只看输入到输出，适用于算法/IP/简单模块；
（2）白盒验证：内部可见，不需要参考模型，可以添加断言assertion、监控器来保证操作正确性；
（3）灰盒验证：模块间信号线可见，在模块间加测试点，需要参考模型；验证工作量比较适中。

4.通用型目录结构

（1）rtl：放置RTL代码
（2）sim：仿真脚本与结果文件
（3）tb：testbench顶层与各个testcase