Я хочу использовать следующие концепции SystemVerilog:
Теперь в UVM мы создаем экземпляр виртуального интерфейса и делаем его доступным через базу данных конфигурации, поэтому я не понимаю, как драйвер сможет получить ссылку только на модпорт вместо виртуального интерфейса. Каково стандартное решение, позволяющее избежать случайного доступа к сигналу без модпорта?
Мне удалось придумать только следующий (непроверенный) пример кода, однако я не уверен, есть ли лучший способ:
interface my_interface(input clk);
logic I;
logic O;
clocking cb_drv @(posedge clk);
output I;
input O;
endclocking
clocking cb_mon @(posedge clk);
input I;
output O;
endclocking
modport drv(clocking cb_drv, output clk);
modport mon(clocking cb_mon, input clk);
endinterface
class my_driver extends uvm_driver #(my_transaction);
`uvm_component_utils(my_driver);
virtual my_interface.drv vif;
...
virtual function void build_phase(uvm_phase phase);
virtual my_interface temp;
super.build_phase(phase);
if (!uvm_config_db#(virtual my_interface)::get(this, "", "my_interface", temp))
`uvm_fatal(...);
vif = temp.drv;
endfunction
virtual task run_phase(uvm_phase phase);
forever begin
seq_item_port.get_next_item(transaction);
@(vif.cb_drv);
vif.cb_drv.I = transaction.I;
seq_item_port.item_done();
end
endtask
endclass
Проблема с этим решением заключается в том, что у меня есть функции/задачи, реализованные в интерфейсе (например, функции чтения/записи), которые таким образом становятся недоступными.
Блоки синхронизации — это лишь один из многих способов предотвратить возникновение гонок между вашим испытательным стендом и тестируемым устройством. Вы можете использовать неблокирующие назначения точно так же, как их используют дизайнеры, чтобы предотвратить гонки между их RTL-кодом. Вы можете использовать отрицательный или смещенный фронт тактовой частоты для управления и мониторинга тестируемого устройства. См. мою статью о DVCon: Недостающее звено: испытательный стенд для подключения ИУ.
Что касается использования задач и функций в интерфейсе modport
, вы, безусловно, можете сделать их доступными с помощью import
. Но большинство людей отказались от использования модпортов для проверки, потому что даже в показанном вами случае очень легко получить доступ ко всему интерфейсу. Вам придется разделить базу данных конфигурации для каждого модпорта.
uvm_config_db#(virtual my_interface.drv)::set(this, "*", "my_interface", itf_instance.drv)
uvm_config_db#(virtual my_interface.mon)::set(this, "*", "my_interface", itf_instance.mon)
Драйверу и монитору необходимо будет получить соответствующие экземпляры виртуального интерфейса из файла uvm_config_db.
Вы можете передать значение любого типа с помощью uvm_config_db. Просто параметризуйте его с помощью абстрактного типа класса. В этом примере я также использовал фабрику UVM: verificationacademy.com/forums/t/…
Спасибо! Есть ли способ передать реализацию абстрактных классов (из вашей статьи) через config_db, например, modports в вашем примере?