Я ищу некоторое интуитивное понимание метода systemverilog ожидания определенного сигнала на интерфейсе для 1) захвата транзакции на мониторе или 2) управления транзакцией в ответ на некоторый сигнал от DUT.Давайте предположим, что проверяемое устройство выдает сигнал готовности, и драйвер должен вести два такта данных (значения 1 и 2) вплотную, одновременно выдавая действительный сигнал, чтобы тестируемое устройство знало, когда собирать данные.
Существует два способа ожидания готового сингла от DUT, о котором я знаю;1) один - если обусловленное событие синхронизации, а другой - 2) потребление тактовых импульсов, в то время как некоторый сигнал не соответствует действительности (например, уровень готовности низок).Код тестового стенда может быть найден EDA детская площадка (строка 37 my_driver.sv) .
Первый метод использует @(posedge dut_vif.clock iff(dut_vif.ready == 1));, а второй метод while( ! dut_vif.ready) @(posedge dut_vif.clock);, и есть одинразница часов между двумя методами, как показано в форме волны.Мое лучшее понимание -
@(posedge dut_vif.clock iff(dut_vif.ready == 1));
Этот метод ожидает события повышения тактового импульса «при условии» готовности == 1. Поэтому данные и действительные значения находятся на высоком уровне25 нс.
while( ! dut_vif.ready) @(posedge dut_vif.clock);
С другой стороны, это утверждение означает, что симуляция должна потреблять часы, когда уровень готовности низок.Однако эта интерпретация и реальное поведение systemverilog очень разные.При 15 нс сигнал готовности становится высоким, и действительные данные передаются в одном и том же цикле.Насколько я понимаю, при 15 нс тестовая среда должна по-прежнему фиксировать готовность, и симуляция должна занимать один такт.Следовательно, второй метод должен вести себя так же, как и первый.
Могу ли я получить некоторую интерпретацию того, как понять эту разницу?
Я прилагаю форму волны здесь.
