SOC验证自动化[摘选]

当各个IP都是OK，将它们整合成一个SOC时，剩下的任务就是验证了。我们在这里重点谈SOC的验证。
一个模块单独看是好的，当然集成要一个系统中时，那么它的功能是否一定OK呢？不一定。因为其他模块不一定OK，或者说其他模块不一定能和它很好工作。
比如一个DMAC一个Memory Controller，DMAC每次发送为burst16 size：word，而memory ctrl只支持burst4，这样就会出问题。
再比如有的设备不支持busy，有的设备ack时间不定等待。也就是说这些IP组合在一起时功能不一定能发挥出来。而且SOC设计很多情况是有些IP是临时做的或者未经充分验证的，这种情况，SOC验证会花费更多的精力。
所以SOC的验证会根据SOC设计不同的情况来调整验证策略。
1，所有IP正确，互联完成，全部bfm OK，monitor OK，checker OK，
这是最理想的情况，这时的SOC验证，测试平台的搭建是非常的容易的，
验证重点会放在，test case和function coverage上。test case应该
也可以重用。如何来保证function coverage上呢，derected + rand。

2.部分IP未经充分验证，bfm 不完全，monitor 不完全，checker  没有。
这是比较差的情况，这是的验证，首先将重点放在那些未经验证的IP上，及时发现
bug让designer修正。其它验证所需的bfm，monitor，checker可以提前编写。
对于interface一定要和desinger确定清除，bfm最好由designer给出。

3.IPbug极多，验证环境没有
这是最恶劣的情况，一定要保证时间和人力的充裕，否则很难保证验证质量。

 

SOC的SPEC或者feature list多如牛毛时如何在短时间内充分的验证它们呢？
唯一的出路在于验证自动化。
SOC验证自动将达到这样一个效果：
一个SOC设计--> SOC Spec--> SOC verfication config --> SOC testbench + SOC testcase
--> SOC verfication --> Analysis and report
举个例子，基本的比如register的验证，
根据每个IP的register 的属性产生一个文件：包含register的base address， offset，有效位数，
读写属性，reset value等，
根据这样一个文件，验证自动化工具会产生相应的测试语句，可以是bfm ，也可以是程序代码，然后
testbench会加载运行这些测试语句，最后统计结果。
再比如对于中断的验证，
将所有的中断源，一级的，二级的，信号路径，产生方式，边沿触发还是电平触发，他们的时能寄存器地址，mask 地址，status地址，中断向量，clear 方式，用一个文件表或者类来描述，验证自动化工具会根据这些属性自动完成test case，它可以实现中断的自动产生，自动检测，自动生成中断程序，来验证中断的产生到响应这个过程是否正确，更高级的功能可以实现中断嵌套的随机验证。
同样，我们可以归纳出DMAC的特性，memory controller的特性，各种IO的特性，然后自动产生testbench和testcase，完成我们的验证。
这样任何一个SOC设计，只要我们将它们的特性描述成验证自动化工具所需的输入条件，验证自动化工具就能自动完成SOC的验证工作，从direct test到rand test，从assert 到 coverage都可以覆盖到。
所以验证的自动化将是解放验证工作的一条光辉大道。
这一篇我谈了一下我的思路，下一篇我将谈谈我是如何具体来实现SOC的验证自动化。也希望感兴趣或者有共同爱好的同仁能够切磋交流。