我对验证的一些理解
发布: 2012-1-07 21:47 | 作者: lshj98115 | 来源: EETOP 赛灵思(Xilinx) 社区
下面这些问题和回答是基于我个人对验证(主要是动态仿真验证)的理解,可
能有理解的不到位、理解有偏差的地方,欢迎大家指正。
我是 synopsys 的用户,所以下面描述的大多是针对 synopsys 的工具。
欢迎发邮件到[url=mailto:lshj98115@sohu.com]lshj98115@sohu.com[/url]和我讨
论验证的问题。
Q:验证的目的?
A:发现 Bug,发现所有的 Bug,或者证明没有 Bug(转自夏晶的帖子)
Q:对验证工程师的要求?
Hacker mentality ,Organized testing ,Tool automation。
如何做更多的 testcase、如何覆盖更多的测试点、如何充分的利用服务器、
如何尽可能最大化的自动比对
强调一下:“注重细节”是验证工程师一个非常非常好的工作习惯。
Q:语言、方法学有多重要?
A:我的观点是:这两个都不重要。做事情的是验证工程师,来源是 Spec,所
以 Testplan(全覆盖 testplan)最重要。重要的是验证的意识,愿不愿意去实现 H-O-
T,即使一开始做的“土”一些也没关系。比如 tb 里经常要做的“自动比对功能”:
1)维护 queue,然后 foreach 的比较 2)利用 file-operation(fopen fread fwrite fsca
nf)来做文件比对 3)直接$system(diff a b > c)以后看 c 文件大小。上述三种方法
都可以(虽然 2)会导致比较多的文件 IO,硬盘读写会影响仿真速度,3)不能做实
时的比对。不必拘泥于方法,关键是有这个意识。
Q:EDA 行业对验证的支持?
A:个人感觉虽然(动态)验证这些年在理论方面的突破不大(静态验证一直是热
点),但是 EDA 行业一直都很重视,实现类的工具主要是在做算法优化,这些年突
破不大。但是验证方向上的点工具一直在不停的出(虽然最终可能也没有几个好使
的工具),但是说明 EDA 行业一直在致力于寻求在验证上的突破。而且由于现在做
SoC 的太多,IP 又太多,大家都是越来越重视验证,很多上规模的公司里验证人员
较设计人员多不少。个人觉得这可能也是 EDA 重视验证的一个原因(用牛工具替代
掉一些人)。
Q:如何跟踪缺陷?
A:可以考虑 bug-zillar 这类的工具---- 自动跟踪问题。
Q:作业提交系统(lsf 或 grid-engine)
A:充分和合理的利用计算资源。
Q:环境变量的管理?
A:个人推荐使用 Module 工具。很多公司都是用这个免费的工具
Q:Testbench 用到的编程语言?
A:我觉得 tb 里 systemverilog 和 verilog 是可以互相替换(当然了,systemveril
og 特有的内容用 verilog 来实现会很复杂),所以推荐 tb 基于 systemverilog 来搭建,
一些仿真模型可以用 verilog。C 除了 Cmodel 以外,firmware 也会用 C 和汇编写。
基本上我做过的项目里用到的语言:
脚本:perl、makefile、shell(perl 用的很多,其他用的很少)
Tb(包括 vmm 的组件):基本是 systemverilog
仿真模型:systemverilog 和 verilog 混着用
Cmodel :C 或 C++
Firmware :汇编和 C
Q:验证工程师需要掌握的基本技术?
A:分享一份我做的基本培训内容安排,供参考
Perl,Makefile,AMBA 介绍,SVTB.pdf ,sva,几种用到的编程语言的 File operatio
n ,Low-power, C-pointer,Cshell-AWK+SED,体系结构相关的一些内容,SV-1D
ay training ,VMM_source_code ,Arm 的嵌入式编程的基本概念
Q:自动化必须吗?
A:不是必须的,但是应该尽量去实现自动化。总之是多让机器跑。如果人均 L
icense 太少的话,要尽量做到白天 debug、晚上让机器跑。“比对”这种事情太机械
了,所以尽量让机器做,做这种事情机器的效率比人高太多。把精力放在构造 testc
ase、testbench、coverage 以及 debug 和分析上。
Q:Testplan 如何做?
A:形式不重要,xls 可以、word 也可以、txt 的也可以。但是来源于 Spec!tes
tplan 里除了要罗列 function-test-piont,还应该有 error-injection 和 random-test-point
以及 cover-point 和 assertion。
需要和各个 team 仔细逐条 review testplan,有些针对具体实现的 coverpoint 可
能只有 designer 能提出来,需要尽早提出。Tb 搭建之前,要充分的 review testplan,
因为 Testplan 的较大修改有可能会导致整个 testbench 的架构调整,effort 较大。Tes
tplan 是一个需要不停增加,不停迭代、不停 review 的东西。
Error injection 要和 RTL-designer 逐条 review,一个是看看 RTL-designer 是不
是没有想到,一个是设计是不是本身就不允许、或者架构上本身不可能出现。Error
-injection 应该往深里去好好挖掘。例如:内存控制器长时间不回数据(这里本身是
一个随机点)由于长时间不回数据是否产生错误中断产生错误中断以后如何响
应响应不过来如何恢复必须用 software reset 做恢复的话,对 software 的时机是
否有要求software 前需要遵守什么要求和步骤
虽然现在有一些工具可以根据规范化描述的 testplan 自动生成 cover-point 和 ass
ertion,不过我觉得自然语言描述的 testplan 应该是最“自然”的。
Q:哪些地方做随机?
A:1)随机配置(一般都想得到的),但是对于一个封闭的系统常常是最不重
要的,因为 firmware 可以自己开发,从而控制配置的流程和数值
2)随机激励数据(很重要)
3)随机时序(通常容易被忘记)
但是有一点要明确:随机不是全随机,是约束随机,是在合理的范围内尽
量充分的随机。
Q:写约束随机哪些地方要注意?
A:推荐看 snug paper。(over-constraint 导致测试不完全,欠约束导致不必要的
debug 和资源的浪费)约束的效率:写的不好会导致随机失败
Q:Coverage 如何做?
A:code-coverage 和 function-coverage(covergroup, assertion coverage)。对于
constraint-random 的地方用 covergroup 做,对于一些时序的 coverage 可以用 assertio
n-coverage。
Q:核心脚本?
A:单个仿真的脚本 ---- 建立所使用的不同的目录、不同的 seed(目录可以叫 c
ase_$seed 这样的格式;当然对于直接的 testcase,可以是 case_$casename);环境变
量和 license 的管理;如果需要做离线比对也可以让脚本来自动调用比对脚本或命令
(也可以在 tb 的代码里使用$system 或者$systemf)。
批量仿真的脚本----自动批量提交到 lsf 上。自动收集 log 信息以判断哪些 case
失败,对于失败的 case 能自动重新提交,并且自动 dump 波形。以及产生批量仿真
结束以后的汇总信息。
Q:SV 中重要的点?
A:特殊的数据类型,比如新增的三种 array(动态、associate、queue)、strin
g(match 函数、backref 函数,参考 vcs 的 svtb.pdf);面向对象编程思想(handle);
coverage;constraint-random。
熟练掌握这些语言点的用法很有必要。
Q:VMM 1.0 够不够?
A:刚开始用 1.0 来建立起 vmm 的概念,然后转到 1.1 或者 1.2 上。个人觉得不
是必须一下子就转到 1.1 或 1.2 上(当然,1.1 的一些扩展宏的确很好用)。个人建
议 vmm1.0+1.1 的扩展宏+subenv
Q:是否要使用 VIP?
A:VIP 的使用 --- 复杂仿真模型推荐用 VIP,简单的建议自己做。如果自己开
发仿真模型的话,也推荐看看 VIP 的文档,经常可以看到一些有价值的 error-injecti
on 和 random-test-points 来完善你自己的 testplan。
Q:要不要做门级仿真?
A:如果是走 design-service,不知道最终带 sdf 的 netlist 仿真是否需要做,如果
做的话,最好在 release 综合后 netlist 的时候也做一下(插完 scan-chain 和做完 CTS
以后有条件也做一下),如果需要 VCD 文件做 power 分析和指导 PR 工具的话,那
么门仿是必须做的。如果 design-service 公司不负责调量产 pattern 的话,那么 ATP
G 等的门仿是需要自己做的。
门仿并不是 sign-off 标准,但是推荐还是做一下,经常还是能跑出问题来的。
如果做 sdf 反标的门仿的话,对于 async 的多级 dff 要剔除掉(VCS 和 NC 都有 opti
on,vcs 可以查手册里“+optconfigfile”,NC 查”+nctfile”)。反标 Sdf 仿真的时候推
荐 notimingcheckno_notifychecking_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 优先,其次是力所能及。但是原则上是先仿真然后再上 FP
GA,仿真可以很快的扫清一些基本的 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、sof
t-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-comp
ile or separate-compile ,vmm-test,在一个 testcase 里做多个功能点的覆盖,fsdb/vp
d 的 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-de
signer 自己写,模块之间的时序由 IC 验证工程师来写。
Assertion 的抽象层次有些高,写复杂了有时候极容易出现和你想象不一致的地
方。而且如果 spec 上描述的不清楚,误报 assertion-fail 也会引入不必要的 debug 时
间。
Q:IC 验证工程师要不要看 RTL?
A:不是很必要,但是有些设计背景比较强的验证工程师看代码通常能看到一
些问题。个人建议还是拿出点时间来 review 一下 RTL code。
Q:自动化的 tb 搭好了,波形对验证工程师来说还那么重要吗?
A:非常非常的重要。毋庸置疑!!波形是最直接的,checker 可能写错,有问
题没有报出来。但是没有激励就没有所要的波形信息。
Q:如何重用?
A:reuse 可以分为横向和纵向。
横向是指项目之间。这个 reuse 主要包括:文档和 tb、script。