Я собираюсь протестировать сложный модуль, который имеет интерфейсы axi4-stream и apb в качестве входов и интерфейс axi4 в качестве вывода. Насколько я понимаю, я должен построить такую среду:
|-----------------------------------------------
| |
_________|_________ _______________ ______v______
| | | | | |
| APB-monitor | | AXI4-monitor |--->| |
|___________________| |_______________| | |
| | | |
____________ ______________ | _________ | | |
| | | | | | | | | |
| APB-seqr |----->| APB-master |---*--->| | | | |
|____________| |______________| | | | | |
| DUT | | | |
____________ ______________ | |-----------*----------->| Scoreboard |
| | | | | | | |
|AXI4-S-seqr |----->|AXI4-S-master |---*--->| | | |
|____________| |______________| | |_________| | |
| | |
| | |
-------------------- | |
| | | |
| AXI4-S-monitor |---------------------------->| |
|____________________| |____________|
Это правильно? Если да, то как мне отправлять транзакции с мониторов на табло? Думаю, мне следует использовать пару analysis_port/imp, но я не могу перегрузить метод write
в классе табло, поэтому, как я понимаю, я не могу использовать три порта анализа в одном классе.
Может ли кто-нибудь указать мне пример такого сложного дизайна uvm?
В настоящее время у меня возникает ошибка такого типа при попытке использовать порты анализа:
# Time: 0 ps Iteration: 0 Region: /uvm_pkg::uvm_analysis_imp #(axi4_s_pkg::axi4_s_seq_item, ecaa_pkg::ecaa_scoreboard) File: D:/questasim64_10.4c/win64/../verilog_src/uvm-1.1d/src/uvm_pkg.sv
# ** Error: (vsim-8754) D:/questasim64_10.4c/win64/../verilog_src/uvm-1.1d/src/tlm1/uvm_analysis_port.svh(114): Actual input arg. of type 'class work.axi4_s_pkg::axi4_s_seq_item' for formal 'trans' of 'write' is not compatible with the formal's type 'class work.apb_pkg::apb_seq_item #(3, 2, 32, 32, 4)'.```
Вот два пути решения вашей проблемы.
1. Простой способ (с использованием макросов `uvm_analysis_imp_decl)
Просто вызовите макрос вне класса компонента для каждого входа. Макрос декларирует особый вкус имп анализа. Аргумент, переданный макросу, используется в качестве суффикса в имени типа импа и имени метода записи. Затем вы создаете один имп для каждого входа и определяете один метод для каждого входа. например:
`uvm_analysis_imp_decl(_AXI4_S)
`uvm_analysis_imp_decl(_AXI4)
`uvm_analysis_imp_decl(_APB)
class scoreboard extends uvm_scoreboard;
uvm_analysis_imp_AXI4_S #(AXI4_S_xact, scoreboard) AXI4_S_export;
uvm_analysis_imp_AXI4 #(AXI4_xact, scoreboard) AXI4_S_export;
uvm_analysis_imp_APB #(APB_xact, scoreboard) APB_export;
...
function void build_phase(uvm_phase phase);
AXI4_S_export = new("AXI4_S_export", this);
AXI4_export = new("AXI4_export", this);
APB_export = new("APB_export", this);
endfunction
...
function void write_AXI4_S(AXI4_S_xact t);
...
endfunction
function void write_AXI4(AXI4_xact t);
...
endfunction
function void write_APB(APB_xact t);
...
endfunction
...
2. Трудный путь (встроенные подписчики)
Создайте экземпляр трех подписчиков в своем табло. Каждый из них представляет собой отдельную область, поэтому у каждого может быть свой метод write
.
Спасибо за ваш ответ! Собственно, я думал о 2-м способе, и у меня есть подписчики в тестовой среде для одноинтерфейсных модулей. Было бы здорово их переиспользовать, но у них такой метод записи:
function void write(axi4_s_seq_item t); axi4_s_scoreboard axi4_s_sb; $cast(axi4_s_sb, m_parent); axi4_s_sb.write(t); endfunction
для интерфейса axi4_s. Я не могу их использовать по той же причине, и я не уверен, что это хорошая практика - писать новых подписчиков для новой комбинации интерфейсов.