4

I'm curious how you handle extensions to a protocol UVC. Let's say we have an APB UVC that implements the AMBA protocol. Let's also say that we have a DUT that, aside from the signals defined in the specification, also implements a few other signals that are related to the generic APB signals (they add support for protected accesses or whatever). On the class side it's pretty easy to handle: just create a new sequence item subclass with extra fields and do type overrides. Where it gets tricky is when working at the signal level. Our UVC already uses an SV interface that only contains the APB signals and it's not possible to extend it in any way. How would we get these extra signals into the UVC to drive and monitor?

What we have done up to now is, since we use our own homegrown UVCs, we just pack everything into the base UVC and have it highly configurable. I don't like this approach as I don't feel it's properly encapsulated. It confuses the user with too many extra config parameters and it makes development a lot harder. I'm just wondering if anyone has a nicer solution to this.

This is a question I also asked on the Accellera UVM forums: http://forums.accellera.org/topic/1832-handling-protocol-extensions/

4

1 回答 1

1

如何扩展协议 UVC（UVM 验证组件）以添加自定义扩展，保持适当的封装？

典型的协议（及其 UVC）具有状态或模式（在不同情况下控制操作）和阶段或事件（根据协议执行传输期间的划定区域或兴趣点）等概念。“普通”UVC 基于激励数据和观察到的 DUT 反馈的某种组合来维持内部状态/模式/阶段。扩展协议 UVC 以添加自定义信号通常需要访问相同的状态/模式/阶段或事件。

我假设您不需要修改协议，只需以非破坏性方式添加即可。

在课堂级别（您已经知道这一点）：

  1. 通过确保/添加为基础 UVC 中的自定义扩展创建基础
    • accessors() 用于关键协议状态或模式，以便扩展类可以访问它们
    • 关键协议阶段的事件/回调，以便扩展类可以订阅它们
    • 更喜欢基本 UVC 配置的配置对象，而不是离散的配置值
  2. 扩展序列项目（和序列库*）以通过扩展传达刺激意图
    • 考虑在这里使用随机约束来强制执行自定义扩展的规则
  3. 扩展 UVC 基类以创建您的自定义扩展，添加
    • 扩展序列项目的排序器，它提取刺激的扩展部分以供本地使用，并将项目向下传递到基本 UVC
    • 一个分析端口，可以报告由于自定义扩展而监控的任何其他信息
    • 自定义扩展的驱动程序/监视器，由基本 UVC 驱动程序/监视器中的事件/回调触发。
    • 配置对象/连接和通常的 UVM 机制的通路。

在信号电平：

  1. 考虑“接口中的接口”方法
    • 创建一个表示完整信号束的物理接口，其中包含：
      • 原始“香草”协议接口的一个实例
      • 表示“侧信号”的新接口的实例
    • 将外部或内部接口分配给测试环境和扩展 UVC 类中正确位置的虚拟接口句柄（通过通常的 UVM 机制）。
    • 如果可能，请考虑在此接口中使用断言以使您的扩展行为合法 wrt 基本协议行为

如果您能够在基本 UVC 中公开正确的钩子和 API，那么通过将扩展分开，您可以在通常难以维护的情况下（定制旨在成为“标准”的协议）中的代码具有最大的可维护性.

*扩展整个序列库可能并不总是可能的，在这种情况下，您的低级序列或项目可能需要访问“侧面”的某些配置，例如模型或某些配置对象的句柄，以控制“扩展”行为，为此使用通常的 UVM 机制。一个例子可能是与电源管理相关的扩展，其中低级实现影响协议，但高级控制独立于协议。

于 2014-09-10T23:13:36.817 回答