 行业工程师对 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，硬盘读写bswk SMT 加工 www.smtsmt.com.cn 会影响仿真速度，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 来搭建，一些仿真模型可bswk SMT 加工 www.smtsmt.com.cn 以用 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 以及bswk SMT 加工 www.smtsmt.com.cn 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 的东西。 |
