日志

UVM验证平台的加速考量

已有 1591 次阅读| 2017-7-30 14:07 |个人分类:验证前沿资讯|系统分类:硬件设计

摘要:  

 UVM已经成为了一种高效率的、从模块级到系统级完整验证环境开发标准，其中一个关键的原则是UVM可以开发出可重用的验证组件。获得重用动力的一个方面表现为标准的仿真器和硬件加速之间的验证组件和环境的复用。

 本文所聚焦的技术手段是让一个已有的UVM验证平台通过改变需求去执行硬件加速。如果这些点在UVM环境开发过程中被考虑到，那么之后将环境迁移到硬件加速器作为一个性能选项将是一件较容易的事情。本文所提议的建议将会使你的UVM验证环境（以及验证组件）对于硬件加速来说是可复用的。

1 简介

 通用验证方法学（UVM）已经广泛的被用于复杂验证环境的开发，如今许多团队已经开始复用之前的验证组件和环境到第二代和第三代设计中，当项目验证过程中需要非常长的仿真时间时，可以采用硬件加速技术将仿真时间从若干小时缩短为若干分钟或者从几天缩短为几小时。理想的情况，对于用户来说希望能够将UVM验证环境运用于仿真器仿真和硬件加速模式，确保仅有一个开发流程去管理验证平台。

本文中讨论的是一种修正的验证方法学，其目的是当设计被移植到硬件加速平台时，开发的UVM验证环境将不再具有负面的性能方面的影响。下面的一些性能方面考虑要被覆盖到：

A：分割顶层模块（top-level），以便于接口、设计以及额外的同步组件是在一个模块同时验证平台在一个单独的模块里。

B：将之前的监视器（monitor）转变成一个收集器（collector）（用于信号层信息的收集）和一个监视器（monitor）（用于检查和覆盖率）。

C：设计的验证环境满则在驱动器/收集器和验证换进剩余部分之间会以最少的事物（transaction）数量进行交互。分组的事物可以被执行，不用和验证环境的剩余部分进行交互。

D：创建同步任务获取事物（transaction）、驱动信号（driver）以及从信号层的详细细节重新组装事物（collector。这些任务可以被移植放到接口定义中然后在驱动器、收集器中调用它们。由于接口是同步的故它可以被划分到硬件范围内。

E：把时序部分（timing）从事物（transaction）中移除掉，在事物序列（sequence）之内或者之间使用指定延时的可替代方法。一个时序的代理（timing agent）被引入去执行“延时”序列（“delay” sequence）。在仿真器仿真期间或者在硬件加速过程中，这些延时序列会在接口被执行。

F：优化随机化的事物（randomization transaction），以确保不必要的随机化调用时不能被执行的，这些调用可能会对性造成严重的影响。

2  硬件加速对于你的UVM验证平台是一个好的性能选项吗？

 在考虑加速之前，从侧面用扼要描述一下验证环境是非常重要的，因为长时间的仿真运行检查，其中很大一部分时间是花费在DUT代码检查上面。通常来讲，当验证环境编译仿真所需时间大、DUT编译仿真时间小时，加速对于验证环境来说不是一个高效的性能选项。然而，当过渡到子系统和系统级验证时，验证的关注点可能不需要详细的验证特性，因为它们都是模块级和IP级验证的焦点。这就意味着，在一些案例中若仿真描述显示出验证环境编译仿真的时间很大时，验证环境优化技术可以被应用同时验证环境也可以考虑加速。

 当仿真时间很短时，对于验证环境来说加速也不是一个好的性能选项。

下面是主要的性能因素的考虑和描述：

 2.1 UVM 环境运行时间（UVM Testbench runtime）:

 这包括了仿真器中的任何时间花费，如包括验证环境的随机化、配置和创建验证环境、配置DUT、驱动随机激励、以黄金模型为参考对接受到的数据进行检查以及采样覆盖率。对于一个长时间的仿真，验证环境的配置和创建时间可以被忽略，因为在编译仿真过程中它们仅仅只在仿真开始时出现一次。

 2.2 软件/硬件同步（HW/SW synochronizations）:

 信号和事物在UVM验证环境和DUT初始化的一个同步事件之间被发送，仿真和硬件之间的每一次交互出现一个延时。此外，当数据需要在仿真器和硬件之间搬移时，性能是会被影响的，这对于性能的开销来说至关重要。

 2.3 DUT运行时间:

 这包括了硬件加速过程中设计被（验证环境）执行的任何层面。由于硬件加速执行非常快，故尽可能将设计（验证环境）移植到属于硬件的范畴中去是非常重要的。如下图所示，其中属于硬件范畴中的任何警告必须被同步。

图1. 相关仿真和加速的运行时间
例如，如果你简要描述了一个仿真的运行，验证环境花费了25%的仿真时间，设计花费了60%的仿真时间，同步化预估计花费15%的仿真时间，如果设计所占的时间呗减少到0，则最大的性能可以按照下面公式计算：
HW_TIME = 60% + 60%*15% = 69%
估算的加速值（没有TB优化） =  (100/(100-HW_TIME)) = 3.2X
在这种情况下，硬件加速可能不是一个好的选项。
 如果设计仿真运行所占时间增加到85%同时整体时间开销减少了10%，那么最大的性能改善可以用下面公式计算：
HW_TIME = 85% + 85%*10% = 93.5%
估算的加速值（没有附加TB优化）= 100/6.5 = 15.4X
 一旦你建立的设计可作为一个好的加速对象，那么通过调整后改善性能可以远远超过上面所举例的数字。通过减少生成随机激励以及在硬件和软件范畴之间数据传递的时间，可以实现额外的性能加速。

3 划分验证环境                          
 值得推荐的是对top级模块进行划分以便DUT和环境附加的同步方面可以被放到一个模块中，验证环境单独放在一个模块中。这样做不会影响仿真性能。
图2展示了一个简化的验证环境，通过环境的划分去支持硬件仿真加速。
图2. 对DUT和TB分割后的验证环境
 顶层硬件模块（hw_top）包括了DUT的实例化、一个时钟和复位单元的产生、接口以及TB和DUT之间的连接和同步的存储组件。被简化的验证环境模块（tb_top）包括了UVM包（UVM package）、UVM组件包（UVM component package）、一个用于配置和启动验证用例的初始化模块。验证环境的顶层模块（tb_top）的唯一目的是通过使用UVM 的配置数据库（UVM configuration database）去配置虚接口（virtual interface）以及调用run_test（）任务命令。
图3. 简化的tb_top模块代码
图4. 简化的hw_top模块代码
4 完成一个收集器和监控器
 UVM推荐在每一个代理（agent）中包含一个监视器（monitor），并且该监视器被动的采样DUT接口上的信号，将采样到的信息聚集组装到一个事物（transaction）中；以及收集覆盖率和性能检查。
 对于硬件加速（和仿真）来说，值得推荐的是分割监视器的活动到信号级以及事物级活动中。这一点非常像UVM中推荐的仿真用例的创建。对于生成的仿真用例，UVM对事物级（transaction-level）（如sequence/sequencer）和信号级（signal-level）活动（如driver）做了强制的分离。
 对于监视器来说，通过分割将监视器放到一个低等级的收集器（low-level collecctor）类中和一个高等级的监视器（high-level monitor）中，其中高等级的监视器用于事物级覆盖率收集和检查。低等级的收集器也是一个被动的实体，它按照接口到特定协议的处理方式从接口信号来捕获事物信息。然后通过UVM的TML通信端口将事物传送到监视器，监视器可以做检查、采样覆盖率以及将检查通过的事物发送给计分板（scoreboard）或者任何可以访问的验证组件。
图5. 带有收集器和监视器推荐的UVC结构
图6. 监视器和收集器的连接
 5 将Testbench和DUT之间的交互最小化
 当硬件加速被部署展开后，在DUT和Testbench之间的每一次交互都需要一个同步的事件，这对于性能会产生不利的影响。在Testbench和DUT之间只对驱动器和收集器做访问限制是非常重要的。这听起来很直观，但是实际很难实施这一政策。当设计和验证环境被迁移到加速平台去运行加速任务时，驱动器/监视器以外的每一次交互都是不可回避的。
 比如两个常见的地方，当发现在一个事物序列中正在等待一个信号发生变化时、或者正在等待复位。一个简单的UVM时钟和复位代理类将会在完成或者一个中断代理可以被添加到UVM验证环境中去限制访问这些信号以及与这些信号相关的事件。

6 驱动器和监视器调整
 当用户从仿真迁移到硬件加速时，第一步通常是化为UVM验证平台到仿真器，将DUT放到硬件范畴这边；对于验证来说，使用同样的测试用例去跑仿真以及加速。
 基于事物的仿真加速，部分验证环境也可以被放到硬加速器中，并且验证环境和DUT之间的接口通过任务调用而不是单个信号的转换，这进一步减少了在仿真器和加速器之间同步是次数。这样的性能提升是可取的，但是要求验证环境划分后的任意一个部分和硬件这边是保持同步的。
 开发的接口UVC 驱动器（driver）通常包含了一个“driver_transfer”任务，该任务会把一个事物转换为一系列经过一段时间周期的用于交互的信号，通过一个虚接口，这些信号会被连接到DUT上。类似地，UVC 监视器/收集器（monitor/collector）包含了一个“collect_transfer”任务，，该任务通过虚接口捕获信号级详细的信息，并且为了后续的检查、覆盖率以及分析从新装配事物。
图7 描述了一个传统的UVC结构。通过一个虚接口句柄进行信号驱动并且从驱动器和收集器中参考时钟信号。
图7. 传统的UVC结构
对于硬件加速来说，值得推荐的是开发同步化的“driver_transfer”和“collector_transfer”任务，以便于它们能够被包括在hw_top模块里面的DUT接口中。可选择的情况下，对于仿真或者加速来说，这些方法可以被放置到接口中去。将这些任务从驱动器类里移到接口中去唯一的缺点就是不能使用UVM的工厂机制去覆盖重载那些任务的默认行为。该需求（重载driver_transfer或者collector_transfer任务）在UVM验证环境中很少见。
 图8描述了一个具有硬件加速功能的UVC结构。其中驱动器和收集器通过一个虚接口句柄调用接口中消耗时间的任务。信号驱动以及时钟参考可以直接在接口中。
图8. 加速UVC结构
7 时钟和复位
 对于加速来说，时钟和复位时设计中一个重要的部分。因为时钟信号频繁切换可以导致不希望的同步事件出现。因此推荐大家完成一个简单的可重用的UVM agent类，在该类中通过使用序列配置和启动时钟时钟信号，初始化复位信号以及执行来自UVM验证环境的延时序列。而时钟生成所要实现的细节、延迟和复位信号将会在SV接口中和属于硬件范畴的时钟生成模块中完成。下图所描述的是一个UVM时钟和复位代理的架构图。
图9. 可重用的时钟 & 复位代理
 
 下面展示的代码是一个简单可重用的数据事物，该事物可以对DUT中的时钟以及复位信号进行控制。
图10. 时钟复位事物
 在driver的connect_phase（）中，driver可以从配置数据库（configuration database）中拿到接口，然后在run_phase（）中它拿到了时钟复位事物并且使用控制信息去调用接口中定义的时钟和复位任务。
 下图中的SV代码所描述的技术细节是通过在driver中使用clk_reset_item事物信息去调用接口中合适的任务。
图11  时钟复位信号驱动以及连接
 为了确保时钟可以正确的被识别，时钟生成结构被放置在了一个模块中。通过接口传递合适的控制信号到模块中去控制处理生成时钟。
 加速环境中处理超时问题尤其令人担忧。常常需要去检查一个特定的事件、事物或者中断发生在的一段特定的时间内，如果时钟的参考被放到了类这边，则需要在仿真器和加速器之间进行频繁的同步操作。为了避免这一点，一个计时器和序列被内置在时钟/复位UVC中，当设置时间超时到达后，该序列会返回对应的超时信息。在仿真测试完成之前，当还没有到达超时，通过一个字段的设置可以引起错误。对于同时引起的超时请求，计时器可以并发的处理那些超时请求。
 上面的sv代码中所演示的是一个简单的例子。如果考虑到一个设计以后想要被重用的话，那么时钟/复位代理（clock and reset agent）可以跨项目和团队内部使用。

8 从事物序列中移除时序
     对于最佳的性能来说，确保在验证环境中没有时序信息是非常重要的。这包括了涉及到的时钟信号，#延时以及wait等待一个DUT信号的转变，在事物序列之间或者之内使用指定延时的替代方法。时序代理（timing agent）可以去执行“延时”序列。并且这些序列会在仿真期间和加速期间硬件这边的接口中去执行。
 时钟和复位代理类中也包括了一个序列，该序列可以被配置去等待（或者不等待）用户基于时钟数目可变所定义的延时。该序列也可以在虚序列（virtual sequence）中被使用。例如下图中sv代码所示：
图12. 通过虚事物序列执行时序序列
 下图中被替换的代码可以在虚事物序列中找到。
图13. 带有时序信息的虚事物序列body（）任务

9 随机化调整
 确保约束随机化尽可能的简单。如果当你在用加速模式跑测试用例且不需要随机化时，确保你的接口UVC中包含的事物序列不会调用随机化函数（randomize（））。

10 总结
 预先花费时间构建容易移植到硬件加速仿真的UVM环境可以带来很大的性能益处。因此建议升级、加强UVM环境结构，使得仿真和硬件加速均使用一个验证环境。