【数字IC前端】浅谈SystemVerilog与UVM标准的发展（下）

浅谈SystemVerilog与UVM标准的发展（上）

上篇主要分析一下Systemverilog与UVM标准的发展历程。 我们应该已经意识到了UVM产生以来，SoC验证产生了巨大的变化。我们需要考虑的是在这种趋势下，UVM的标准将何去何从。

验证范围的变更

SoC设计变得越来越复杂，早些年的数据如下，现在自然更复杂了。

• 除了存储器之外，逻辑和数据路径的平均门数已经从2004年的400K门增加到2012年的11.1M门。
• 嵌入式处理器的平均数量已经从2004年的1.06个，增加了一倍多，到2012年的平均数量为2.25个。
• 2004年，只有52％的设计有一个或多个嵌入式处理器，2012年，79％都有一个或多个嵌入式处理器（其中的29％有3个或更多嵌入式处理器）

复杂性的增加对验证提出了新要求，UVM最初被开发时并未考虑到这些要求。嵌入式处理器的出现已经导致软件的实现成为系统的关键部分之一，因此功能验证的最终目标是必须准确对芯片或系统将在真实操作时的环境和行为进行建模，并确保指定功能的硬件和软件都能正确地响应。

我们曾经考虑过“软硬件验证”，只是想要确保嵌入式处理器能够成功地与硬件模块进行通信，进而来配置它们，并启动数据传输。通过UVM可以相对容易地模拟这样的行为，具体可以通过用UVM验证组件替换处理器模型，UVM验证组件通过使用UVM序列来发起一些想要的操作。

一旦正确配置了模块，UVM可以生成带约束的随机激励，基于连接到接口的SoC模块的相互关系，去验证一些功能。显然，这种方法验证400K门的设计时还可以，但是验证11M门的设计就有些尴尬了。

基于UVM序列的软硬件验证方法的另一个问题是，虽然它在解决总线上的基本问题上有点用，但是，在实际嵌入式处理器模型上，没有简单的方法去复制在验证组件上运行的UVM序列。因此，在从模块级到系统级验证的迁移复用中，不可避免地引入了不连续性。这就需要确保运行实际软件时验证方案仍然有效。随着多处理器的引入，问题变得更加明显，因为需要验证更多的软件，包括多个处理器之间通过共享内存、缓存等而发生的软件线程间的交互等。

事实上，使用复杂的协议时，如arm的ACE，总线结构本身已经成为必须被验证的子系统。不再是SoC上的简单“互连”。相反，这个“互连”现在集成了高速缓存，存储器控制器和其他功能，并且在许多情况下，它自己的网络还用于将许多组件彼此连接。连接到这种总线结构的多个UVM组件上运行的带约束的随机序列，是非常不好写的，要产生这种结构验证所需的所有场景就更难了。

对UVM提出的要求

在对多处理器SoC验证要求的简要探讨中，我们可以看到，许多基于UVM的随机约束，其能力不足以满足当今SoC设计的生产力要求。我们需要的是，在UVM环境的基础上，在更抽象的层次上，指定实现激励和覆盖率的能力的新方法，要求如下：

• 可以作为UVM序列和软件复用
• 可以更好地覆盖所需的状态空间而不重复
• 允许多个状态空间的组合成为系统级空间，而不损失有效性

当考虑这些要求时，有理由认为，UVM作为致力于为用户提供理想验证平台的验证方法学，应当允许工具开发人员自由创新，以尝试通过进一步的抽象和自动化来解决这些问题。如果找到了这些问题的解决方案，很容易看出，在UVM 1.2中意图解决的障碍，不再需要由UVM本身中解决。相反，UVM具有指定验证组件的能力以及使用UVM squence的能力，验证组件可以依据算法配置，UVM squence 可以提供用于更高级别激励规范的API以驱动UVM组件，这样就意味着不必继续扩展UVM的核心功能。像transaction 记录这样的功能现在可以作为UVM之上的更高级别工具的一部分来完成，所以诸如事务链接和高级调试之类的事情也不用UVM来完成。

考虑这样一种系统，其中总线master必须能够在所有可能的模式下驱动总线。 在UVM环境中，master将被表示为agent，其中driver将从sequence中获得transactions，并使用嵌入在transaction对象中的模式信息来控制接口信号，以在总线上执行transaction 。 考虑一个假设的总线协议：

假设有4个可能的size值，2个可能的rw值，16个可能的等待值和100个可能的commit_delay值，这个协议将涉及4 × 2 × 16 × 100 = 12,800 种可能的transaction类型的变化。典型的覆盖模型还要求每一种transaction 类型在不同的存储器区域执行。期望能够通过随机约束生成实现所有的这些覆盖点是不太现实的，并且当有多个masters 时，问题就变得更糟。因此验证工程师希望减少写入覆盖点，并希望随机事务流能终命中所需的组合。

不再单独指定约束和覆盖目标，使用不同的语法，将抽象级别提高到单个规范将是很有用的，这可以保证生成的事务集合覆盖所需的状态空间，而不重复任何场景。因此，这种抽象规范可以用于生成事务。

在UVM环境中，通过sequences对激励进行建模，因此可以从规范生成sequences代码，或者可以使用自动化钩子来构建UVM sequences以链接到另一个生成引擎，该生成引擎将告诉sequences下一次生成什么事务 。UVM的模块化允许UVM环境的其余部分，包括agent，scoreboard和其他组件，包括其他随机约束sequences，都可以继续使用而无需修改。 UVM就是这样的允许自动化的理想平台。

我们的最终目标是确保在处理器上运行的软件成功地与环境交互。抽象规范的另一个优点是，抽象规范将使得事务流生成也可以作为在处理器模型上运行的软件来实现。

结论

SystemVerilog和UVM的标准化对我们的行业有显著的好处。
UVM无疑是成功的，但在其开发过程中，SoC验证的要求已经改变，需要引入了对更高层次的抽象，而且最先进的SoC验证将需要使用更创新型工具，这些工具可能已经超出UVM所提供的特性了，继续在UVM中添加额外的功能又反而会使UVM效率降低，因此继续修订UVM和SystemVerilog带来的副作用看来还是更大一些，再继续更新UVM意义并不大。
制定一个标准的目的在是未来更好的创新，所以标准必须要提供一个高效、稳定的平台，这样工具开发才能集中注意力，创造更有意义的价值，而不用把精力花在兼容语言或验证方法功能上。