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的svtb.pdf）；面向对象编程思想（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分析）。

Tb的修改：由于CTS和综合的原因，导致时钟名字和信号名字有变化，所以tb有可能要修改。另外，tb里的probe文件建议使用反沿采样，也是为了避免带sdf反标以后clk踩不到整个data-vector。除此之外，个人不太建议在门仿的时候依然使用自动化的tb。因为你的tb里抓的很多内部信号可能名字变了（或者被优化掉了），这样导致tb在门级跑的时候维护起来有些麻烦。有些信号即便名字不变，可能会反向，这样会导致你的checker误报错。毕竟在门仿的时候不用跑太多的testcase，可以靠几条和rtl仿真一一对应的仿真来覆盖。门仿毕竟不是为了function，而是为了检查timing。

       如果你的设计里用了不带reset的dff的描述，由于开始不定态的传播，可能导致你门仿失败。个人推荐的方法是：如果特别多的话，用脚本找到对应模块里所有dff，产生一个force-release文件（注意：很影响编译时间，所以能不用就不用）

Q：FPGA和仿真如何安排顺序？

A：首先是schedule优先，其次是力所能及。但是原则上是先仿真然后再上FPGA，仿真可以很快的扫清一些基本的bug。给仿真的时间充裕的话，那就仿真尽量往前赶，尽量在上FPGA之前多测一些（不是太多case的情况下，FPGA的测试速度毕竟要快一些）。即便FPGA很着急上，起码也让仿真先用几条直接testcase调试通过最基本的功能。第一版FPGA可能因为接死、悬空和信号反向导致逻辑被优化掉，这些问题有时候用仿真也不能全发现，就要结合leda等lint工具。

Q：仿真如何复现FPGA发现的bug？

A：首先保证配置的一致性，可以考虑做一些内部的工具。仿真上要probe寄存器操作端口，FPGA上要能把firmware里的配置流程转成文本。

       如果配置一样还是不能发现的话，再去逻辑分析仪上debug时序。当然，CDC的问题在仿真上是看不到的。

       个人不建议做FPGA网表的门仿，有点得不偿失。

Q：FPGA不能cover的部分的验证？

A：PAD_Mux（Test_mux）、Clkrst、Power-management-unit 以及FPGA跑不到的高频所对应的功能。Clkrst这部分主要就是pll config、clock-gate、divider、soft-and-hard reset，从测试点的角度还是很明确的，RTL代码修改的少的话，可以考虑不用做太复杂的验证（但是clkrst模块里可能会有一些控制逻辑或者状态机，比如：sdram的切频，这里一般是需要一个状态机控制的，这个需要仔细和小心的验证。）

PAD_mux个人比较推荐使用自动化的流程，因为代码风格非常固定，所以可以用脚本生成RTL和用脚本生成testcase（一般这样的testcase是一堆的force）

PMU建议看看VCS的MVsim的文档，里面介绍的很清晰了。（还是要配合静态验证工具MVRC一起来做）没有MVSim的话，可以考虑用VCS的$power $isolate。

Q：固化的firmware如何验证？

A：个人不建议让仿真去覆盖firmware，但是对于FPGA和ASIC不一样的地方要重点覆盖到。大的流程要覆盖到，其他细节由FPGA保证。

Q：架构评估？

A：我经验也不多，举几个例子。比如你的总线拓扑合理不合理？内存控制器的效率（机制）是否满足你的应用？使用哪类Cache？Cache的大小？模块的FIFO深度够不够（error-injection可以测到）？算法需要多少mips（rvds等工具带的模拟器可以给出结论，但是要让模拟器能考虑到内存access的latency）？软件里如果有不少memcpy的话，要模拟系统运行起来以后memcpy的效率。

       如果没有人手专门用ESL（如Carbon的CMS）工具的话，建议在验证平台上做（当然一旦有大问题，要推翻架构会很麻烦）。