gpt4 book ai didi

system-verilog - 在从属模式下实现 UVM Agent

转载 作者:行者123 更新时间:2023-12-04 06:46:18 27 4
gpt4 key购买 nike

我在 uvm_agent 中实现了一个从模型。 “奴隶”是指它不能自己发起交易。事务始终由另一方(主 DUT)发起。所以它是一种被动代理(尽管它仍然能够传输回复数据包)。
当从设备检测到来自 DUT 的数据包时,它将自动(基于其协议(protocol))响应/回复另一个数据包。从代理有一个监视器来监听 DUT 的启动传输。并且由于它能够传输数据包,因此从属代理也确实有一个驱动程序来发送回复数据包。

+------------+  master initiate transfer  +------------------------+
| Master DUT | ------------------------> | UVM Agent - slave mode |
| | | Monitor |
| | | Driver Sequencer |
+------------+ +------------------------+


+------------+ +------------------------+
| Master DUT | | UVM Agent - slave mode |
| | slave auto reply | Monitor |
| | <------------------------- | Driver Sequencer |
+------------+ +------------------------+

我的问题是它应该如何发送回复数据包?直接来自其驱动程序?由于在 uvm 方式中,驱动程序项始终来自从用户测试级别执行序列的定序器。但现在在这种情况下,没有序列 - 只有来自监视器的检测到的数据包。

我的第一个想法是,我需要从 monitorsequencer 提供某种反馈,并在那里实现我的协议(protocol)功能。
或者我应该将数据包直接从 monitor 传递给 driver,让它处理并发送回复?如果是这样,我该怎么做?有没有更好的办法?

最佳答案

您想要的也称为 react 剂。不要将它与被动代理混淆,被动代理是仅监视信号但不驱动信号的代理。

在这样的代理中,您要做的只是在驱动从项的定序器上启动无限循环。

class slave_sequence extends uvm_sequence;
task body();
forever begin
`uvm_do(slave_item)
end
endtask
endclass

驱动程序会等待主机开始一个事务(它如何做取决于协议(protocol)),当它看到一个它会调用 get_next_item(...),驱动响应和回去等待另一笔交易。

class slave_driver extends uvm_driver;
task run_phase(uvm_phase phase);
forever begin
wait @(master_requests);
seq_item_port.get_next_item(req);
drive_response(req);
seq_item_port.item_done();
end
endtask
endclass

从代理使用的序列项主要用于随机化响应延迟和读取数据。您甚至可以创建更奇特的东西,例如从属序列(一个简单的数组)内的内存模型。当来自某个地址的读取到来时,您从内存模型中传送数据,您只是随机化延迟。

查看以下链接以获取具体示例:https://verificationacademy.com/cookbook/sequences/slave

关于system-verilog - 在从属模式下实现 UVM Agent,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/28447993/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com