行业工程师对IC验证的理解

行业工程师对IC验证

的理解

行业工程师对IC验证的理解-下面这些问题

和回答是基于我个人对验证（主要是动态仿真验证）的理解，可能有理解的不到位、理解有偏差的地方，欢迎大家指正。

Q：验证的目的？

A：发现Bug，发现所有的Bug，或者证明没有Bug（转自夏晶的帖子）

Q：对验证工程师的要求？

Hacker mentality ，Organized testing ，Tool automation。

如何做更多的testcase、如何覆盖更多的测试点、如何充分的利用服务器、如何尽可能最大化的自动比对

强调一下：“注重细节”是验证工程师一个非常非常好的工作习惯。

Q：语言、方法学有多重要？

A：我的观点是：这两个都不重要。做事情的是验证工程师，来源是Spec，所以Testplan （全覆盖testplan）最重要。重要的是验证的意识，愿不愿意去实现H-O-T，即使一开始做的“土”一些也没关系。比如tb里经常要做的“自动比对功能”：1）维护queue，然后foreach的比较2）利用file-operation （fopen fread fwrite fscanf）来做文件比对3）

直接$system(diff a b > c)以后看c文件大小。上述三种方法都可以（虽然2）会导致比较多的文件IO，硬盘读写会影响仿真速度，3）不能做实时的比对。不必拘泥于方法，关键是有这个意识。

Q：EDA行业对验证的支持？

A：个人感觉虽然(动态)验证这些年在理论方面的突破不大（静态验证一直是热点），

但是EDA行业一直都很重视，实现类的工具主要是在做算法优化，这些年突破不大。但是验证方向上的点工具一直在不停的出（虽然最终可能也没有几个好使的工具），但是说明EDA行业一直在致力于寻求在验证上的突破。而且由于现在做SoC的太多，IP又太多，大家都是越来越重视验证，很多上规模的公司里验证人员较设计人员多不少。个人觉得这可能也是EDA重视验证的

一个原因（用牛工具替代掉一些人LL）。Q：如何跟踪缺陷？

A：可以考虑bug-zillar这类的工具---- 自动跟踪问题。

Q：作业提交系统（lsf或grid-engine）A：充分和合理的利用计算资源。

Q：环境变量的管理？

A：个人推荐使用Module 工具。很多公司都是用这个免费的工具

Q：Testbench用到的编程语言？

A：我觉得tb里systemverilog和verilog是可以互相替换（当然了，systemverilog特有的内容用verilog来实现会很复杂），所以推荐tb基于systemverilog来搭建，一些仿真

模型可以用verilog。C除了Cmodel以外，firmware也会用C和汇编写。

基本上我做过的项目里用到的语言：

脚本：perl、makefile、shell（perl用的很多，其他用的很少）

Tb（包括vmm的组件）：基本是systemverilog

仿真模型：systemverilog和verilog混着用

Cmodel ：C或C++

Firmware ：汇编和C

Q：验证工程师需要掌握的基本技术？A：分享一份我做的基本培训内容安排，供参考

Perl，Makefile，AMBA介绍，SVTB.pdf ，sva,

几种用到的编程语言的File operation ，Low-power，C-pointer，Cshell-AWK+SED，体系结构相关的一些内容，SV-1Day training ，VMM_source_code ,Arm的嵌入式编程的基本概念

Q：自动化必须吗？

A：不是必须的，但是应该尽量去实现自动化。总之是多让机器跑。如果人均License

太少的话，要尽量做到白天debug、晚上让机器跑。“比对”这种事情太机械了，所以尽量让机器做，做这种事情机器的效率比人高太多。把精力放在构造testcase、testbench、coverage以及debug和分析上。

Q：Testplan如何做？

A：形式不重要，xls可以、word也可以、txt 的也可以。但是来源于Spec！testplan里除

了要罗列function-test-piont，还应该有error-injection 和random-test-point以及cover-point和assertion。

需要和各个team仔细逐条review testplan，有些针对具体实现的coverpoint可能只有designer能提出来，需要尽早提出。Tb搭建之前，要充分的review testplan，因为Testplan的较大修改有可能会导致整个

testbench的架构调整，effort较大。Testplan 是一个需要不停增加，不停迭代、不停review的东西。

Error injection要和RTL-designer逐条review，一个是看看RTL-designer是不是没有想到，一个是设计是不是本身就不允许、或者架构上本身不可能出现。Error-injection 应该往深里去好好挖掘。例如：内存控制器长时间不回数据（这里本身是一个随机点）

à由于长时间不回数据是否产生错误中断à产生错误中断以后如何响应à响应不过来如何恢复à必须用software reset做恢复的话，对software的时机是否有要求àsoftware前需要遵守什么要求和步骤

虽然现在有一些工具可以根据规范化描述的testplan自动生成cover-point和assertion，不过我觉得自然语言描述的

testplan应该是最“自然”的。

Q：哪些地方做随机？

A：1）随机配置（一般都想得到的），但是对于一个封闭的系统常常是最不重要的，因为firmware可以自己开发，从而控制配置的流程和数值