对 IC 验证有哪些深刻理解？十年资深经验工程师为你解读（二）

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 验证的深刻理解