VCS与Verdi联合仿真简易教程及例子示范

最近在公司实习，最近也恰好在学习Linux下的IC设计环境，涉及到了VCS与Verdi联合仿真等内容，也切身感觉到，和学校学习的内容是如此的不同，此篇便来讲下：

1. VCS，Verdi是什么，为何要用VCS和Verdi？
2. 用一个简短的例子展示如何在Linux下使用VCS，Verdi对Verilog文件进行功能仿真；
3. 一些用VCS，Verdi的提高效率的方式；

1. VCS，Verdi介绍

相信大家都用过Vivado，Quartus等，这里以Vivado为例，他包含了RTL，编译，仿真，综合，看波形，烧板子等，集大成为一体。相比之下，VCS和Verdi就很专一了，VCS专注于编译及仿真，Verdi专注于看波形，仅此而已，安分守己。那Vivado这种功能这么全，工业界直接全用一个Vivado走天下不就行了，为何要大费周折用VCS和Verdi呢？

按我公司老板的话来讲，Vivado其实只能算个写Verilog的（而且还很慢），只不过集成了综合，仿真，看波形等功能，如果要真正做Asic设计，还是得在各个步骤用上用更加专业的软件，用那些在领域中做到顶峰的EDA，对，那就是Synopsys的VCS，Verdi这种（毕竟Vivado的优化大多也只针对于自家FPGA）。首先VCS编译仿真速度极快，效率极高，为大家节约时间，Verdi看波形也十分方便debug，它支持信号追溯，无缝增加信号波形等功能。虽然上手比Vivado难，但学习之后能感受到其美丽之处的。

（注意：仿真包含前仿和后仿，如果单纯的前仿，VCS就绰绰有余了，然后想后仿，那就得需要再用DC (Design Complier) 来“综合”，此篇专注于前仿）

2. VCS，Verdi使用教程

环境：Linux

编写Verilog：Vim or Gedit

编译仿真：VCS

波形查看：Verdi

这里默认VCS和Verdi环境都已配好，需要配环境的朋友可以自行百度~

1. 可以Terminal输入vcs，verdi来验证下环境有没有配置成功（若安装成功一般会如下图所示，但出现下图也不能确保环境一定是正确的）；

• Terminal输入vcs会显示如下：
  
• Terminal输入verdi会直接调用出verdi的GUI
  

2. 这样我们先新建一个计数器的verilog文件以及testbench文件（流程是：在桌面新建Counter文件夹，并在文件夹内新建counter.v，tb_counter.v和timescale.v文件。如果不熟悉可以鼠标操作）；

cd Desktop
mkdir Counter
cd Counter

3. 至此已完成Counter文件夹建立以及Terminal路径现在在\Desktop\Counter里，我们继续：在文件夹里新建counter.v，tb_counter.v和timescale.v文件，其内容如下：

vim counter.v

module counter(
        input                   clk,
        input                   rst,
        output  reg     [5:0]   count
);
always @(posedge clk or negedge rst)
begin
        if(!rst)
                count <= 0;
        else
                count <= count + 1;
end
endmodule

vim tb_counter.v

module tb_counter();

reg 		clk,rst;
wire	[5:0]	counter;

counter u1(clk,rst,counter);

always #(5) clk = ~clk;

initial begin
	clk <= 0;
	rst <= 0;
	#20;
	rst <= 1;
	#50;
	if(counter != 5)
		$display("Failure 1: the counter should be 5 but it is %d",counter);
  else
  	$display("You gotta the right result!");
	$finish;
end

`ifdef FSDB
initial begin
	$fsdbDumpfile("tb_counter.fsdb");
	$fsdbDumpvars;
end
`endif
endmodule

vim timescale.v

`timescale 1ns/10ps

（注意，要VCS与Verdi联合仿真，需要在testbench里面必须加入``ifdef FSDB到endif`的代码，这样才能生成fsdb文件提供Verdi读取，不然不会输出波形）

4. 我们已经有了RTL代码了，现在开始用vcs调用这两文件，对counter进行功能仿真；
5. 在Terminal输入如下代码并运行

vcs -R -full64 +v2k -fsdb +define+FSDB -sverilog counter.v tb_counter.v timescale.v -l run.log

其中-R表示自动运行仿真，+v2k表示使用Verilog-2001标准，-fsdb表示支持对fsdb相应操作，+define+FSDB相当于在verilog头文件里加上`define FSDB，-sverilog表示支持system verilog，输入.v文件的顺序可以不同（顺序是随意的）-l run.log表示将终端显示的信息在run.log中储存；

6. 当Terminal显示下图，并在文件夹中出现fsdb文件时，代表vcs已经对counter编译仿真成功了：
   

7. 现在我们可以打开verdi来看波形了，在Terminal输入：

   verdi
   

   再按下图点击相应选项，它们的意思也很直白，就不解释了；
   
   

8. 然后按图依次点击，导入代码，然后会变下图所示，恭喜，至此您已经完成了verdi看代码了，开心吧！

9. 但还没出波形呢，别急，我们现在导入之前生成的fsdb文件。

   按图依次点击，导入fsdb文件，以显示波形：

没错，还是没有波形输出，哈哈哈哈 _别气馁
这不是bug，因为我们还没有告诉波形窗口应该看哪个信号的波形，那我们先直接调用这个counter.v里面所有信号的波形吧~ 再按如下操作verdi：

10. 这样我们就看到波形啦，对于别的工程也可以依据此例子来做VCS与Verdi联合仿真啦~

至此，我们简单的VCS与Verdi联合仿真例子就大功告成咯，是不是很开心~

可能有些朋友在想，我没看到他们俩一起用有啥方便啊，又得手打命令，又得调来调去，麻烦的很，还没Vivado一半智能。那在下节，我来涉及些VCS和Verdi的一些基本提高效率操作吧~

3. VCS，Verdi提高效率

试想下，我们仅需在Terminal内敲入15个字母的命令，就能迅速自动完成vcs编译仿真甚至调用出verdi，是不是感觉很快，很速度！verdi可以实现代码窗口，波形窗口的联合debug，提高debug效率，是不是很高级，很舒适！

那具体怎么实现呢，请往下看~

1. 调用vcs时不用每次都手打 .v文件，使用 .f文件就行，以及用脚本实现调用vcs，具体如下：

   在工程文件夹（这里继续用上面Counter的例子）里面新建一个.f文件;

   （这里用的vim，不熟悉的可以鼠标新建.f文件并输入内容）

   cd Desktop/Counter
   vim file.f
   

   file.f内容如下

   tb_counter.v counter.v timescale.v
   

   依旧，这里.v的顺序不重要，只需要将包含的文件写进去便行；

   这样，这个file.f文件便代表了工程中的三个.v文件，在调用vcs来前仿时便能这么写了：

   vcs -R -full64 +v2k -fsdb +define+FSDB -sverilog -f file.f -l run.log
   

   此时，-f代表着你在使用.f文件了，之后如果想再添加.v文件，就在file.f中添加便可~

   是不是感觉方便了一些，但感觉方便的还不够啊，以后每次开机岂不都都得重打这个长长的vcs命令，然后在输入verdi？

   为了避免如此，我们可以用脚本来做下操作~

   首先在Counter文件夹里，新建一个文件，我们叫他runrand（这个可以无后缀的，我这里使用的vim，也能鼠标新建文件）

   vim runrand
   

   然后在runrand文件输入如下内容（实验室Linux系统的shell是bash，此以bash为例）

   #!/bin/bash
   vcs -R -full64 +v2k -fsdb +define+FSDB -sverilog -f file.f -l run.log
   verdi
   

   然后在Terminal输入如下命令，将runrand转为执行文件：

   chmod -x runrand
   

   这样，在每次重新启动Terminal时，我们仅需在Terminal输入以下命令便能进行vcs仿真，并调用出verdi了~

   （实验室Linux系统的shell是bash，此以bash为例）

   source runrand
   

   是不是方便了很多~

   （如果不想直接调出verdi可以在runrand里将verdi这一行去掉）

2. Verdi的优点体现

   ​ 不知道大家之前是不是也遇到过这种困扰，使用Vivado或者Modelsim看波形时，为了增加某几个信号的波形，又得重新仿真一遍（贼耗时间）；为了追踪一个信号它在某几个时刻的变化原因，需要对着波形图琢磨几遍（贼耗时间）…

   ​ 那么Verdi在这块都已经全部解决，在Verdi看增加信号波形无需再次仿真，追踪信号只需要在代码窗口里点击相应信号便能看到它是由哪些信号决定的。

   那具体操作如下：

   • 在导入.v文件以及.fsdb文件后，如果我们要增加某信号波形，可以鼠标单击代码窗口的对应信号，然后再键盘输入ctrl+w，这样该信号的波形便直接导入波形窗口并显示了，不需要再次仿真，是不是超级方便！！！

• 为了让debug更加快捷，我们可以在代码窗口单击键盘的x键，以显示出每个wire和reg在特定clk时的值的变化，再也不需要盯着波形来回看了！

• verdi也能生成.v文件对应的电路结构图，具体如下图所示：

• verdi还有很多快捷键，比如ctrl+4将.v文件中所有信号波形全部导入波形窗口，在波形窗口按f自动适配波形大小，按z缩小波形，按Z放大波形，等等，许多便捷操作，以及用命令行或者脚本直接verdi读取fsdb文件并显示等，这些大家可以自行上网查询~
• 这里再举个命令行直接调用verdi并直接导入.v文件，.fsdb文件的操作。同时我们也能像先前生成runrand脚本文件那样，创建一个新脚本文件调用下面的命令，从而提高效率~

verdi -ssf tb_counter.fsdb -2001 -sverilog tb_counter.v counter.v

• 欢迎大家找到更棒的快捷键或命令后与我分享，一起来完善此教程~

总结

十分感谢看到这里，教程就到此为止了，相信大家也已经能自主应用VCS和Verdi去对自己工程进行前仿以及看波形了。教程里面涉及的较少，如果想更加深入了解VCS和Verdi，建议去品读synopsys的官方指导文档，同时这也有一个良心UP主的VCS Lab教程视频，有兴趣的朋友也能看看，会让您对VCS有更深地理解。

https://www.bilibili.com/video/BV1Ab411r75o，这是VCS Lab1，还有Lab2，3，直接在UP主主页便能看见~

该范例已经包含一个测试用例的模板。

3、测试用例设计的误区

1、能发现到目前为止没有发现的缺陷的用例是好的用例：

首先要申明，其实这句话是十分有道理的，但我发现很多人都曲解了这句话的原意，一心要设计出发现“难于发现的缺陷”而陷入盲目的片面中去，忘记了测试的目的所在，这是十分可怕的。我倾向于将测试用例当作一个集合来认识，对它的评价也只能对测试用例的集合来进行，测试本身是一种“V&V”的活动，测试需要保证以下两点：

l 程序做了它应该做的事情 

l 程序没有做它不该做的事情

因此，作为测试实施依据的测试用例，必须要能完整覆盖测试需求，而不应该针对单个的测试用例去评判好坏。

2、测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试；

不知道国内有没有公司真正做到这点，或者说，不知道有国内没有公司能够将每个测试用例都写得如此详细。在我的测试经历中，对测试用例描述的详细和复杂程度也曾有过很多的彷徨。写得太简单吧，除了自己没人能够执行，写得太详细吧，消耗在测试用例维护（别忘了，测试用例是动态的，一旦测试环境、需求、设计、实现发生了变化，测试用例都需要相应发生变化）上的时间实在是太惊人，在目前国内大部分软件公司的测试资源都不足的情况下，恐怕很难实现。但我偏偏就能遇到一些这样的老总或者是项目负责人，甚至是测试工程师本身，全然不顾实际的资源情况，一定要写出“没有接触过系统的人员也能进行测试”的用例。

在讨论这个问题之前，我们可以先考虑一下测试的目的。测试的目的是尽可能发现程序中存在的缺陷，测试活动本身也可以被看作是一个Project，也需要在给定的资源条件下尽可能达成目标，根据我个人的经验，大部分的国内软件公司在测试方面配备的资源都是不足够的，因此我们必须在测试计划阶段明确测试的目标，一切围绕测试的目标进行。

除了资源上的约束外，测试用例的详细程度也需要根据需要确定。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻，那测试用例就没有必要太详细了，文档的作用本来就在于沟通，只要能达到沟通的目的就OK。

在我担任测试经理的项目中，在测试计划阶段，一般给予测试设计30% - 40%左右的时间，测试设计工程师能够根据项目的需要自行确定用例的详细程度，在测试用例的评审阶段由参与评审的相关人对其把关。

3、测试用例设计是一劳永逸的事情；

这句话摆在这里，我想没有一个人会认可，但在实际情况中，却经常能发现这种想法的影子。我曾经参与过一个项目，软件需求和设计已经变更了多次，但测试用例却没有任何修改。导致的直接结果是新加入的测试工程师在执行测试用例时不知所措，间接的后果是测试用例成了废纸一堆，开发人员在多次被无效的缺陷报告打扰后，对测试人员不屑一顾。

这个例子可能有些极端，但测试用例与需求和设计不同步的情况在实际开发过程中确是屡见不鲜的，测试用例文档是“活的”文档，这一点应该被测试工程师牢记。

4、测试用例不应该包含实际的数据；

测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行性。当然，测试用例中包含输入数据会带来维护、与测试环境同步之类的问题，关于这一点，《Effective Software Test》一书中提供了详细的测试用例、测试数据的维护方法，可以参考。

5、测试用例中不需要明显的验证手段；

我见过很多测试工程师编写的测试用例中，“预期输出”仅描述为程序的可见行为，其实，“预期结果”的含义并不只是程序的可见行为。例如，对一个订货系统，输入订货数据，点击“确定”按钮后，系统提示“订货成功”，这样是不是一个完整的用例呢？是不是系统输出的“订货成功”就应该作为我们唯一的验证手段呢？显然不是。订货是否成功还需要查看相应的数据记录是否更新，因此，在这样的一个用例中，还应该包含对测试结果的显式的验证手段：在数据库中执行查询语句进行查询，看查询结果是否与预期的一致。

4、测试用例在软件测试中的作用 

    1、指导测试的实施 

    测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。 

    根据测试用例的测试等级，集成测试应测试那些用例，系统测试和回归测试又该测试那些用例，在设计测试用例时都已作明确规定，实施测试时测试人员不能随意作变动。 

    2、规划测试数据的准备 

在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。

除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。 

    3、编写测试脚本的"设计规格说明书" 

    为提高测试效率，软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。 

    4、评估测试结果的度量基准 

    完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。 

    5、分析缺陷的标准 

    通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。

5、试用例编号规则

目的：好的测试用例编号，可以更好的去了解此项用例所针对的模块，也有助于记忆和新用例的增加。

规则：测试用例编号采用“版本+细类+编号”的形式。

备注：其中“版本”为设计此测试用例的软件版本。

“细类”为小模块中的汉字头一个字母，以最多5个字母为标准。

“编号”为BUG用例的编号，以4位为标准，依次递增。

例如：引导系统V2.01版本中，候车点设置，用例编号可以书写为：

          2.01_HCDSZ_0001

九、集成测试

      集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。此外，如果程序由多个进程组成，应该成对测试它们，而不是同时测试所有进程。

      集成测试识别组合单元时出现的问题。通过使用要求在组合单元前测试每个单元并确保每个单元的生存能力的测试计划，可以知道在组合单元时所发现的任何错误很可能与单元之间的接口有关。这种方法将可能发生的情况数量减少到更简单的分析级别。

      集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。也就是说，在集成测试之前，单元测试应该已经完成，集成测试中所使用的对象应该是已经经过单元测试的软件单元。这一点很重要，因为如果不经过单元测试，那么集成测试的效果将会受到很大影响，并且会大幅增加软件单元代码纠错的代价。 

      集成测试是单元测试的逻辑扩展。在现实方案中，集成是指多个单元的聚合，许多单元组合成模块，而这些模块又聚合成程序的更大部分，如分系统或系统。集成测试采用的方法是测试软件单元的组合能否正常工作，以及与其他组的模块能否集成起来工作。最后，还要测试构成系统的所有模块组合能否正常工作。集成测试所持的主要标准是《软件概要设计规格说明》，任何不符合该说明的程序模块行为都应该加以记载并上报。 

      所有的软件项目都不能摆脱系统集成这个阶段。不管采用什么开发模式，具体的开发工作总得从一个一个的软件单元做起，软件单元只有经过集成才能形成一个有机的整体。具体的集成过程可能是显性的也可能是隐性的。只要有集成，总是会出现一些常见问题，工程实践中，几乎不存在软件单元组装过程中不出任何问题的情况。从图1可以看出，集成测试需要花费的时间远远超过单元测试，直接从单元测试过渡到系统测试是极不妥当的做法。 

      集成测试的必要性还在于一些模块虽然能够单独地工作，但并不能保证连接起来也能正常工作。程序在某些局部反映不出来的问题，有可能在全局上会暴露出来，影响功能的实现。此外，在某些开发模式中，如迭代式开发，设计和实现是迭代进行的。在这种情况下，集成测试的意义还在于它能间接地验证概要设计是否具有可行性。 

      集成测试的目的是确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确。它所测试的内容包括单元间的接口以及集成后的功能。使用黑盒测试方法测试集成的功能。并且对以前的集成进行回归测试。