芯片验证漫游指南6验证的结构

1 测试平台概述

测试平台（testbench）是整个验证系统的总称，包括验证结构中的各组件、组件之间的连接关系、测试平台的配置和控制；从更系统的意义来讲，还包括编译仿真的流程、结果分析报告和覆盖率检查等。狭义上我们主要关注验证平台的结构和组件，它们产生设计所需的各种输入，并在此基础上进行设计功能的检查。我们首先给出经典的测试平台结构，如图6.1所示。可以看到：

• 各个组件之间是相互独立的；
• 验证组件与设计之间需要连接；
• 验证组件之间需要进行通信；
• 验证环境需要时钟和复位信号的驱动。

从实现语言看，验证平台经过多年的需求变化，常用的语言有VHDL、Verilog、Open Vera、e、System C、C/C++、SystemVerilog等。测试平台对不同语言的使用趋势可以从图3.5看到，近年来SystemVerilog的使用比例明显占据主导地位，我们会在日后的SystemVerilog部分介绍它的主要特性，通过对比不同的语言，体现它在验证领域的优势。此外，对 SystemC 和C/C++在验证部分的应用，我们也会在验证方法的高级应用部分进行介绍。对于验证师而言，构建一个验证平台，除了对设计有充分了解之外，还要考虑在平台上给出更丰富完备的测试场景，并使验证组件针对丰富的激励可以做出细致的判断，最终分析设计的功能是否符合硬件描述。

接下来，我们将围绕设计实例MCDF进行介绍，包括它的结构、功能、时序描述。作为验证工作展开的第一步，我们有理由相信只有对设计结构足够了解，才能进行验证结构的规划和搭建。

2 硬件设计描述

为了模拟实际情景，我们给出贯穿于SystemVerilog和UVM章节的硬件设计MCDF，并且遵循硬件设计描述的方式，介绍它的结构、功能、寄存器和时序。在以后的 SV 和 UVM部分中，我们也将围绕这个硬件设计来考虑测试平台的构成。日后对测试平台的构建论述，需要经常引用MCDF的功能描述，请读者注意这一点。同时，熟悉硬件描述的方式是进入验证领域的一项基本技能。那么，我们就从这个规模适中的设计开始了解。

2.1 功能描述

我们称该设计为多通道数据整形器（MCDF,Multi-Channel Data Formatter），它可以将多个通道的上行 uplink）数据经过内部的FIFO以数据包（data packet）的形式送出。上行数据和下行数据的接口协议不同，我们将在后面的接口描述和时序部分进一步讲解。多通道数据整形器有寄存器的读写接口，可以支持更多的控制功能。

2.2 设计结构

图6.2所示为MCDF的设计结构，主要分为如下几部分：

• 上行数据的通道从端（Channel Slave）：负责接收上行数据，并存储到其FIFO中。
• 仲裁器（Arbiter）：选择从不同的 FIFO 中读取数据，将数据进一步传送至整形器（Formatter）。
• 整形器（Formatter）：将数据按照一定的接口时序送至下行接收端。
• 控制寄存器（Control Registers）：有专用的寄存器读写接口，负责接收命令并修改MCDF的功能。

2.3 接口描述

1.系统信号接口

• CLK（0）：时钟信号。
• RSTN（0）：复位信号，低位有效。

2.通道从端接口

• CHx_DATA（31:0）：通道数据输入。
• CHx_VALID（0）：通道数据有效标志信号，高位有效。
• CHx_READY（0）：通道数据接收信号，高位表示接收成功。

3.整形器接口

• FMT_CHID（1:0）：整形数据包的通道ID号。
• FMT_LENGTH（4:0）：整形数据包长度信号。
• FMT_REQ（0）：整形数据包发送请求。
• FMT_GRANT（0）：整形数据包被允许发送的接收标识。
• FMT_DATA（31:0）：数据输出端口。
• FMT_START（0）：数据包起始标识。
• FMT_END（0）：数据包结束标识。

4.控制寄存器接口

• CMD（1:0）：寄存器读写命令。
• CMD_ADDR（7:0）：寄存器地址。
• CMD_DATA_IN（31:0）：寄存器写入数据。
• CMD_DATA_OUT（31:0）：寄存器读出数据。

2.4 接口时序

通道从端接口时序见图6.3。当valid为高时，表示写入数据。该时钟周期ready为高，表示已经将数据写入；该时钟周期ready为低，需等到ready为高的时钟周期才可以将数据写入。

整形器接口时序见图6.4。整形器是按照数据包的形式发送数据的，数据包的可选长度有4、8、16和32。整形器必须完整发送某一个通道的数据包后，才可以转而准备发送下一个数据包，在发送数据包期间，fmt_chid和fmt_length应保持不变，直到数据包发送完毕。

整形器准备发送数据包时，首先应该将fmt_req置为高，同时等待接收端的fmt_grant。当fmt_grant变为高时，应在下一个周期将fmt_req置为低。fmt_start也必须在接收到fmt_grant高有效的下一个时钟被置为高，且维持一个时钟周期。在fmt_start被置为高有效的同一个周期，数据开始传送，数据之间不允许有空闲周期，即应连续发送数据，直到发送完最后一个数据，fmt_end也应被置为高并保持一个时钟周期。

相邻数据包之间应至少有一个时钟周期的空闲，即fmt_end从高位被拉低以后，至少需经一个时钟周期fmt_req才可以被再次置为高。

控制寄存器接口时序见图6.5。在控制寄存器接口上，需要在每一个时钟解析cmd。当cmd为写指令时，需要把数据cmd_data_in写入到cmd_addr对应的寄存器中；当cmd为读指令时，即需要从 cmd_addr 对应的寄存器中读取数据，并在下一个周期，将数据驱动至cmd_data_out接口。

2.5 寄存器描述

地址0x00 通道1控制寄存器32 bit读写寄存器：

• bit（0）：通道使能信号。1为打开，0为关闭。复位值为1。
• bit（2:1）：优先级。0为最高，3为最低。复位值为3。
• bit（5:3）：数据包长度，解码对应表为，0对应长度4,1对应长度8,2对应长度16,3对应长度32，其他数值（4～7）均暂时对应长度32。复位值为0。
• bit（31:6）：保留位，无法写入。复位值为0。

地址0x04通道2控制寄存器32 bit读写寄存器：同通道1控制寄存器描述。

地址0x08通道3控制寄存器32 bit读写寄存器：同通道1控制寄存器描述。

地址0x10通道1状态寄存器32 bit只读寄存器：

• bit（7:0）：上行数据从端 FIFO 的可写余量，同 FIFO 的数据余量保持同步变化。复位值为FIFO的深度数。
• bit（31:8）：保留位，复位值为0。

地址0x14 通道2状态寄存器32 bit只读寄存器：同通道1状态寄存器描述。

地址0x18 通道3状态寄存器32 bit只读寄存器：同通道1状态寄存器描述。

至此我们将MCDF的功能描述完毕，从下一节开始，我们将分析如何给出激励、检测以及比较数据，同时从验证效率的角度考虑，如何同时为各个模块构建模块验证平台，并最终组合为一个子系统验证平台，来完成MCDF的验证。

3 激励发生器

Stimulator（激励发生器）是验证环境的重要部件，在一些场合中也被称为 driver（驱动器）、BFM（Bus Function Model，总线功能模型）、behavioral（行为模型）或generator（发生器）。激励发生器的主要职责是模拟与DUT相邻设计的接口协议。与真正的相邻设计相比，激励发生器（Simulator）只关注如何模拟接口信号，使其能够以真实的接口协议来发送激励给DUT。激励发生器并不需要模拟相邻设计内部的功能细节，这使得实现一个激励发生器的工作相对设计而言更容易，也更方便维护。

从模拟接口协议的角度来看，激励发生器不应该违反协议，但不拘束于真实的硬件行为，还可以给出更多丰富的协议允许的激励场景。比真实硬件行为更丰富的激励，会使模块级的验证更加充分，因为不但验证了硬件普通的接口协议情景，还模拟出更多复杂的、在更高系统级别无法产生的场景，而这些场景只有在模块级验证中才能产生和检查。这些复杂的边界场景（corner scenario）往往有可能有触发到由于考虑不充分导致的设计缺陷。对于边界情景所触发的设计缺陷，我们一般遵循立即修正的原则，即便该场景可能在系统集成后很难触碰到，但无法保证它在这个项目或下个项目中不会被系统触发。在构建激励发生器时，核心的准备工作就是熟读并正确理解接口协议。如果激励发生器无法完全实现协议，那么可以想象，我们利用激励发生器生成的场景是不完备的，这直接导致接口覆盖率的不完整，存在较大的验证风险隐患。

如果接口协议是成熟的商业协议，建议使用第三方的商用接口IP，这很大程度上节省了二次开发的成本和对激励发生器调校的精力。如果是较复杂的协议，我们可能面对激励发生器协议实现上的缺陷，或者未完全实现协议，而这对验证的成功和效率都有消极的影响。即便出于节约经济成本的考虑，仍然不建议使用不成熟的激励发生器，至少接口的激励发生器应经过足够的时间来开发、自我验证（仍然利用第三方商用接口IP来进行自我验证）。

如果接口协议较为简单，或者是内部设计之间规定的非标准接口，那么应该查阅相邻设计的硬件描述文档，如6.2节中展现的一样，充分理解接口的时序。如果你不幸遇到了一个没有接口时序的设计，恐怕你要与 DUT 和相邻设计的设计者沟通，从他们那里获得相关信息来理解接口协议；这样做也可以帮助双方在项目前期排除有关接口协议的实现分歧。需要注意的是，对接口的理解不能完全遵循设计者的描述，更不能看设计接口的实现代码，因为这违反了设计参照的来源应从系统定义中来的原则。验证者需要做的是调查、收集有用信息，但不完全采纳设计者关于接口的设定。

激励发生器的接口主要是与 DUT 之间的连接，此外，也应该有时钟和复位的输入，确保生成的数据与 DUT 的接口侧是同步的关系。较精细的激励发生器还可以有其他的配置接口用来控制接口的数据生成。最后，激励发生器具有存储接口数据生成历史的功能，用来在仿真运行时或结束后查看接口数据，方便统计和调试。

从激励发生器与 DUT 的连接关系来看，可以将其进一步分为两种：initiator（发起器）和responder（响应器）。就我们要验证的MCDF来看，与下行通道从端（channel slave）的连接或寄存器接口的连接，这两部分的激励发生器都属于initiator，它们的功能是主动发起接口数据传输；而与MCDF formatter接口的连接，该激励发生器则属于responder，它的职责是对接口的数据发送请求做出响应，本身并不主动发送数据。

接下来，我们从MCDF的接口协议和时序分析图6.6中三种激励发生器需要考虑的因素。

1.Channel initiator

• Channel从端接口协议上有握手信号，我们要遵照接口时序，确保chx_ready为低时，chx_data和chx_valid保持不变。
• 相邻数据之间没有数据包的限制，所以相邻数据之间的关系较弱。但也应考虑数据之间是否有空闲周期，以及整体数据的传输速率设定。
• 由于每一个数据从端都有对应的FIFO缓存数据，所以要考虑如何使FIFO的状态可遍历。例如，典型的 FIFO 状态分为 empty、full和中间状态（即有数据存储但未写满）。要使FIFO触发这些状态，就应该控制channel initiator的传输速率。

2.Register initiator

• 寄存器接口上cmd的默认状态应该为idle，但cmd_addr、cmd_data_in并未指出默认值应为何值，所以可以考虑给出随机数值测试DUT的接口协议稳定性。
• 在寄存器读写传输上，可以考虑连续的写、读或读写交叉的方式测试寄存器模块的读写功能。
• 测试应覆盖读写寄存器的所有比特位。
• 需要测试只读状态寄存器的设定是否为不可写入，同时要测试 读出的数值是否为真实的硬件状态。

3.Formatter responder

• 作为三种接口协议中相对复杂的一个，首先要侧重formatter接口协议是否充分遍历。
• 需要详细理解协议的要求，除了按照协议给出fmt_grant的响应以外，还要检查协议的时序。
• fmt_grant的置高，代表formatter的从端有足够的存储空间，可以容纳formatter要传输的长度为fmt_length的数据包。为了模拟真实场景，可以考虑让fmt_grant采取立即拉高或延时拉高，测试formatter接口的响应时序。

至此，我们结合实际的MCDF，给出了激励发生器的连接关系以及实现时要注意的地方，在SystemVerilog和UVM的章节为大家提供可参考的代码实现。接下来，我们将进入Monitor（监测器），看一看如何放置监测器较为合理，它们的优劣势分别是什么？

4 监测器

Monitor（监测器）的主要功能是观察DUT的边界或内部信号，并将它们打包整理再传送给其他验证平台的组件如Checker（比较器）。从监测信号的角度来划分Monitor的功能，可以分为：

• 观察DUT边界信号。对于系统信号如时钟，可以监测其频率变化；对于总线信号，可以监测总线的传输类型和数据内容，以及检查总线时序是否符合协议。
• 观察DUT内部信号。灰盒验证往往需要探视 DUT 内部信号，以指导激励发生器的激励发送，或者完成覆盖率收集，或者完成内部功能的检查。

结合6.3节激励发生器的验证结构图布置，我们有如图6.7和图6.8所示的两种Monitor结构框图。

从图6.7可以看出，在验证平台中置入一个全局性的Monitor，监视整个环境中的信号，包括：

• 寄存器配置接口。
• 3个通道从端数据接口。
• Formatter输出接口。
• MCDF内部信号，包括Register、Arbiter和Formatter的关键信号。

我们再看图6.8中分布式的monitor是如何实现的。可以发现，每一个monitor对应一个激励发生器，所以，我们需要如下的Monitor：

• 3个Channel Monitor分别用来监测对应的channel initiator的接口。
• Register monitor监测寄存器配置接口。
• Formatter monitor监测formatter输出接口。
• MCDF monitor监测register、arbiter和formatter的内部信号。

从功能的角度来看，无论是集为一体的monitor，还是相互分离、各司其职的monitor群，都可以完成监测全局的任务。那么，采用哪种方式好呢？我们试着从如下几个方面进行对比：

• 独立性：我们倾向于采用后者，即将不同接口信号的采集交给相应的 monitor。因为各接口的功能之间没有相关性，易于切割。
• 复用性：仍然采用后者。如果 MCDF 的接口可能运用到别的验证环境中，那么相对独立的 monitor 可以更好地作为验证 IP 被其他验证环境所复用。基于这个考虑，我们将通道从端数据接口的采集分别对应到3个channel monitor，每一个monitor只需要负责监视一组总线。
• 可维护性：后者优于前者。设计的外部接口必定先于内部信号趋于稳定，那么，平行的 monitor 组更有利于验证者在验证后期定向维护 MCDF monitor，而不需考虑其他monitor。同样到了后期项目或者设计遇到修改时，更有可能修改的是内部逻辑，而非接口信号；这种情况下也只需更新MCDF monitor，而不必更新其余接口类型的monitor。
• 封装性：后者的优势在于与各激励发生器一一对应，形成验证环境的小单位，这些小单位之间的通信按照统一的方式实现，可以保持各自的独立性。这样，就可以各小单位（即一个激励发生器对应一个 monitor）封装为独立的组件，使其提供激励和监测的功能。

从上面的分析可以得出，无论是 monitor 还是激励发生器，我们都倾向于将验证环境中的组件尽量做到功能单一，而非大而全，这种方式带来的好处，可以在以后的验证环境集成和垂直复用中得到印证。对于monitor的监测功能实现，我们遵循与激励发生器一样的要求，即验证人员应深入理解协议。这样，无论是按照协议采集数据还是检查 DUT 的接口是否按照协议实施，都是必需的。对于监测MCDF内部信号的要求，我们给出如下建议：

• 若无特殊需要，应采取灰盒（而非白盒）验证的策略。
• 观察的内部信号应尽量少，且应是表示状态的信号。不建议采集中间变量信号的原因在于，这些信号的时序、逻辑甚至留存性都不稳定，这种不稳定对验证环境的收敛是有害的。
• 能够通过接口信息计算的，尽量少去监测内部信号，因为这种方式有悖于假定设计有缺陷的验证思想。我们观测到的内部信号，有必要在被环境采纳之前确认它们的逻辑正确性，这一要求可以通过动态检查或断言触发的方式来实现。

在数据监测、覆盖率收集、协议检查功能覆盖率驱动验证之外，在高级的验证环境中，monitor也可以通过对覆盖率加以分析，来反馈指导激励发生器的激励数据生成，这种方式称之为功能覆盖率驱动验证（function coverage driven verification）。接下来，我们将介绍验证组件的最后一个成员——checker（比较器），看一看checker的功能和一些需要注意的问题。

5 比较器

无论是从实现难度还是从维护人力上看，checker（比较器）都是最需要时间投入的验证组件。之所以这么说，是因为checker肩负了模拟设计行为和功能检查的任务。更细致地看，checker的功能包括：

• 缓存从各个monitor收集到的数据。
• 将DUT输入接口侧的数据汇集给内置的reference mode（l 参考模型）。reference model在这里扮演了模拟硬件功能的角色，也是需要较多精力维护的部分，因为验证者要在熟悉硬件功能的情况下实现该模型，同时不参考真实硬件的逻辑。
• 通过数据比较的方法，检查实际收集到的DUT输出端接口数据是否与reference model产生的期望数据一致。
• 对于设计内部的关键功能模块，也有相对应的线程进行独立的检查。
• 在检查过程中，可以将检查成功的信息统一纳入到检查报告中，便于仿真后的追溯。

如果检查失败，可以采取暂停仿真同时报告错误信息的方式进行在线调试。

关于checker细分的功能，我们需要记住几个关键词：数据缓存、参考模型和检查报告。我们在后期的代码实例中围绕这几个部分进行梳理。在实际项目中，各种 checker 的实现方式迥异，大致分为两类：

• 线上比较（online check）：在仿真时收集数据和在线比较，并实时报告。
• 线下比较（offline check）：将仿真时收集到的数据记录在文件中，仿真结束后通过脚本或其他手段进行数据比较。

在硬件设计发展初期，DUT的功能较为简单，采取定向测试（directed test）和线下比较的方式就不足为奇了。甚至，验证者没有数据处理脚本或参考模型，进行人为比较（manual check）的古老方式也是存在的。设计的功能愈加复杂，靠验证者每次进行烦琐检查的方式可靠性愈差。于是，我们将checker添加到验证环境中，用它分析DUT的边界激励，理解数据的输入，并按硬件功能来预测输出的数据内容。这种的过程发生在reference model 中，有时我们也将其称为预测predictor。 从 MCDF 的 checker 来看，对于数据的整形（formatter），寄存器模块可以控制数据包的长度，reference model也需要register monitor的观察数值进行数据包内容的预测。一般而言，reference model会内置一些缓存，分别存放从DUT输入端观察到的数据，以及经过功能转换的数据。同时，checker也有其他缓存来存放从输出端采集到的数据，即图6.9由formatter monitor存放到MCDF checker的formatter FIFO。

由于 MCDF 有数据通路的功能，我们认为 reference model 存储的数据内容顺序和formatter FIFO中数据的顺序是一致的。这种顺序一致性有利于我们做前后的数据比较，一旦data checker发现两者的FIFO都有数据，就从两侧读出等量数据来做比较。如果数据比较成功，则将数据信息和比较信息打印到仿真窗口和记录文件中；如果数据比较失败，则暂停仿真，将比较失败的数据信息提供给验证人员。

在前面介绍的reference model、formatter FIFO（output data buffer）和data checker之外，我们考虑引入更多细致的检查功能，这些功能和各个模块相对应，分别是：

• channel checker；
• arbiter checker；
• register checker；
• formatter checker。

回顾上一节讲到的monitor的分布不难发现，checker、monitor和stimulator与MCDF内部的各模块有一一对应的关系。我们之前建议将monitor和stimulator各自对应组成一个个的小单元，那么 checker是否也适合与其对应呢？应该怎么放置呢？在回答这些问题之前不妨考虑一下，对checker进行分散搁置与集群搁置的特点是什么？

分散搁置的特点包括：

• 各自检查对应模块的功能；
• checker之间通信需要特殊连接；
• 报告信息较难统一；
• 对各个checker的使能控制因其分散变得复杂。

集群搁置的特点包括：

• 各自检查对应模块的功能；
• checker各自相邻，可以共享monitor的输入，减少复杂的连接关系；
• 可以按照统一的报告形式，写入记录文件中；
• 集中管理各个checker，例如在前期使能各个模块的checker，在后期可以将其作为黑盒验证，只使能data checker。

对于复杂的系统验证，我们倾向于集中管理stimulator和checker，因为它们都需要主动给出激励或判断结果，需要较多的协调处理。Monitor 则相对独立，它只是作为监测方，将自己兢兢业业观察到的数据一字不落地交给checker即可；至于checker怎么使用这些数据，monitor并不需要关心。我们接下来将再次分析DUT MCDF的结构，以及一个项目如何高效地完成实际的验证工作。这其中涉及验证师之间如何协作、验证进度与设计进度的关系。你也可以放开思路，考虑如果自己负责这个设计时将会如何展开验证工作。

6 验证结构

本节将模拟实际的工作，抛出一系列的问题，启迪你的思考。这里给出的建议不是最好的，但至少从工程项目的观点来看是合理的。如果你有更棒的主意，欢迎在路科验证的微信订阅号留言。

6.1 项目背景

现在，你是这个设计模块的负责人，需要考虑分配设计人员和验证人员。而笔者作为验证的老司机，对下面这些模块的实现难度做出了评估。

对MCDF设计的评估：

• channel slave（slave interface+FIFO）需要7个工作日；
• arbiter 需要10个工作日；
• formatter 需要5个工作日；
• registers 需要4个工作日；
• MCDF integration（模块集成）需要2个工作日。

目前共有3位设计师：肖、吕、高，你需要安排他们在最短的时间内完成设计工作。你考虑的人力安排是什么呢？由于MCDF模块之间有独立性，我们可以同时安排3名设计师展开工作。一种较为合理的建议 是：

• 肖：channel slave 7天+MCDF integration 2天=9天；
• 吕：arbiter 10天=10天；
• 高：formatter 5天+registers 4天=9天。

从设计完成的周期来看，一共需要10天（取设计者所用的最长时间）。那么，针对这份设计的进度安排，你又该怎么安排验证工作呢？

6.2 MCDF验证进度安排

在开展验证之前，首先恭喜你，运气还不错，你被分配了4位验证师：梅、尤、娄、董，比设计师还多呢。是啊，作为你的项目经理，笔者也知道验证的工作量要更重一些。那么，如果按照简单的人力比例，即验证人力与设计人力之比大致为1.5∶1的话，上述各个模块的验证人力需求大致如下：

• channel slave:11个工作日；
• arbiter:15个工作日；
• formatter:8个工作日；
• registers:6个工作日；
• MCDF integration的验证人力有待商榷，因为它不单单需要2×1.5个工作日，而是在MCDF集成以后，还需要各个模块在子系统完成集成验证。我们暂时按照30个工作日计算。

接下来，如果将验证师按照上述的人力估计进行分配，就更加有趣了，我们来看一看只有三名设计师，意味着在formatter完成的前5天，我们只有3个模块在设计中。接下来，我们可以等待设计师高将registers模块完成，再递交给相应的验证师。这些计划都是按照天数计算的，我们将这个时间进度表绘制成图，如图6.10所示。

我们来分析一下这张项目计划表：

• 从设计人力利用上来看，尽力做到了从各个模块设计开始到交付用了最短的时间。
• 从验证一侧看，验证师梅、尤、娄的验证开展时间要略晚于设计部分。这是因为只有在设计的边界和功能有初步版本时，验证才可以开始进入。
• 在验证师梅、尤、娄开始搭建验证环境的过程中，验证师董看似没有事情可以安排，因为设计师高的另外一个设计register还没有开始准备，那么验证师需要等待吗？相信我，验证师一旦闲置下来，在任何一个项目中都会引起项目经理的疑问。验证师董可以在其余三位验证师搭建模块验证环境一段时间以后着手准备顶层验证环境。
• 完成初步验证环境集成后，验证师董可以在适当的时间开始验证模块 register。在完成模块验证后，验证师董可以进行最后阶段的验证环境持续集成。
• 在验证师董进行验证环境的持续集成前后，验证师梅、尤、娄可以在完成模块验证之后进入顶层验证，检查各自的模块是否工作，而所用到的checker均来自于他们的模块验证环境。同时，验证师董也应该进行最后的顶层验证，检查模块register的功能。
• 最后值得注意的是，MCDF作为一个整体子系统，我们不能忽视各个模块的协调使用。这项工作我们交给验证师娄，因为他还有一定的时间来完成这项任务。完成 MCDF整体验证的任务包括协调stimulator和checker 来创建激励场景和检查数据。数据检查用到的reference model、formatter FIFO和data checker需要由验证师娄来实现。

在项目执行部分，我们围绕4位验证师如何从模块级验证环境开始搭建到顶层环境的集成。接下来SystemVerilog基础和应用部分将讲述这些内容，而MCDF模块的设计源代码，读者可以通过扫描二维码下载。从第7章开始，我们将进入SystemVerilog语言的基础部分，笔者将提炼语言的重要特性，同时结合实际应用，将SystemVerilog语言在验证环境中所需的知识点展示出来。也请读者在接下来的SV语言和UVM方法学中理解本书的指导方法，即，语言知识点为辅助，项目实际应用和思想为我们贯穿全书的核心基调。

7 作者结束语

无论接下来是学习SV还是学习UVM，在展开验证之前都需要仔细阅读硬件的设计描述，并要考虑验证结构的实施。对于子系统级别，还需要考虑如何划分模块和对应的模块验证环境，然后考虑如何复用模块验证环境，最终在子系统级别完成验证环境的集成和复用。

在动态仿真领域，读者需要了解的是，无论什么验证语言或方法学，都需要有激励发生器、监测器和比较器，也都需要有顶层的验证环境来封装它们。对于小组规模的验证场景，验证师之间还需要考虑整体验证进度的平稳推进、验证环境的统一化和系统层面的验证协作等。