下面这些问题和回答是基于我个人对验证（主要是动态仿真验证）的理解，可能有理解的不到位、理解有偏差的地方，欢迎大家指正。
Q：验证的目的？
A：发现Bug，发现所有的Bug，或者证明没有Bug。
Q：对验证工程师的要求？
A：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介绍， ，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可以自己开发，从而控制配置的流程和数值
2）随机激励数据（很重要）
3）随机时序（通常容易被忘记）
但是有一点要明确：随机不是全随机，是约束随机，是在合理的范围内尽量充分的随机。
Q：写约束随机哪些地方要注意？
A：推荐看snug paper。(over-constraint导致测试不完全，欠约束导致不必要的debug和资源的浪费)约束的效率：写的不好会导致随机失败
Q：Coverage如何做？
A：code-coverage和function-coverage（covergroup, assertion coverage）。对于constraint-random的地方用covergroup做，对于一些时序的coverage可以用assertion-coverage。
Q：核心脚本？
A：单个仿真的脚本 ---- 建立所使用的不同的目录、不同的seed（目录可以叫case_$seed这样的格式；当然对于直接的testcase，可以是case_$casename）；环境变量和license的管理；如果需要做离线比对也可以让脚本来自动调用比对脚本或命令（也可以在tb的代码里使用$system或者$systemf）。
批量仿真的脚本----自动批量提交到lsf上。自动收集log信息以判断哪些case失败，对于失败的case能自动重新提交，并且自动dump波形。以及产生批量仿真结束以后的汇总信息。
Q：SV中重要的点？
A：特殊的数据类型，比如新增的三种array（动态、associate、queue）、string（match函数、backref函数，参考vcs的）；面向对象编程思想（handle）；coverage；constraint-random。
熟练掌握这些语言点的用法很有必要。
Q：VMM 1.0够不够？
A：刚开始用1.0来建立起vmm的概念，然后转到1.1或者1.2上。个人觉得不是必须一下子就转到1.1或1.2上（当然，1.1的一些扩展宏的确很好用）。个人建议vmm1.0+1.1的扩展宏+subenv
Q：是否要使用VIP？
A：VIP的使用 --- 复杂仿真模型推荐用VIP，简单的建议自己做。如果自己开发仿真模型的话，也推荐看看VIP的文档，经常可以看到一些有价值的error-injection和random-test-points来完善你自己的testplan。
Q：要不要做门级仿真？
A：如果是走design-service，不知道最终带sdf的netlist仿真是否需要做，如果做的话，最好在release 综合后netlist的时候也做一下（插完scan-chain和做完CTS以后有条件也做一下），如果需要VCD文件做power分析和指导PR工具的话，那么门仿是必须做的。如果design-service公司不负责调量产pattern的话，那么ATPG等的门仿是需要自己做的。
门仿并不是sign-off标准，但是推荐还是做一下，经常还是能跑出问题来的。如果做sdf反标的门仿的话，对于async的多级dff要剔除掉（VCS和NC都有option，vcs可以查手册里“+optconfigfile”,NC查”+nctfile”）。反标Sdf仿真的时候推荐notimingcheck -> no_notify -> checking_timing with optconfigfile的三步走。
前期在评估IP的时候，有可能个别模块可能需要单独搭门级环境，比如CPU-IP有RTL，要自己做flow，那么通常是需要做门仿的（有可能主要是为了跑vcd或saif做power分析）。
