Механизм окончания испытаний UVM
task mabu_scoreboard::main_phase(uvm_phase phase);
forever begin
# 1ns;
if (extip_rd_req_cnt - extip_rd_rsp_cnt >= `MABU_READ_OST_NUM) begin
hit_rd_max_outstanding = 1;
`uvm_info(get_type_name(),"reach read outstanding threshold!",UVM_NONE);
end else begin
hit_rd_max_outstanding = 0;
end
if (extip_wr_req_cnt - extip_wr_rsp_cnt >= `MABU_WRITE_OST_NUM) begin
hit_wr_max_outstanding = 1;
`uvm_info(get_type_name(),"reach write outstanding threshold!",UVM_NONE);
end else begin
hit_wr_max_outstanding = 0;
end
end endtask
Цикл forever выполняется в фазе, отнимающей много времени (main_phase). Тест может быть завершен правильно, потому что main_phase не вызывает возражений?
Ответы 2
Да это верно. Поскольку main_phase в вашем табло не вызывает raise_objection, табло не помешает окончанию теста.
Большинство компонентов вашего тестового стенда не вызовут возражений. Обычно ваш тест (класс, расширенный от uvm_test) вызывает возражения на его трудоемкой стадии.
При запуске трудоемкой фазы UVM должно быть выдвинуто хотя бы одно возражение, чтобы предотвратить завершение этой фазы. Завершение фазы означает, что процесс всех uvm_component, выполняющих эту фазу, будет уничтожен.
В вашем примере с табло нам пришлось бы предположить, что какой-то другой компонент возражает против main_phase, иначе цикл forever никогда не завершит свою первую итерацию. Лучше использовать run_phase для процесса, который должен выполняться для всего теста.
Любая задержка в вашем тестовом стенде UVM, кроме генерации часов, является плохой практикой. Предполагается, что испытательный стенд UVM основан на транзакциях, и единственные задержки должны быть связаны с генерацией ваших часов. Цикл forever с задержкой опроса в 1 нс особенно вреден для производительности. Гораздо лучший подход — блокировать ожидание события.
спасибо, Дэйв, «бесконечный цикл с задержкой опроса в 1 нс особенно плохо сказывается на производительности». что, если часы работают на 1 нс, есть ли разница в производительности?