我对验证的一些理解

1、Q：验证的目的？A：发现Bug,发现所有的Bug，或者证明没有Bug （转自夏晶的帖子）Q：对验证工程师的要求？Hacker mentality， Organized testing，Tool automation。如何做更多的testcase.如何覆盖更多的测试点、如何充分的利用服务器、如何尽可能最大 化的自动比对强调一下：“注重细节”是验证工程师一个非常非常好的工作习惯。Q：语言、方法学有多重要？A：我的观点是：这两个都不重要。做事情的是验证工程师，来源是Spec,所以Testplan （全 覆盖testplan）最重要。重要的是验证的意识，愿不愿意去实现H-O-T，即使一开始做的“土”

2、一些也没关系。比如tb里经常要做的“自动比对功能”：1）维护queue，然后foreach的比 较 2）利用 file-operation （fopenfreadfwritefscanf）来做文件比对3）直接$system（diff a b c） 以后看c文件大小。上述三种方法都可以（虽然2）会导致比较多的文件IO，硬盘读写会影 响仿真速度，3）不能做实时的比对。不必拘泥于方法，关键是有这个意识。Q： EDA行业对验证的支持？A：个人感觉虽然（动态）验证这些年在理论方面的突破不大（静态验证一直是热点），但是EDA 行业一直都很重视，实现类的工具主要是在做算法优化，这些年突破不大。但是验证方向上

3、 的点工具一直在不停的出（虽然最终可能也没有几个好使的工具），但是说明EDA行业一直 在致力于寻求在验证上的突破。而且由于现在做SoC的太多，IP又太多，大家都是越来越重 视验证，很多上规模的公司里验证人员较设计人员多不少。个人觉得这可能也是EDA重视 验证的一个原因（用牛工具替代掉一些人LL）。Q：如何跟踪缺陷？A：可以考虑bug-zillar这类的工具-自动跟踪问题。Q：作业提交系统（lsf或grid-engine）A：充分和合理的利用计算资源。Q：环境变量的管理？A：个人推荐使用Module工具。很多公司都是用这个免费的工具Q： Testbench用到的编程语言？A：我觉得tb里syst

4、emverilog和verilog是可以互相替换（当然了，systemverilog特有的内容 用verilog来实现会很复杂），所以推荐tb基于systemverilog来搭建，一些仿真模型可以用 verilogo C除了 Cmodel以外，firmware也会用C和汇编写。基本上我做过的项目里用到的语言：脚本：perl、makefile. shell （perl用的很多，其他用的很少）Tb （包括vmm的组件）：基本是systemverilog仿真模型：systemverilog和verilog混着用Cmodel： C 或 C+Firmware :汇编和 CQ：验证工程师需要掌握的基本技术

5、？A：分享一份我做的基本培训内容安排，供参考Perl，Makefile，AMBA 介绍，SVTB.pdf ，sva,几种用到的编程语言的 File operation ，Low-power， C-pointer， Cshell-AWK+SED， 体系结构相关的一些 内容，SV-1Day training ， VMM_source_code ,Arm的嵌入式编程的基本概念 。：自动化必须吗？A：不是必须的，但是应该尽量去实现自动化。总之是多让机器跑。如果人均License太少 的话，要尽量做到白天debug、晚上让机器跑。“比对”这种事情太机械了，所以尽量让机 器做，做这种事情机器的效率比人高太

6、多。把精力放在构造testcase、testbench、coverage 以及debug和分析上。Q： Testplan 如何做？A：形式不重要，xls可以、word也可以、txt的也可以。但是来源于Spec！ testplan里除了 要罗列 function-test-piont，还应该有 error-injection 和 random-test-point 以及 cover-point 和 assertion o需要和各个team仔细逐条review testplan，有些针对具体实现的coverpoint可能只有designer 能提出来，需要尽早提出。Tb搭建之前，要充分的revie

7、w testplan，因为Testplan的较大修 改有可能会导致整个testbench的架构调整,effort较大。Testplan是一个需要不停增加，不 停迭代、不停review的东西。Error injection 要和 RTL-designer 逐条 review， 一个是看看 RTL-designer 是不是没有想到，一 个是设计是不是本身就不允许、或者架构上本身不可能出现。Error-injection应该往深里去 好好挖掘。例如：内存控制器长时间不回数据（这里本身是一个随机点）d由于长时间不回 数据是否产生错误中断d产生错误中断以后如何响应d响应不过来如何恢复d必须用softwa

8、re reset做恢复的话，对software的时机是否有要求dsoftware前需要遵守什么要求和步骤 虽然现在有一些工具可以根据规范化描述的testplan自动生成cover-point和assertion，不过 我觉得自然语言描述的testplan应该是最“自然”的。Q：哪些地方做随机？A： 1）随机配置（一般都想得到的），但是对于一个封闭的系统常常是最不重要的，因为 firmware可以自己开发，从而控制配置的流程和数值2）随机激励数据（很重要）3）随机时序（通常容易被忘记）但是有一点要明确：随机不是全随机，是约束随机，是在合理的范围内尽量充分的随机。Q：写约束随机哪些地方要注意？A：

9、推荐看snug papero （over-constraint导致测试不完全，欠约束导致不必要的debug和资 源的浪费）约束的效率：写的不好会导致随机失败Q： Coverage 如何做？A： code-coverage 和 function-coverage（covergroup, assertion coverage ）。对于 constraint-random 的地方用covergroup做，对于一些时序的coverage可以用assertion-coverage。：核心脚本？A：单个仿真的脚本-建立所使用的不同的目录、不同的seed （目录可以叫case_$seed 这样的格式；当然对

10、于直接的testcase，可以是case_$casename）；环境变量和license的管 理；如果需要做离线比对也可以让脚本来自动调用比对脚本或命令（也可以在tb的代码里 使用$system 或者$systemf）。批量仿真的脚本-自动批量提交到lsf上。自动收集log信息以判断哪些case失败，对于失 败的case能自动重新提交，并且自动dump波形。以及产生批量仿真结束以后的汇总信息。 Q： SV中重要的点？A：特殊的数据类型，比如新增的三种array （动态、associate、queue） string （match函数、 backref 函数，参考 vcs 的 svtb.pdf）

11、；面向对象编程思想（handle）； coverage； constraint-randomo 熟练掌握这些语言点的用法很有必要。Q： VMM 1.0够不够？A：刚开始用1.0来建立起vmm的概念，然后转到1.1或者1.2上。个人觉得不是必须一下 子就转到1.1或1.2上（当然，1.1的一些扩展宏的确很好用）。个人建议vmm1.0+1.1的扩 展宏+subenvQ：是否要使用VIP？A： VIP的使用-复杂仿真模型推荐用VIP，简单的建议自己做。如果自己开发仿真模型的 话，也推荐看看VIP的文档，经常可以看到一些有价值的error-injection和random-test-points 来完

12、善你自己的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

13、和NC都有option，vcs可以查手册里+optconfigfile”，NC 查” +nctfile”）。反标 Sdf 仿真的时候推荐 notimingcheckano_notifya checking_timing with optconfigfile 的三步走。前期在评估IP的时候，有可能个别模块可能需要单独搭门级环境，比如CPU-IP有RTL，要 自己做flow，那么通常是需要做门仿的（有可能主要是为了跑vcd或saif做power分析）。Tb的修改：由于CTS和综合的原因，导致时钟名字和信号名字有变化，所以tb有可能要修 改。另外，tb里的probe文件建议使用反沿采样，也是为了避免

14、带sdf反标以后clk踩不到 整个data-vector。除此之外，个人不太建议在门仿的时候依然使用自动化的tb。因为你的 tb里抓的很多内部信号可能名字变了（或者被优化掉了），这样导致tb在门级跑的时候维护 起来有些麻烦。有些信号即便名字不变，可能会反向，这样会导致你的checker误报错。毕 竟在门仿的时候不用跑太多的testcase，可以靠几条和rtl仿真 对应的仿真来覆盖。门仿 毕竟不是为了 function，而是为了检查timing。如果你的设计里用了不带reset的dff的描述，由于开始不定态的传播，可能导致你门仿失 败。个人推荐的方法是：如果特别多的话，用脚本找到对应模块里所有d

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

16、如何复现FPGA发现的bug？A：首先保证配置的一致性，可以考虑做一些内部的工具。仿真上要probe寄存器操作端口， FPGA上要能把firmware里的配置流程转成文本。如果配置一样还是不能发现的话，再去逻辑分析仪上debug时序。当然，CDC的问题在仿真 上是看不到的。个人不建议做FPGA网表的门仿，有点得不偿失。Q： FPGA不能cover的部分的验证？A： PAD_Mux （Test_mux）、Clkrst、Power-management-unit 以及 FPGA 跑不到的高频所对应 的功能。Clkrst 这部分主要就是 pllconfig、clock-gate、divider、so

17、ft-and-hard reset,从测试点 的角度还是很明确的，RTL代码修改的少的话，可以考虑不用做太复杂的验证（但是clkrst 模块里可能会有一些控制逻辑或者状态机，比如：sdram的切频，这里一般是需要一个状态 机控制的，这个需要仔细和小心的验证。）PAD_mux个人比较推荐使用自动化的流程，因为代码风格非常固定，所以可以用脚本生成 RTL和用脚本生成testcase （一般这样的testcase是一堆的force）PMU建议看看VCS的MVsim的文档，里面介绍的很清晰了。（还是要配合静态验证工具MVRC 一起来做）没有MVSim的话，可以考虑用VCS的$power $isolat

18、e（Q：固化的firmware如何验证？A：个人不建议让仿真去覆盖firmware，但是对于FPGA和ASIC不一样的地方要重点覆盖到。 大的流程要覆盖到，其他细节由FPGA保证。Q：架构评估？A：我经验也不多，举几个例子。比如你的总线拓扑合理不合理？内存控制器的效率（机制） 是否满足你的应用？使用哪类Cache ? Cache的大小？模块的FIFO深度够不够 （error-injection可以测到）？算法需要多少mips （rvds等工具带的模拟器可以给出结论，但是要让模拟器能考虑到内存access的latency）？软件里如果有不少memcpy的话，要模 拟系统运行起来以后memcpy的

19、效率。如果没有人手专门用ESL （如Carbon的CMS）工具的话，建议在验证平台上做（当然一旦 有大问题，要推翻架构会很麻烦）。Q：哪些资源要节省？A：当然首先是人（数）要节省，人的成本比起计算资源成本和存储资源成本要大多了。提 高技术、提高自动化程度才能节省人的成本。（低Package这种方法属于伤天害理的手段， 不是正当途径）减少硬盘需求（如果有必要）共享simv/simv.daidircsrc包括regression过程中自动清理磁盘 空间）；激励数据是否可以不一下子全产生出来（对于通讯类的比较有意义，由于是floating 的激励数据，所以经常很短时间就需要GB的空间）。注意对每个人

20、每个项目设置硬盘quota， 避免被个别人撑爆存储。减少编译次数。soc项目里比较有必要，testcase基于firmware ），parallel-compile or separate-compile，vmm-test，在一个 testcase 里做多个功能点的覆盖，fsdb/vpd 的 dump 层次的改变不要重新编译（fsdb有command，vpd可能得用ucli）。Q：设计规模大了编译很慢怎么办？A：有时候设计规模太大导致编译很慢，但是SoC项目很多情况下，功能模块彼此之间是用 总线隔开的（即便在功能模块之间有硬件连线也可以考虑用仿真模型来做替代）。在仿真某 一个功能模块的时候，可

21、以考虑dummy掉不相关的模块。但是这就引入了一个新问题“文件列表的维护”。基于这种dummy的思想，文件列表的维 护就成了 tb里的一个很关键的地方，要尽量避免维护太多的文件列表。我个人比较推荐利 用脚本来自动产生所需要文件列表。除此之外，仿真用的文件列表里我个人比较推荐用绝对 路径（避免别人debug的时候出现调错文件的问题，另外可以指定不同的工作目录）。CVS 里用相对路径，相对路径转绝对路径的工作由脚本自动完成。Q：编译还是运行option？A:为了减少编译的次数，能使用运行的option就使用运行的option。比如使用$value$plusargs$test$plusargsQ：

22、Assertion 谁来写？A：建议RTL designer和IC验证工程师都写。内部实现细节的描述由RTL-designer自己写， 模块之间的时序由IC验证工程师来写。Assertion的抽象层次有些高，写复杂了有时候极容易出现和你想象不一致的地方。而且如 果spec上描述的不清楚，误报assertion-fail也会引入不必要的debug时间。Q： IC验证工程师要不要看RTL？A：不是很必要，但是有些设计背景比较强的验证工程师看代码通常能看到一些问题。个人 建议还是拿出点时间来review 一下RTL code。：自动化的tb搭好了，波形对验证工程师来说还那么重要吗？A：非常非常的重要

23、。毋庸置疑！波形是最直接的，checker可能写错，有问题没有报出来。 但是没有激励就没有所要的波形信息。Q：如何重用？A： reuse可以分为横向和纵向。横向是指项目之间。这个reuse主要包括：文档和tb、script。纵向是指同一个项目内，一般是模块级和系统级（包括子系统级）。一般是tb和scripto 比如在一个项目中，所有的tb都是用run_sim和regress脚本的，只是带的filelist不同。对 于tb来说，driver和generator可能不能reuse，但是一般monitor和scoreboard这类被动接 收的一般都可以reuse。而且testcase通常是可以reu

24、se的。对于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不同，其实是可以跑到各种各样

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

26、2）静态变量处理要小心。举个例子：我是每帧调一次systemf来做比对，某个函数每次比对会 被调用一次。函数里的静态变量就没什么静态的意义了。如果不做修改的话，肯定会出错。 一般是要求算法组尽量少用静态变量，非用不可的话，我们会把静态变量改成全局变量，然 后让systemf多一个参数。要说明的是：DPI “天然”的就是tb的一部分。但是我觉得把时间浪费在debug算法C代 码的优劣上是一件很不值得的事情（无论什么时候都是schedule优先），当然我也很佩服有 些人对任何事情都“精益求精”的态度。无论用不用DPI，你都可以使用DDD这类debug工具。DDD这种工具在非DPI情况下用起来 会更

27、加的得心应手。Q： Force要不要用？A：有的人比较抵触用Force-release，觉得如果写的不注意的话，可能会浪费时间（debug 或者re-compile）。个人觉得“规定所有人把各自模块的force语句写在一个文件里，然后再 被一个统一的force_prj.sv include进去，并且include前要有ifdef保护起来”应该可以规避 掉一些风险。Q：人手少的情况下怎么做验证？A：我个人觉得验证不能大包大揽，人手少的话就要更多的靠RTL-designer自己做验证。对 于某些模块验证工程师就不要做了，否则陷进去出不来，反而影响了核心模块的验证力度。 可以适当的更多依赖FPGA。但是对于核心模块一定要做好验证