|
对于SoC类项目，为了保持testcase的一致性，我个人比较倾向于都使用firmware做testcase，这就要求
1）模块的验证也要基于一个（类）soc的tb下验证。
2）cpu-ip要尽量简单，否则cpu会占用太多的仿真资源。个人推荐用iss（wolf评论：what？）做cpu-ip，负责配置寄存器。 Q：regression什么时候做？做多少次？ A：tb好了以后，任何时候都可以做。下班后尽量提交regression到lsf里，让机器充分的跑。如果你的环境是random的，那么随机空间实际是很大的（随着random-test-point的增长指数级增长），所以只要seed不同，其实是可以跑到各种各样的情况。 Q：DPI要不要用？ A：有的人很喜欢用DPI，不过我个人不喜欢用。我尽量是把C封装好（自己写wrapper），产生可执行文件，然后在tb里用$systemf（wolf评论：what？verilog里的系统函数？sv里的系统函数？sc？还是贵公司封装出来的？）来调。不喜欢用DPI的原因主要是因为如果代码里有不太安全的地方（比如C代码里你不是在堆上而是在栈上开了一个大数组，或者C和SV之间的参数传递写法不合理），很容易造成coredump。而且你也不确定到底是SV写的不安全还是C写的不安全。另外，有些大公司的算法源代码是不提供的，只给你一个.o文件，这样coredump了你debug起来会让你有砍人的冲动。 但是不用DPI也带来一些坏处： 1）
要自己写一些wrapper之类的代码 2）
静态变量处理要小心。举个例子：我是每帧调一次systemf来做比对，某个函数每次比对会被调用一次。函数里的静态变量就没什么静态的意义了。如果不做修改的话，肯定会出错。一般是要求算法组尽量少用静态变量，非用不可的话，我们会把静态变量改成全局变量，然后让systemf多一个参数。 要说明的是：DPI“天然”的就是tb的一部分。但是我觉得把时间浪费在debug 算法C代码的优劣上是一件很不值得的事情（无论什么时候都是schedule优先），当然我也很佩服有些人对任何事情都“精益求精”的态度。 无论用不用DPI，你都可以使用DDD（wolf评论：what？）这类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的方法覆盖。 Q: Debug到什么程度请designer来debug? A：首先schedule优先，然后本着“力所能及”的原则，有时间有精力就debug的深入一些，否则checker报错以后，确认一下不是checker误报，就可以先提交给RTL-designer。 Q：遗漏bug怎么办 A：开发过程（FPGA）乃至最终silicon-validition甚至已经产品化后都可能发现遗漏的bug，要重视这些被仿真遗漏掉的bug。要一个一个的做case-analysis，仔细的分析为什么testbench没有抓到这样的问题。而且对于TO（wolf评论：I see！Tap－Out!）以后发现的Bug，要在下一版里重点review，以保证不犯同样的错误。另外，对于每个bug都应该尽量加一条对应的assertion。 Q：验证工程师要不要深入了解自己负责验证的模块？ A：虽然不深入了解，也不影响刚开始的工作，但是要把自己负责的模块吃透的话我觉得是很有必要的，我希望验证工程师能从系统（架构）一直到应用这些层面上都能深入的了解自己负责的模块。 Q：分享的氛围。 A：我个人觉得验证的范围很广，一个人很难把各个方面都搞的很精通。经常的技术讨论和培训是非常有必要的。Team-leader应该营造一个很好的技术分享的氛围。 | 
楼主
标题置顶
标题高亮
