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

在工作日里，如果你问验证工程师在干嘛，多半时间他/她会告诉你在Debug。换句话说，一般在验证周期内，工程师有超过一半的时间都消耗在了功能调试上，尽管这里面包含了验证工程师跟自己“作对”的时间，即验证环境或者测试用例本身存在bug。所以，调试这项工作还是很重要的！

调试这项工作除了要求工程师对设计规范（Specification）、DUT（Design Under Test）、测试环境（testbench）结构和用例（test case）的测试意图有一定的了解，掌握必要的工具、方法和技巧也十分重要，它能够帮助工程师获得更多有效的信息，加速问题定位，提高工作效率。

Debug这一主题被拆成了两篇文章，第一篇《SystemVerilog | 这些Debug调试方法你都知道吗？| Part I》主要介绍的是一些基础和常用的调试方法，而Part II将紧接着介绍其他一些工具、方法和想法。

方法4：可视化调试

可视化调试主要分为Post-process和Interactive这两种模式。可视化调试工具是工程师在定位代码问题时的有力工具，也是现在验证工程师主流的调试工具。工具的使用一般可以参考官方的用户手册（User Guide），也能够在官网上找到相应的培训链接和视频。

常用的可视化调试工具有Synopsys家的Verdi，Siemens家的Visualizer，还有Cadence家的SimVision。对于个人用户来说，可能没有办法去实操体验，但通常所在公司会购买至少一家的License。三家公司的工具的操作流程和基础调试功能都差不多，然后又分别有自己调试的独特功能。

先介绍下后处理调试模式（post-process，即在仿真结束之后再去可视化和处理仿真结果，有些地方会叫做PPE，post-processing environment）的使用，因为这种方式在实际工作中用的比较多。在使用可视化调试工具之前，通常需要将testbench和RTL编译到同一个数据库中，该数据库包含了文件信息、RTL例化层次信息、信号连接关系等等，以供调试工具的追踪和分析。

如果使用Verdi工具，需要使用VCS在编译（Compilation=Analysis+Elaboration）的时候，通过加参数-kdb -lca来生成KDB库（Knowledge Database），其中lca（Limited Customer Availability Features）参数是为了指定工具特性。KDB数据库格式是Verdi专用的格式，所以KDB库有时候也可以叫Verdi库。打开verdi的时候使用命令verdi加参数-elab来选择该KDB库。

如果使用Visualizer工具，需要使用Questa/ModelSim在对设计完成编译（vlog/vcom）之后，使用vopt命令加参数-debug -designfile design.bin来生成.bin文件，同样该文件格式是Visualizer专用的。打开Visualizer的时候使用命令visualizer加参数-designfile来选择该bin文件，使用参数-wavefile来选择db波形文件。

如果使用SimVision工具，需要在仿真阶段使用NC仿真器或者XCelium仿真器（具有更高的仿真性能，比如支持多核等）将设计和波形都导出成shm格式。在仿真结束之后，你可以看到名为example.shm的目录，该目录下会有两个文件：.dsn文件和.trn文件，前者包含的是设计的信息（类似于我们上面说的数据库），后者包含的是波形信息。打开SimVision的时候使用命令simvision直接加example.shm来打开待调试的数据库。

再看看交互模式（interactive mode），交互模式相对于后处理模式增加了仿真控制的功能，即可以设置仿真断点、控制仿真的暂停、运行和重启等，并实时地观察到信号的行为。交互模式下，上述EDA工具的界面上会多出来一些调试控件。不过这种模式的仿真运行速度比较慢，且在分发和重现代码行为上不是很友好，所以在实际工作中也用的比较少，除非遇到非常棘手但却摸不着头脑的问题。以上提到的几家工具都支持交互模式调试，操作流程也都差不多，并且跟后处理模式一样也需要先编译出来一个数据库。

如果使用Synopsys家的工具，在设置完必要的环境变量之后，比如VCS_HOME和VERDI_HOME，需要使用VCS命令vcs -kdb -lca -debug_access+all 编译出KDB库和simv可执行的仿真文件，然后在执行simv的时候加上参数-verdi就可以打开交互模式下的Verdi了，这个时候调试器和仿真器是关联起来的。

如果使用Siemens家的工具，同样在设置完必要的环境变量并使用命令vopt编译出design.bin文件之后，可以使用命令vsim -visualizer=design.bin -qwavedb=+signal+class -f 打开交互模式下的Visualizer，便可以在调试工具界面去控制仿真器。

如果使用Cadence家的工具，那就相对复杂一点，因为Cadence前前后后有几个仿真器，比如verilog、ncsim、irun，并且进交互调试模式的方法也比较多样，但大致可以分两种：一种是可以通过参数-gui直接开启带SimVision的仿真器，另一种方式是单独启动SimVision，使用参数-connect host/pid连接到运行在本地或者远端的仿真上。

以上命令只是展示大概的使用过程，实际应以对应版本的用户手册为准哈。当你打开可视化调试工具调试界面之后，有这么几种常用的调试功能：

1. 通过Hierarchy等窗口浏览源代码的例化层次结构，类继承关系等；
2. 通过查找Driver和Load来定位信号的传播通路（这个是用的最多的）；
3. 通过Filter来分类查看当前文件包含的输入输出信号、参数、变量等；
4. 通过查找来定位某一个module例化出来的所有模块；
5. 原理图和状态机跳转图可以有限地帮助你理解代码行为；
6. 配合波形文件查看各种信号随时间变化的行为；
7. 调试工具的功能还有很多，具体可以查看各个工具的官方介绍和培训视频。

方法5：SVA断言在调试中的应用

**概述：**SystemVerilog Assertion（断言）主要用于验证设计的行为，并且可以提供功能覆盖率信息。Assertion可以应用于两种不同的验证方法中，一种是在动态仿真中去动态地检查各个既定属性（property）是否满足，另一种测试用于Formal验证工具去证明设计是否符合规范。

**作用：**如果你刚接触，可以把断言简单理解成checker或者monitor，它指的是在设计中嵌入一些工程师根据待测特性自行定义的一些属性，仿真的时候仿真工具会去判断这些属性是否成立，以此来判断某个特性是否实现正确。SVA在本文中作为调试的方法来介绍，就是因为断言可以帮助我们监测属性，为我们报出来哪些时刻行为正常、哪些时刻行为异常，且这些行为可以是有时序的！

**分类：**在SystemVerilog中，断言大致可以分为两类：立即断言（immediate assertion）和并发断言（concurrent assertion）。立即断言是基于仿真事件（simulation event）的，当它被执行到的时候就会立即对多定义的属性做出判断并给出结果；而并发断言是基于时钟的，断言的评估（evaluate）发生在时钟边沿，这也使得并发断言具有监测的能力，这也是下面要主要介绍的。

**结构：**断言的具体实现依赖于更基础的元素，比如sequence和property。Sequence是最底层的元素，它可以复用和嵌套。Sequence可以用来定义简单的布尔表达式，也可以用来描述多周期的时序行为。Property则可以实现跟sequence一样的内容，也可以通过组合不同的sequence来构造更加复杂的时序行为。为了规范化，建议将嵌入的时钟信号@(posedge clk)放在property这一层，而将sequence跟时钟独立开来，方便基础sequence的复用。

**调度：**SystemVerilog的仿真基于事件驱动模型，事件的调度机制在SV语言标准中有明确说明。该调度机制将每个仿真时刻（time slot）再划分成多个region，如下图所示，每个region都有自己明确的操作。仿真调度算法的确定，可以使得仿真环境跟DUT交互时显示出同步的效果。其中跟SVA相关的region有Preponed、Observed和Reactive。在Preponed中，SVA会对有关联的变量完成采样；在Observed中，多有的property完成评估，即判断断言描述是否成立；在Reactive中，执行断言评估结果需要采取的对应的操作。

**应用：**断言的应用主要可以分成四个步骤：1、构造基础布尔表达式；2、构造sequence序列；3、构造断言属性property；4、将属性代码插入或绑定（bind）到待测模块中。SVA提供了一些好用又强大的功能：判断信号边沿和状态、添加延时来构造信号时序行为、支持构造不定周期的时序窗口、判断过去的信号状态、支持断言的逻辑运算等等，本文篇幅显然是不够的了。

方法6：软件调试方法的借鉴和应用

这一节的内容更像是讨论，有哪些软件开发中用到的调试方法，或者问题定位策略是可以借鉴过来应用到芯片验证中的。

有个前提需要明确的是，硬件仿真始终是基于事件驱动的程序执行过程，尽管仿真调度机制简洁明了，但往往待测设计规模庞大（具体表现为硬件行为具备并行性质，一个时钟信号的翻转事件关联着成千上万的信号动作），所以硬件仿真的运行速度会非常的慢，这是跟单纯软件程序的一个显著区别。

运行速度上的差异带来了调试方法上的一些不同。软件调试中交互式的操作非常多，比如解释执行的脚本（比如Python）不需要编译就可以马上得到执行的结果，又比如基于断点的调试可以非常容易地检查变量值和堆栈跟踪。反观硬件调试，工程师很难快速地知道在哪里设置断点，往往需要反复的尝试，这会浪费掉很多时间。因此硬件的调试更多依赖于信息的导出，其形式通常是仿真日志和波形文件。

如何提高硬件调试的交互性可能是软件调试带来的启示，有这么一些不成熟的想法，比如是否可以增加调试信息（代码、波形和仿真日志）之间的关联，实现自动化跳转；是否可以增加工具对代码的理解或者记录调试过程来进行自动化分析；是否可以在增量编译的概念上实现增量仿真；等等等等。