当我们验证片上系统(SoC)嵌入了具有多个数字外设的微处理器以及可能的模拟模块时，我们希望检查所有实现的功能和可能的极端情况，以最大限度地缩短验证时间。多种技术和方法的混合用于改进功能验证并提取覆盖等级的度量：基于通用验证方法(UVM)的形式验证和随机约束测试增加了发现错误的可能性。有时我们为RTL验证创建一个完美有效的测试，但发现它不能在门级仿真期间重复使用，因为UVM监视器挂在内部SoC信号上，这些信号在实现阶段后可能会消失或改变。

本文将描述创建有效的自检模型是多么容易，这些测试既简单又可以在门级模拟过程中重复使用。令人惊讶的是，通过改变数据流，我们可以为测试平台带来好处，降低记分板的复杂性，这也意味着更少的测试开发时间。

流程基于实例化UVM验证用于检查接口的组件，例如SPI，I 2 C，＆amp; UART，但它也可以扩展到更复杂的接口。

SoC验证流程

最有效的SoC验证是基于内部总线内部，特定内部模块和主SoC接口上的多个UVM验证组件(UVM VC)的实例化。这些UVM VC用作总线协议检查器(例如，AMBA检查器);串行协议检查器和主动主控器(例如，I 2 C，SPI，UART，JTAG，SATA，PCIe)。

基于UVM开发的测试应该是自检的;必须通过检查器验证每个操作，激励和事务，如果不匹配，会引发一个“标志”，停止模拟并发出模拟器控制台上显示的错误消息并写入日志文件。

通信接口(例如，SPI)的验证需要使用由在总线上获取事务的收集器形成的UVM VC，用于检查协议合规性的监视器以及生成的生成的总线功能模型(BFM)交易。 SoC和外部UVM VC之间交换的数据通过名为记分板的模块进行验证。

此记分板至少有两个端口，其中添加的对象与第二个相匹配 - 参考。如果不匹配，则发出错误。在门级仿真期间必须重复使用这种检查器以刺激关键路径。图1显示了验证测试平台的简单框图，该平台使用多个检查器进行有效的验证方法。

图1：典型的UVM验证测试平台

黄色块是UVM VC。总线监视器是一个只有监视器和检查器的无源组件。

用于测试串行外设的通用数据流是将数据从UVM VC发送到微处理器并检查数据是否有到达目的地(微处理器)。在第二步中，我们将数据从微处理器发送到UVM VC，检查正确的数据是否已到达目的地(UVM VC)。

图2显示了数据记分板用于全双工同步通信(例如，SPI)。 UVM VC和外围总线上的监视器(被动)用于将数据发送到记分板：UVM VC发送的数据被添加到记分板 TX路径，当它们到达外围设备时，将通过总线监视器发送到相同的记分板进行匹配。来自外围设备的数据被添加到记分板 RX路径中，并与UVM VC被动监视器接收的数据相匹配。

图2：全双工同步外设示例

此方法的主要缺点是门级仿真的可移植性。在实施阶段，RTL中可用的内部信号可能会在优化的网表中消失，UVM VC模块的绑定变得困难，有时甚至不可能(例如，在合成期间删除未使用的端口)。

新的SoC验证流程

新流程的基本概念是记分板中检查的数据不应来自内部SoC节点上绑定的监视器(参见图2)。因此，修改了测试平台配置，以便仅使用UVM VC(主动和被动)进行顶层绑定的数据检查。内部监视器(绑定在SoC内部节点上的监视器)仅用于RTL仿真，检查总线的合规性并跟踪覆盖范围。

此时，有必要更改数据在UVM VC和SoC外设之间交换数据包的流程。主要要求是：

数据随机化

门级模拟的可移植性

易用性

由UVM VC生成并由外围设备接收的随机约束数据分组被SoC用于生成出站分组。为了增加随机化，SoC中的微处理器计算接收数据的CRC并将结果用作要传输的数据。

记分板将从UVM获取数据VC，在将它们添加到数据列表之前，它将计算CRC。从外围设备返回的数据将直接添加到记分板以进行匹配过程。图3显示了这个新流程的一个示例。

图3：数据检查的新方法

计算CRC非常简单;对于记分板，可以使用内置函数(伪方法)，例如，可以使用 e 语言：

list_bytes 。crc_32(来自字节，字节数)

list_bytes 。crc_8(来自字节，字节数)

它逐字节读取列表返回位或字节列表的CRC函数的整数值。可以计算CRC，定义起始字节(通过第一个参数 from byte )和选定的字节数(通过第二个参数字节数)。

32位CRC的生成多项式为：

x 32 + x 26 + x 23 + x 22 + x 16 + x 12 + x 11 + x 10 + x 8 + x 7 + x 5 + x 4 + x 2 + x +1

8位CRC的生成多项式为：

x 8 + x 2 + x + 1

类似的函数用于SoC中微处理器执行的 C 代码：

POLY_GEN8为0x03。可以使用POLY_GEN32 = 0x2608EDB为CRC32扩展该功能。

使用此方法可以极大地简化记分板上的数据管理;由于数据检查是在串行接口上进行的，因此它与微处理器总线的数据大小无关，可以是8,16,32位或更多。以下是记分板的示例。

全双工同步接口

如果是全双工同步接口，例如SPI，我们可以有两种可能的模式：外设是从机，或外设是主机。

当外设是从机时，事务由外部UVM VC启动。全双工模式意味着必须同时发送和接收数据。由于我们希望避免在SoC侧生成数据(在 C 代码上没有有线数据)，因此有效数据存在系统延迟。此延迟应在记分板上实现，以便正确比较交换的数据。

图4：全双工数据序列用于从模式

图4显示了在主(UVM VC)和从(外设)之间交换的数据序列的示例。由外围设备发送的第一个符号对于记分板“不关心”，因此被释放。微处理器需要一些时间从缓冲区获取数据并计算CRC。一段时间后，数据准备就绪，交换继续从UVM VC随机生成和来自外围侧的伪随机数据(在D x 上计算的CRC)。

我们可以通过使用传统的“不关心”数据(例如，零)来进行自动符号同步。当然，这些数据不应由UVM VC生成。 SoC上的外设将发送零直到CRC数据准备就绪，并且UVM VC以足够的零符号终止以完成记分板中的匹配。

当外围设备是主设备时，事务通过微处理器自行启动。

图5：主模式的全双工数据序列

数据流与奴隶模式的情况非常相似。图5显示了在主(外设)和从(UVM VC)之间交换的数据序列的示例。外围设备发送的第一个符号对于记分板“不关心”。 UVM VC用随机符号D x 回复，微处理器用它来计算外围设备发送的伪随机数据。如上所述，黄色突出显示的符号是在记分板中比较的符号。

半双工接口

如果是半双工接口，例如I 2 C，我们可以有两种可能的模式：外设是从机，或外设是主机。

外设是slave，事务由外部UVM VC启动。半双工模式基于通信协议，其中主设备发送命令请求数据作为回复或将数据发送到专用从设备。

对于全双工模式，有必要定义良好的流程这样可以避免 C 代码中的数据(非随机)并使数据检查变得简单：

通过发送write命令启动事务。 UVM VC将开始发送数据包。在计算CRC之后，这些数据被添加到记分板中。

接收的数据被DUT用作“回复读取”命令。微处理器计算接收数据的CRC并准备数据包以进行回复。

UVM VC发送读命令。外围设备开始发送先前准备的数据。这些数据将添加到记分板中以进行匹配。

图6显示了此数据握手的简单图表。

图6：从模式的半双工数据交换

主模式

当外围设备是主设备时，事务通过微处理器自行启动。

在这种情况下，为了利用UVM VC的随机约束特性，协议必须

通过发送读命令启动事务。 UVM VC将开始作为回复发送数据包。在计算CRC之后，这些数据被添加到记分板中。

接收的数据被DUT用作“写入数据”命令。微处理器计算接收数据的CRC并为下一步准备数据包。

外设发送写命令，然后开始发送先前准备的数据。这些数据将添加到记分板中以进行匹配。

图7显示了此数据握手的简单图表。

图7：主模式的半双工数据交换

复杂协议

相同的方法可以也可用于USB或以太网等复杂协议。概念是相同的：对于全双工通信，初始符号是“不关心”(空符号)，然后DUT使用接收的样本来计算CRC并将数据发回。

对于半双工，数据交换由UVM VC启动，然后DUT使用接收的数据包构建传输数据包。