这些Debug调试方法你知道多少？（下篇）

调试（Debug），是个非常广泛的话题，让我先尝试给它下个定义：

调试指的是在遇到工程问题的时候，通过一些手段来进一步诊断问题原因，探索解决方法，最终使得系统功能正常运行的必要过程。

调试应该说是任何一个工程师解决问题的必备技能，对于芯片验证工程师来说更是如此。调试通常没有固定的章法，不可能按照某一个流程步骤就可以解决所有的工程问题，毕竟在实际环境中遇到的问题千差万别，可能只是你的某一个命令参数敲错了，可能是RTL逻辑设计上存在bug，也可能是设计规格（Specification）本身就存在纰漏，等等等等。

尽管调试方法不固定，但调试思想还是很一致的，那就是：尽可能的获取更多的有效信息，并对这些信息做综合分析。你细品，比如最常用的导出仿真日志（log）或者波形文件，这些方法本身就是为了获取更多的有效信息，这些信息能够帮助我们更好地去了解现在RTL的功能行为，帮助我们进一步对问题进行定位。

回到本文主题，本文要介绍的内容就是调试过程中常用的方法和技巧，这些方法的合理应用可以获得上面说的有效信息，从而提高我们解决问题的效率。而至于如何做信息的综合分析，需要根据具体场景和经验才能完成。

方法1：文件和参数索引的建立

之所以把建立文件和参数的索引也说成是调试方法，是因为在面对一个组件繁杂的验证环境，或者规模庞大的设计的时候，能够快速地检查相对应特性的规格文件、配置文件、宏定义、类型定义、参数配置、类原型、函数原型等信息，极有可能就可以解决掉一些低级的错误了。

要快速地找到这些有效信息，一方面依赖于工程师对当前验证环境和设计配置文件的熟悉程度，另一方面可以借助一些工具来找到它们。后者就是本节所要介绍的内容，下面就直接罗列我工作中最常用的一些工具和命令。

• 使用ctags扫描工作目录，建立基于语法元素的索引，配合Vim可以实现语法元素的快速跳转。
• 使用meld工具比对目录或者文件在不同版本之间的差异，功能比gvimdiff强那么一些。
• Windows下使用Listary或者Everything软件来快速查找本地文件，可以参考《芯片工程师必备软件神器》。
• Linux下使用grep命令来筛查文件内容，配合管道符“|”可以实现更多级的筛查。
• 掌握一两门脚本，Python、Perl、Shell等都可以，掌握正则表达式，随手就可以实现一些小功能。

以上提到的工具和命令，都可以在网上找到大量的教程。如果有时间，我再写一些小的使用Tip放到公众号上。

方法2：波形的导出和使用

通过波形可以很直观地看到RTL随时间变化的所有行为细节，尽管拉波形看信号变化看多了容易眼睛瞎掉，但不得不承认大多数情况下没有波形的话问题定位会变得寸步难行。波形文件是仿真过程的副产物，它按照一定的格式将每个仿真事件发生时刻的信号和变量状态记录下来，并最终以图形化的方式呈现出来。

波形文件的格式很多，比如VCD、FSDB、VPD、WLF等等。

• VCD格式应该说是最通用的波形格式，它是SV标准中定义的一种ASCII文件格式，其全称是Value Change Dump。VCD包含了所有信号的变化信息，它可以被任何EDA调试工具打开。VCD文件可以在testbench中使用SV的内建任务$dumpfile("name.vcd")和$dumpvar()来导出。
• FSDB的全称是Fast Signal Database，它是原来Novas公司（先被Synopsys收购）的工具Verdi专用的波形格式。在testbench中，可以使用Verilog PLI接口（可以像调用内建函数那样去调用C/C++函数）调用$fsdbDumpfile("name.fsdb")和$fsdbDumpvars(0, top)去导出。注意，要用着两个函数需要将Verdi安装目录中share/PLI下的相关库添加到动态链接库路径（$LD_LIBRARY_PATH）中，或者有参数（比如Mentor工具用的-pli）去指定PLI库的路径。
• VPD是Synopsys自家定义的波形压缩格式，叫VCD Plus（这个plus是不是有点似曾相识的感觉），在使用Synopsys VCS工具仿真时可以导出VPD波形，同时也可以使用使用配套的波形浏览器DVE（Discovery Visual Environment）去打开波形。VPD波形可以在testbench中使用$vcdpluson去导出，在VCS做编译和仿真的时候需要指定debug能力，比如加参数-debug_all。
• WLF的名字就比较单纯，叫Wave Log Format，一看就知道是干啥的。WLF格式是Mentor家（现在属于SIEMENS）定义的，可以由QuestaSim或者ModelSim仿真工具可以生成和加载。如果你用ModelSim做过实验，当你打开波形界面，它会在工作目录下自动生成一个WLF文件。另外Mentor的工具还可以使用命令选项-qwavedb并附加一串选项，可以在仿真过程中生成仿真数据库文件（simulation database），该文件以.db为后缀，可以当成仿真波形被Visualizer调试工具打开。

以上提到的函数调用在参数上具有很大灵活性，可以指定具体要dump波形的RTL层级、scope范围甚至指定哪些信号。此外还有其他函数可以用来限制波形文件大小、波形dump开关、导出Memory数据等等。

尽管不同格式的波形文件有以上差异，但在应用的时候大部分情况下取决于你有什么EDA工具可以用，另一方面这些波形格式也有工具可以相互转化。

仿真波形在使用的时候通常有一些技巧，方便问题的定位和重现，下面列举几个常用的：

• 将功能相关的信号分组（group）放在一起，方便做逻辑或协议检查；
• 可以将多个信号组合成总线信号，或者进行自定义的逻辑运算；
• 为被关注的仿真时刻添加标签（Mark），方便来回观看；
• 通过添加标尺可以查看信号事件间距、周期信号频率、统计信号事件等功能；
• 将常用的状态信号、总线信号、某个用例调试用的信号等保存成do文件，即将当前波形界面的元素保存下来，方便波形重现；
• 每个人看波形的习惯和方式会有不同，找到自己习惯的方式就可以了；

方法3：仿真日志的导出和使用

仿真日志（常说的log文件）通常是我们查看仿真结果会首先打开的文件。该文件中可以包含整个仿真过程中由编译器和仿真器打印输出的各种文本信息，比如当前导入了哪些文件、本次编译和仿真分别用到了哪些参数、当前DUT的顶层是哪一层、仿真过程中不同时刻的关键动作和信息、本次仿真的结果和资源开销等等。

基于文本的仿真日志记录和对仿真日志的手动分析看起来是比较低级和低效的，特别是当我们看着仿真日志并顺着时间轴试图去将打印数据和RTL行为关联起来的时候，简直苦不堪言。尽管如此，仿真日志的导出和使用仍然在某些时刻起到了基础性的作用，特别是在UVM将report机制构造健全之后，其作用不可忽视。

SystemVerilog本身在打印信息上有好几个任务可以用：**display, **write, **strobe, **monitor, 这几个任务的使用上不完全相同。

• 最常用的是**display，**display可以用来做格式化输出，格式化方法跟C语言几乎一致，并且打印完成之后会自动换行。
• write则用的不多，它的功能跟display很接近，区别在于在打印完成之后不会添加换行符，所以适用于想要在一行里输出多个信息的场景。
• strobe的打印就比较讲究了，通过strobe打印的变量值是当前仿真时间槽（time slot）中该变量最后的值，比如对变量A做非阻塞赋值（<=）之后跟着用strobe打印变量值，打印出来的是该变量完成赋值之后的值，而如果用display则是打印出来该变量赋值完全之前的值。
• monitor的功能就跟它的名字一样，它相当于是在主线程之外开了一个监控线程。当通过monitor打印的变量或者表达式发生改变时，打印的功能就会被触发，看起来就像是一个有了外部中断能力的$display。

在UVM的框架里，打印信息被赋予了严重性等级（severity）和冗杂等级（verbosity），这在信息控制上提供可很大的便利。

Severity分成了INFO、WARNING、ERROR和FATAL，分别使用宏uvm_info、uvm_warning、uvm_error和uvm_fatal来进行信息打印。

Verbosity等级共分为UVM_NONE、UVM_LOW、UVM_MEDIUM、UVM_HIGH、UVM_FULL、UVM_DEBUG六级，表示信息的冗杂程度由低到高。

• INFO顾名思义就是简单的状态信息打印，这些信息并不是必须的，它的verbosity属性可以通过uvm_info宏的参数来指定。比如当仿真的verbosity设为UVM_DEBUG时，所有uvm_info信息都会被打印出来，仿真日志会显得非常冗杂；当仿真的verbosity设为UVM_NONE的时候，只有UVM_NONE属性的uvm_info信息才会被打印出来，仿真日志就看起来简洁很多。
• WARNING指的是一些警告信息，提示潜在的问题，比如你显式地调用了某个phase，可能不会影响仿真的继续，但可能会让仿真场景不符合预期。WARNING的verbosity默认都是UVM_NONE，因此始终会被打印出来。
• ERROR就是一些错误信息，错误信息的出现不会使得仿真马上停止，UVM给我们提供了阈值设置，当错误信息的数量达到某个值只有仿真就会自己退出。通常UVM_ERROR的信息被打印出来，我们都需要去把它们都解决掉。ERROR的verbosity等级默认都是UVM_NONE，所以也不要想着用verbosity来屏蔽它。
• FATAL就是一些致命的错误，只要一出现仿真就会马上退出，这种问题同样必须解决，不解决你连仿真都跑不完。可想而知，这类信息同样verbosity默认是UVM_NONE，始终会被打印出来。

Verbosity的设置出了直接用仿真参数+UVM_VERBOSITY=UVM_DEBUG来配置，UVM还提供了+uvm_set_verbosity这一非常灵活的参数，具体使用方法这里就不做介绍了。UVM出了这套完备的打印信息控制机制之外，还提供了很多调试宏，比如+UVM_CONFIG_DB_TRACE、+UVM_PHASE_TRACE、+UVM_OBJECTION_TRACE等，用来方便用户从仿真日志中观测配置数据库（configuration database）状态、phase执行状态和objection状态等。

总而言之，信息的打印方法有很多，UVM在report机制上也给到了足够的控制手段，利用好这些方法，仿真日志将是我们调试用例的利器！关于UVM的议题可以介绍的实在太多，有时间再开这一系列的文章。