我遇到的情况是,uvm_reg_block中有大约100000个寄存器。我有三个驱动程序可以将事务驱动到这些寄存器。根据标准的UVM RAL方法,我知道我们需要三个单独的uvm_reg_maps连接到三个音序器和驱动器。问题是要在所有三个uvm_reg_maps中复制寄存器,这会占用CPU时间来运行。甚至需要一个小时才能进入数据阶段。你能帮我解决这个问题吗?有没有一种方法可以将所有三个音序器连接到一个uvm_reg_map,并以某种方式基于该参数,确定应选择哪个物理音序器?
预先感谢
答案 0 :(得分:0)
据我所知,你做不到。如果一个reg映射能够连接到多个音序器,那么以后如何选择要运行的音序器?另外,对于每个添加的reg映射,其句柄将通过map.add_reg()存储在uvm_reg的m_maps数组中。并非每个映射都将创建自己的寄存器,因此不会复制寄存器。
答案 1 :(得分:0)
uvm_reg_map
只能与一个音序器一起工作。
您提到创建多个注册表映射太慢了,因为add_reg(...)
。可能将寄存器映射规范方面(寄存器在什么地址处)与定序器方面分开。为此,您将需要一个uvm_reg_map
实例来对其进行add_reg(...)
调用。我们称其为规格图。对于要驱动寄存器访问的每个定序器,您将需要另一个uvm_reg_map
(子类),该{某种方式指向规格图。我们将这些称为“驾驶地图”。
目前,我没有任何有关如何执行此操作的代码。我们需要研究一下其他代码如何调用uvm_reg_map
并覆盖这些函数。它们将指向规范图并使用uvm_reg_map
对其进行查询,而不是在get_reg(...)
中调用处理其自己的寄存器存储的实现。如果未在virtual
中将函数声明为uvm_reg_map
,则可能无法正常工作。 UVM倾向于使扩展成为不可能,因为代码依赖于实现而不是抽象。
答案 2 :(得分:0)
另一种方法是创建一个使用所有这三个音序器/代理的驱动程序(我们称之为reg_driver)。 reg_driver将有一个获得通用reg的音序器。交易。 从给定的运行时开关中,选择接口的reg序列以驱动reg_driver内部的特定事务。