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里用相对路径，相对路径转绝对路径的工作由脚本自动完成。

Q：编译还是运行option？

A：为了减少编译的次数，能使用运行的option就使用运行的option。比如使用$value$plusargs $test$plusargs

Q：Assertion谁来写？

A：建议RTL designer和IC验证工程师都写。内部实现细节的描述由RTL-designer自己写，模块之间的时序由IC验证工程师来写。

Assertion的抽象层次有些高，写复杂了有时候极容易出现和你想象不一致的地方。而且如果spec上描述的不清楚，误报assertion-fail也会引入不必要的debug时间。

Q：IC验证工程师要不要看RTL？

A：不是很必要，但是有些设计背景比较强的验证工程师看代码通常能看到一些问题。个人建议还是拿出点时间来review一下RTL code。

Q：自动化的tb搭好了，波形对验证工程师来说还那么重要吗？

A：非常非常的重要。毋庸置疑！！波形是最直接的，checker可能写错，有问题没有报出来。但是没有激励就没有所要的波形信息。

Q：如何重用？

A：reuse可以分为横向和纵向。

   横向是指项目之间。这个reuse主要包括：文档和tb、script。

   纵向是指同一个项目内，一般是模块级和系统级（包括子系统级）。一般是tb和script。

   比如在一个项目中，所有的tb都是用run_sim和regress脚本的，只是带的filelist不同。对于tb来说，driver和generator可能不能reuse，但是一般monitor和scoreboard这类被动接收的一般都可以reuse。而且testcase通常是可以reuse的。

       对于SoC类项目，为了保持testcase的一致性，我个人比较倾向于都使用firmware做testcase，这就要求

1）模块的验证也要基于一个（类）soc的tb下验证。

2）cpu-ip要尽量简单，否则cpu会占用太多的仿真资源。个人推荐用iss做cpu-ip，负责配置寄存器。

Q：regression什么时候做？做多少次？

A：tb好了以后，任何时候都可以做。下班后尽量提交regression到lsf里，让机器充分的跑。如果你的环境是random的，那么随机空间实际是很大的（随着random-test-point的增长指数级增长），所以只要seed不同，其实是可以跑到各种各样的情况。

Q：DPI要不要用？

A：有的人很喜欢用DPI，不过我个人不喜欢用。我尽量是把C封装好（自己写wrapper），产生可执行文件，然后在tb里用$systemf来调。不喜欢用DPI的原因主要是因为如果代码里有不太安全的地方（比如C代码里你不是在堆上而是在栈上开了一个大数组，或者C和SV之间的参数传递写法不合理），很容易造成coredump。而且你也不确定到底是SV写的不安全还是C写的不安全。另外，有些大公司的算法源代码是不提供的，只给你一个.o文件，这样coredump了你debug起来会让你有砍人的冲动。

但是不用DPI也带来一些坏处：

1）
要自己写一些wrapper之类的代码

2）
静态变量处理要小心。举个例子：我是每帧调一次systemf来做比对，某个函数每次比对会被调用一次。函数里的静态变量就没什么静态的意义了。如果不做修改的话，肯定会出错。一般是要求算法组尽量少用静态变量，非用不可的话，我们会把静态变量改成全局变量，然后让systemf多一个参数。

要说明的是：DPI“天然”的就是tb的一部分。但是我觉得把时间浪费在debug 算法C代码的优劣上是一件很不值得的事情（无论什么时候都是schedule优先），当然我也很佩服有些人对任何事情都“精益求精”的态度。

       无论用不用DPI，你都可以使用DDD这类debug工具。DDD这种工具在非DPI情况下用起来会更加的得心应手。

Q：Force要不要用？

A：有的人比较抵触用Force-release，觉得如果写的不注意的话，可能会浪费时间（debug或者re-compile）。个人觉得“规定所有人把各自模块的force语句写在一个文件里，然后再被一个统一的force_prj.sv include进去，并且include前要有`ifdef保护起来”应该可以规避掉一些风险。

Q：人手少的情况下怎么做验证？

A：我个人觉得验证不能大包大揽，人手少的话就要更多的靠RTL-designer自己做验证。对于某些模块验证工程师就不要做了，否则陷进去出不来，反而影响了核心模块的验证力度。可以适当的更多依赖FPGA。但是对于核心模块一定要做好验证（比如内存控制器以及FPGA覆盖不到的模块等）

Q：IP要不要验证？

A：首先是去找业界口碑好的IP（个人觉得对数字IP来说silicon-validition一样重要）。人手不够的时候，可以考虑让FPGA多承担一些IP的验证，对于IP里一些FPGA无法cover到的测试功能点，可以考虑用直接testcase的方法覆盖。