Нужно ли избегать кода OOMR (ссылка вне модуля) в UVM?

Использование иерархических ссылок Verilog или OOMR в пакете SystemVerilog является незаконным. Это связано с тем, что пакеты SystemVerilog компилируются первыми, а не остальной код SystemVerilog.

Как правило, вы будете помещать свои классы в пакет. Поэтому вам следует избегать использования Verilog Hierarchical References или OOMR в классах.

Очевидно, вы захотите подключить код класса к портам ИУ (например, драйверам и мониторам), а также, возможно, захотите проверить внутренние сигналы ИУ. Решение этих проблем различно для каждого случая.

Для подключения к портам DUT большинство людей используют SystemVerilog интерфейс. Вы создаете экземпляр интерфейса на том же уровне иерархии, что и DUT, и каким-то образом подключаете элементы интерфейса к DUT, например, используя иерархические ссылки Verilog или OOMR), например:

interface TB_hook (input bit clk);
  logic Stim, Resp;
  ...
endinterface

module harness;
  bit clk;
  TB_hook DUT_intf (.clk);
  Sys_Top DUT (
    .clk  (clk), 
    .Stim (DUT_intf.Stim),
    .Resp (DUT_intf.Resp), 
    ...

Затем в каком-то классе (драйвере, мониторе или агенте) вы можете использовать SystemVerilog виртуальный интерфейс для подключения к экземпляру интерфейса. Виртуальный интерфейс — это особый тип переменной SystemVerilog, которая может хранить иерархическую ссылку Verilog или OOMR на экземпляр интерфейса или модпорт. Поскольку вам нужно присвоить это значение во время выполнения, виртуальный интерфейс может быть скомпилирован в пакете (но код, который присваивает значение, не может быть в пакете), например:

class driver;
  virtual TB_hook V;
  task drive (input bit data);
    V.Stim <= data;

Затем в каком-нибудь Verilog module (вероятно, в модуле верхнего уровня) вы бы присвоили значение переменной виртуального интерфейса. Вы можете сделать это напрямую, например:

module TB_top;
  top_env env;
  ...
  initial begin
    ...
    env.agent.driver.V = harness.DUT_intf;

но большинство людей будут использовать базу данных конфигурации UVM:

module TB_top;
  top_env env;
  ...
  initial begin
    ...
    uvm_config_db #(virtual TB_hook)::set(null, "*", "DUT_intf", harness.DUT_intf);

class driver;
  virtual TB_hook V;
  ...
  function void connect_phase(uvm_phase phase);
    ...
    ok = uvm_config_db#(virtual TB_hook)::get(this, "", "DUT_intf", V);

Вы можете улучшить эту технику, используя модпорты и/или блоки синхронизации.

Для проверки внутренних сигналов тестируемого устройства имеются средства, предоставляемые уровнем регистра UVM. Для этого есть набор функций/задач:

• uvm_hdl_check_path — проверяет, существует ли путь HDL
• uvm_hdl_deposit — вносит значение в RTL
• uvm_hdl_force — вставляет значение в RTL
• uvm_hdl_force_time — форсирует значение на указанную продолжительность
• uvm_hdl_release — освобождает принудительное значение
• uvm_hdl_release_and_read — освобождает принудительное значение и считывает новое значение
• uvm_hdl_read– считывает значение RTL