芯片验证的相关概念（转载）

作为一名linux驱动工程师，与验证同事打交道的很多，这里记录一下芯片验证方面的一些概念，方便后续查找

原文链接：芯片验证需要围绕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要求。