IC验证培训——验证环境的自动化生成
随着SoC规模不断增大，验证环境也不断变得复杂。例如，如果我们想要验证整个的SoC的总线，DUT可能包含几百个接口，如果我们人工的对各类VIP和DUT进行连接，会非常麻烦，而且易出错。所以验证环境的自动化是大势所趋。因而，在本文我们提出了一个系统的解决方案，提取设计信息，并根据所提取的信息，自动创建验证环境。
本文我们会以总线接口为例，介绍我们的解决方案，以及如何提取信息、如何为单个模块、子系统乃至芯片自动建立总线桥验证环境等关键内容。
I. 方案简介
下图示意了一个典型的SoC总线架构和相应的验证环境。
在SoC中，依据不同的协议（ACE, ACE-Lite, AXI, AHB, APB等）可能会有上百种接口。对于每一个总线接口，验证工程师需要收集以下信息来构建验证环境：
-
VIP接口连接：设计层次和RTL信号名称。
-
VIP配置：该总线接口的功能。
-
VIP激励约束：这种总线接口可以发送的transaction或sequence类型
因此，建立验证环境的挑战，主要来自以下几个方面：
1.VIP接口连接
一个总线接口有许多信号。例如，一个AXI master连接有50多根信号。对于具有数百个接口的设计，就需要连接上千根信号线。
2. VIP配置
VIP有很多变量需要进行配置。例如，我们的AXI VIP master 有超过70个可配置变量。其中，20个变量与设计有关。所以验证工程师需要收集来自设计团队的相应信息。对于有180个接口的设计，就有1800多个变量需要进行配置。
3. VIP激励约束
考虑到时序和面积，总线组件并不总是充分发挥作用。所以验证工程师需要自定义每个VIP的激励。对于master类型的总线接口，验证工程师需要知道什么样的Transaction可以发送。例如，对于只有读信道的AXI master无法发送写操作Transaction。Slave类型的总线接口也应避免接受超出其接收范围的Transaction。
一般而言，所有的信息都需要人工收集，测试平台也要工程师自己编码。设计规范是自动建立验证环境的来源，但是设计规范并不总和RTL的变化完全契合，而且搜集这些信息需要花费大量的时间和精力。此外，还没有任何自检机制。所以，直到仿真失败，你才能发现RTL和设计规范之间并不匹配。一旦RTL发生变化，收集的信息和相应的测试平台也不能再用，就会需要更多的精力去查找和纠正了原先的设计信息。
另一方面，其实很多如上所述的信息可以自动收集。例如，从RTL代码中可以自动提取许多接口信号的可配置变量。有了必要的信息，测试平台也可以自动生成。所以，我们更倾向于从RTL本身提取设计参数，并以此建立自动验证环境。基于此，我们提出了一个系统的解决方案，解决方案大致如下图所示。
我们使用总线接口为例来演示如何提取RTL设计信息。根据我们的观察，在实践中，80％左右的接口信号遵循相同的命名惯例。所以，我们使用模式匹配来提取基于总线协议的信号。对于接口信号外的其他信息，如数据宽度，读/写能力，也可以从RTL提取。
另外，我们提供了一个简便的GUI工具，便于用户审查修订所提取的信息，并输入那些提取不到的信息。此外，用户的输入，会与RTL进行检查比对，以确保它与RTL的一致性，消除人为错误。最后根据手头已有的成熟的验证库，用户可以使用内置的命令自动生成的验证环境。此外，我们还为用户提供了一些API，方便用户定制自己的脚本。
这种解决方案具有以下优点：
-
建立验证环境花费的时间可以从数月减少至数周。
-
确保了VIP与RTL的连接是准确的，由此缓解DV繁琐的调试工作。
-
它是可扩展的。它可以应用于一些标准总线（APB，AHB，AXI等）以及用户自定义的总线。此外，它与VMM和UVM也是可兼容的。
-
验证环境易于移植，无论是从VMM到UVM，还是从一项目到另一个项目。
II. RTL信息提取
这里，我们将介绍如何从RTL设计中提取构建验证环境的信息。设计信息被提取之后，用户就可以验证所提取信息的正确性，并输入GUI上缺少的信息。然后，设计信息会与RTL进行检查比对，以确保它与RTL的一致性。为了进一步减少用户的精力，某些以前的设计的信息可重复使用。
A.信息提取
1）配置-总线定义
为了提取总线接口，我们首先应该知道这个总线的定义。用户应该提供一个配置文件解释总线接口。通常，配置文件包含以下信息：总线协议（例如，AXI）、类型（master或slave）、协议信号名称等。使用这种方式，我们不仅可以提取标准总线接口信息，也可以提取用户自定义接口信息。对于标准总线接口（例如，AHB，APB，AXI），为避免用户的麻烦，我们预先准备了配置文件。对于用户自定义的接口，用户需要依据标准接口配置文件为模板，准备自己的配置文件。表1列出了一个APB总线配置的例子。注意最后一列标出的“seed”，表示在提取过程中，seed信号将作为模板用于名称模式匹配。
2）总线接口提取
有了总线协议配置，我们就能够从RTL提取总线接口。有几种方法完成提取。一种方法是提取所有的接口信号，然后根据命名模式对其进行分组。然而，这种方法会产生许多不属于任何总线接口的附带信号。另一种方法会更好一点，用户可以在配置文件中指定在一个或几个“种子（seed）”的信号。种子信号是协议中的一些强制性信号，而且很可能会与其它信号有相同的命名规定。它将作为模板用于名称模式匹配。在我们的实现中，地址信号（例如，表I所示APB的“PADDR”）总是被选择作为种子信号，用户不必担心如何选择种子信号。
一旦种子信号被指定，其命名模式（例如前缀和后缀）作为第一匹配点，用于在相同的总线协议中匹配查找其他信号。使用这种方法，我们能够从任何感兴趣的实例的RTL中提取总线接口。
除了接口信号，其它信息也可从RTL中提取，一旦从某一实例中提取一个总线接口，它的信息（如地址宽度、数据宽度和读/写能力等）也可以从RTL被提取出来。例如，总线接口提取后，如果在一个实例中发现有一个AHB接口存在，它的地址宽度可由连接到“HADDR”的端口的宽度得到；其数据宽度可以由连接到“HRDATA”或“HWDATA”的端口的宽度来得到 ；读/写能力，可以通过此接口是否有读或写信号来决定。这些信息决定了VIP agent处理transactions的能力。另外，这些信息也可由用户通过配置文件来确定。
提取后，所有的信息都保存下来，包括相应的RTL层次。这些信息将在GUI上被显示，如图3所示。该GUI有两个面板。左侧面板显示设计的层次结构，右侧面板显示与所选择的总线信息接口相关的信息。由于相同的层次结构下可以有多个接口，所以右侧面板上会有好几个标签，每个接口对应一个标签。
B.手动补充信息
为了能够从RTL提取完整的接口信息，接口上的所有信号应遵循相同的命名约定（即用相同的前缀和后缀）。不幸的是，实际项目并非总是如此。根据经验，接口信号中约80％遵循相同的命名规则，因此能够从RTL被提取。也就是说，绑定VIP时，80％手动工作的可以省下来了。同时，还有剩余的20％的接口信号信息必须由用户手动输入。
例如，一般来讲，时钟和复位信号与其他信号不遵循相同的命名规则。所以，用户必须手动提供时钟和复位信号，从而提供完整的接口信息。至于已成功提取的信息，也不能保证是完全正确的。因此，在生成验证环境之前，至关重要的是，用户要可以查看和修改所提取的信息，并输入那些不能被自动提取的信息。通过GUI工具，用户能够通过它的层次结构来跟踪一个实例，审查和修改所提取的信息，输入丢失的信息。
C.与RTL的相关性
为确保所获得的信息与RTL的一致性，我们开发了自动检查功能。检查结果将自动备注到GUI里。从而用户可以再来检查这个信息是否正确。从而减轻工程师繁琐的调试工作。这种检查机制的另一个好处：它可以使获取的设计信息跟得上RTL的变化。一旦RTL改变时，设计层次结构可能被改变，并且总线接口也可能和原来的不同。这时，用户需要重新检查信息，以确保其正确性。手动检查无疑是痛苦又耗时的事情。而在我们的项目中，原始信息将针对新的RTL进行检查。一旦有发现错误，将提示用户进行相应的修订。
D.和设计规范的相关性
除了RTL，也可以对获取的设计信息和一些设计规范之间进行检查比对。例如，如果我们有一个存储器映射（见后文表II所示）表示相应实例的总线接口，我们可以对内存映射和提取的总线接口之间进行交叉检查。具体来说，我们可以检查存储器映射的层次信息是否正确，各类总线接口与获得的设计信息是否匹配等。以这种方式，我们能够实现RTL、设计规范和所获取的设计信息的一致性。这对于构建验证环境很有帮助。
III. 用于独立模块的验证环境
对于模块级验证，设计相对比较简单，上述流程可以简化为一个按钮式的解决方案。具体上讲，就是信息提取后立即产生测试平台。用户当然也可以查看和修改直接生成的测试平台。
以总线桥型设计为例。基于从RTL中提取的信息，我们可以知道每个接口的总线协议，并据此配置相应的VIP。以图4 为例，我们设置这样一个典型的验证环境，这个环境包括DUT实例、VIP接口连接、VIP、激励和检查机制等。因此，基于UVM方法将生成以下模板。如果有必要，用户也可以基于这些模板做进一步的定制。
-
包含DUT实例、VIP接口连接、VIP agent实例以及VIP配置的testbench顶层文件。
-
默认的scoreboard连接。
-
transaction约束模板文件。
-
基于总线功能的功能覆盖定义。
-
运行模拟仿真的脚本文件。
环境建成后，模拟仿真之前，用户还需要做到以下几点：
-
必要时调整一些信号的连接。
-
添加一些VIP的约束限制。
-
修改默认的VIP配置。
然后，简单使用makefile，用户可以运行测试平台，并得到了仿真结果了。
以图3总线接口为例。将产生如图5所示的测试平台顶级文件。图6所示为接口连接“user_interface.svi”，类似地，也会产生UVM agents, UVM envs, UVM test classes等模板代码。
IV.子系统或者整个芯片的验证环境
对于子系统或芯片级验证，与模块级验证相比，验证环境的结构并没有太大变化。然而，随着设计复杂性显著增加，可能会有数百个总线接口。因此，我们需要更多的信息。例如，为了正确解码地址，我们将需要预定义一个如表II所示的存储器映射表。
在该表中，每个存储器区域使用唯一的名称定义。此外，还需要一些基本信息。这个信息有助于从RTL提取设计信息。例如，总线位置和协议类型可以用来识别RTL的总线接口。每次存储器映射提交后，它与RTL代码以及所需要的设计信息之间的交叉检查就会执行。这可以在早期帮助发现错误，从而减少仿真失败时debug的精力。
有了设计信息和存储器映射表，子系统或整个芯片的测试平台就可以产生了。此外，表Ⅱ中的存储器映射可以转变成可执行的System Verilog代码，用于检查地址译码。
V.总结
在本文中，我们提出的解决方案，系统地提取RTL设计信息，为客户提供一个方便的图形界面，方便检查、修改以及添加提取的信息，并基于所提取的信息生成验证环境。这种方法可用于模块、子系统以及芯片级的设计。使用这种方法，我们建立验证环境的效率大大提高，另外testbench与RTL设计是可以做到同步变化的。我们也在实际项目里，对比了之前方法耗费的时间精力与使用这种自动方法所耗费的时间精力，最终估算，这种自动生成的验证环境大概可以减少我们70%的工作量。
谢谢你对路科验证的关注，也欢迎你分享和转发真正的技术价值，你的支持是我们保持前行的动力。
