2016-09-29 2 views
-1

Я запускаю испытательный стенд с UVM. В одном из run_phase() задачи компоненты, я делаю fork...join_none, чтобы начать следующий цикл, который проходит через все моделирование:

fork 
    forever @(posedge trigger) begin 
     force dut.a = $urandom_range('h00,'hFF); 
     force dut.b = $urandom_range('h0, 'hF); 
     force dut.c = $urandom_range('h00,'hFF); 
     force dut.d = $urandom_range('h0, 'hF); 
     force dut.e = $urandom_range('h00,'hFF); 
     force dut.f = $urandom_range('h0, 'hF); 
    end 

... 
some other stuff 
... 
join_none 

Дело в том, что сигналы , с и х получить принудительный к тому же значению. То же самое касается b, d и e.

Если новый триггер posedge появился позже, новые значения получаются рандомизированными и принудительными, но снова я получаю a == c == e и b == d == e.

Кажется, что $urandom_range вызывается только один раз для выбора каждого параметра (от 0 до FF и от 0 до F), а возвращаемое значение повторно используется для трех команд force.


EDIT: Я был в состоянии воспроизвести проблему на минимальном ТБ: http://www.edaplayground.com/x/4_ph

Похоже, вопрос с продавцом, я использую, выбирая другие инструменты проблема уходит.


EDIT 2: Я не понял, почему именно это происходит, но это, кажется, связано с тем, что сила заявление походит немигающая присвоения (т.е. если изменения RHS сигнала в будущем , принудительная LHS будет следовать за ним до тех пор, пока сила не будет равна release d, это не похоже на присвоение '='.

Поэтому я предполагаю, что проблема заключается в использовании возвращаемого значения функции как RHS. (Я не знаю, какое время жизни это возвращаемое значение имеет)

Решение в моем случае состояло в том, чтобы сохранить $ urandom значение переменной со статическим временем жизни, а затем принудительно включить эту переменную в RTL (как предложил J Reid)

+0

http://stackoverflow.com/help/mcve – toolic

+0

Насколько близко код, который вы отправили, к тому, что вы фактически выполнили? –

+0

@ dave_59 Я отредактировал сообщение с другим контекстом. Я пытаюсь воссоздать его на EDA Playground, но у меня проблемы с моей учетной записью на данный момент – chinocolerico

ответ

1

Почему бы не использовать класс со случайными величинами и ограничениями ???

// outside of the test-bench 
class my_stimulus; 
    rand bit [7:0] a, c, e; // can be logic if you like 
    rand bit [3:0] b, d, f; // rand won't give X or Z 

    constraint c1 { 
     unique {a, c, e}; 
     unique {b, d, f};  
    }  
endclass; 

// inside the actual testbench 
my_stimulus to_dut = new; 

fork 
    forever @(posedge trigger) begin 
    if (!(to_dut.randomize()) $error; 
    force dut.a = to_dut.a; 
    ... 
    force dut.f = to_dut.f; 
    end 
... 
join_none 

Уникальное ограничение будет либо вызывать ошибку, либо давать вам уникальные значения каждый раз. Наличие указанного размера устраняет необходимость установки границ, но это может быть сделано и с другим ограничением.

1

Две проблемы с кодом. Первое, что у вас есть аргументы в $ urandom_range reverseed; это (max, мин.), а мин. является необязательным по умолчанию для 0. Некоторое симуляторе это выяснит, но оно не является стандартным.

Вторая проблема заключается в том, что вы неоднократно выставляете одно и то же выражение. симулятор, возможно, не видит это как новое выражение и больше не вызывает $ urandom. Попробуйте поставить инструкцию release перед каждым force.

forever @(posedge trigger) begin 
     release dut.a; force dut.a = $urandom_range('hFF); 
     release dut.b; force dut.b = $urandom_range('hF); 
     release dut.c; force dut.c = $urandom_range('hFF); 
     release dut.d; force dut.d = $urandom_range('hF); 
     release dut.e; force dut.e = $urandom_range('hFF); 
     release dut.f; force dut.f = $urandom_range('hF); 
    end 
+0

Хороший улов с перевернутым диапазоном. Я попытался высвободить сигналы, но не повезло. Фактически, когда блок повторно запускается, сигналы обновляют до новых случайных значений ... это просто, что выбранные значения одинаковы. – chinocolerico

0

Я столкнулся с очень похожей проблемой с «urandom_range» как OP, используя NCSIM. Однако «уранд» работал просто отлично. Не должно быть причин, по которым «urandom» не должен работать в вашем случае вместо «urandom_range» (если предположить, что «urandom» работает правильно, конечно). Результат «urandom» будет просто усечен.

ИНФОРМАЦИЯ ОБ ИСТОРИИ: на всякий случай кому-то интересно, я столкнулся с ошибкой в ​​NCSIM относительно «urandom_range» (но не «urandom»), где первый вызов функции всегда возвращал минимальное заданное значение независимо от того, какие. Но все последующие звонки работали нормально.

+0

Я добавил дополнительную информацию по моему вопросу, надеюсь, что это поможет – chinocolerico

Смежные вопросы