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）工具的话，建议在验证平台上做（当然 一旦有大问题，要推翻架构会很麻烦）。
Q：哪些资源要节省？
A：当然首先是人（数）要节省，人的成本比起计算资源成本和存储资源成本要大多了。提 高技术、提高自动化程度才能节省人的成本。（低 Package 这种方法属于伤天害理的手段，不是 正当途径） 减少硬盘需求（如果有必要） 共享 simv/simv.daidir csrc(包括 regression 过程中自动清 理磁盘空间)；激励数据是否可以不一下子全产生出来（对于通讯类的比较有意义，由于是 floating 的激励数据，所以经常很短时间就需要 GB 的空间）。注意对每个人每个项目设置硬盘 quota，避免被个别人撑爆存储。 减少编译次数（soc 项目里比较有必要，testcase 基于 firmware），parallel-compile or separate-compile ，vmm-test，在一个 testcase 里做多个功能点的覆盖，fsdb/vpd 的 dump 层次的改变不要重新编译(fsdb 有 command，vpd 可能得用 ucli)。
Q：设计规模大了编译很慢怎么办？
A：有时候设计规模太大导致编译很慢，但是 SoC 项目很多情况下，功能模块彼此之间是 用总线隔开的（即便在功能模块之间有硬件连线也可以考虑用仿真模型来做替代）。在仿真某一 个功能模块的时候，可以考虑 dummy 掉不相关的模块。 但是这就引入了一个新问题“文件列表的维护”。基于这种 dummy 的思想，文件列表的维 护就成了 tb 里的一个很关键的地方，要尽量避免维护太多的文件列表。我个人比较推荐利用脚 本来自动产生所需要文件列表。除此之外，仿真用的文件列表里我个人比较推荐用绝对路径（避 免别人 debug 的时候出现调错文件的问题，另外可以指定不同的工作目录）。CVS 里用相对路 bswk SMT 加工 www.smtsmt.com.cn 径，相对路径转绝对路径的工作由脚本自动完成。
Q：编译还是运行 option？
A：为了减少编译的次数，能使用运行的 option 就使用运行的 option。比如使用 v a l u e value valueplusargs t e s t test testplusargs
Q：Assertion 谁来写？
A：建议 RTL designer 和 IC 验证工程师都写。内部实现细节的描述由 RTL-designer 自己 写，模块之间的时序由 IC 验证工程师来写.
想要了解更多，可以关注IC修真院，下期继续为大家更新！或者可直接ling 全文档
这里放个口：对 IC 验证的深刻理解