芯片验证需要围绕DUT做什么？

TestBench即测试平台，是为了检验待测设计（design under test， DUT ）而搭建的验证环境。有了这个环境，我们就可以对DUT输入 定向或随机的激励 ，以保证DUT的正确性。故验证要做的事分为以下几步：

1、生成各种各样的输入激励

2、将输入激励传递到DUT上

3、DUT响应输入激励并输出

4、检查输出与预期结果差异

5、发现功能错误后修改DUT

6、重复上述步骤收集覆盖率

做个不太恰当的比喻，testbench就像一个书桌，你买来了一个键盘（DUT），你想要验证它是不是正常工作，你就开始敲键盘检查。你的十个手指就是 激励 ，数据线和屏幕相连，数据线为 接口 ，屏幕是 记分板 ，键盘使用说明书为 参考模型 。

首先你把26个字母都敲了一遍（ 定向测试 ），发现屏幕上也出现了26个字母，每个键都能没毛病，基本功能验证了；但是还不够，你又组合着敲了**“** guan zhu dian zan” （ 随机测试 ），屏幕上突然出现****“**** fen xiang zai kan ”**** ，这时你就发现bug了，赶紧找设计人员来修改代码。

细心的同学发现，随机测试岂不是边界很大，甚至”永无止境“？因此就有了 受约束的随机激励 。使用定向测试和受约束的随机测试，最终使得功能覆盖率趋于要求值。最终，键盘验证完没问题了，再教给后面的人做物理设计，比如键程长短、工艺面积、功耗分析等等，一套流程下来没问题就拿去厂子代工了。

说完了这个有点尬的比喻，我们理解了testbench就是模拟设计所在的环境，以检查RTL代码是否符合设计规范的玩意，其内部是分好几个组件的。那testbench具体有哪些组件呢？请看下图（PPT画的，不是很专业）：

generator ：产生不同的输入激励来驱动DUT

产生有效的数据，并发送给driver。

interface ：用于连接testbench和DUT

如果一个设计包含成百上千个端口信号，那么连接、维护和重复利用这些信号就会很麻烦。如果将这些输入输出端口放到一块组成一个接口，那么连接变得更加简洁而不易出错，后续添加新的信号更简便，接口也便于重用。

driver ：将激励驱动到DUT

monitor ：检测DUT的输出

scoreboard ：用于比较输出与预期值

scoreboard上有与DUT相应的参考模型，反映了DUT的预期行为。如果DUT的输出和参考模型的输出不匹配，则设计中存在功能缺陷。

environment ：包含以上所有的组件，便于复用

test ：可以包含不同配置的环境

因此，为了验证DUT这份RTL代码，验证要做的事是：

1）了解 spec ，即代码的规格说明书，有结构模型、功能描述、信号端口、寄存器定义等，它是设计和验证对接工作的桥梁。

2）制定 testplan ，一个完整的验证计划需要考虑的东西有很多，它为后续工作的进行提供了方向。

3）构建 testbench ，根据具体验证需求选择相应的组件，搭建出尽量可重用的验证环境。

4）编写 testcase ，根据之前定制的验证计划，coding相应的测试用例， debug fail case ，把全部case调试至 pass 。

5）收集 coverage ，跑regression回归，根据覆盖率来决定是否加case，直到满足RTL freeze要求。