Разглядывая различные дизайны встретил вот такого типа конструкцию:

always @(posedge clk) R12 <= L11;
...
...
always @(posedge clk) L11<=R17;

Показалось, что рискованно устанавливать сигнал на фронте и на том же фронте его использовать.
Я прав?

В других же дизайнах аналогичного вида конструкция имела вид:

always @(posedge clk) R12 <= #1 L11;
...
always @(posedge clk) L11 <= #1 R17;

Здесь явно пытались решить эту как раз проблему задержав изменение сигнала на некий момент после его использования.

Собственно два вопроса:
1. Достаточно ли в таких случаях одной единицы времени и как понять, если недостаточно?
2. Почему не используется (привычное мне "разведение" сигналов типа

always @(posedge clk) R12<= L11;
...
always @(negedge clk) L11<=R17;
Есть в этом решении какие-то подводные камни?

1. В поиске найдете тему, где обсуждали добавление #1 . Там вроде описана суть этой "заплатки"
2. Это аналогично работе на удвоенной частоте для синхроного дизайна. Камни думаю - это усложнение оценки адекватной частоты работы дизайна.

Используя posedge вы выбираете триггеры типа Flip-flop. Их отличительная черта, это отсутствие времени удержания входного сигнала после фронта, т.е. сразу за фронтом сигнал может изменится, но это уже не будет иметь значение.

При RTL моделировании изменение происходить сразу за фронтом на +1 цикл поделирования, а у всех триггеров фронты одновременно +0 цикл. поэтому в триггере фиксируется старое значение. Иногда добавляют #1 но это только для наглядности, с такими вещами лучше оценивать зависимости в комбинаторике.

В реальной жизни обеспечить приход фронтов на все триггера невозможно, но с помощью деревьев клока, или спец трассировочных ресурсов разбежку клоковых фронтов делают не более времени распространения выходных сигналов. Т.е. после фронта сигнав в реальной схеме на выходе триггера переключится не мгновенно, а через известный параметр D, так вот разбежку фронтов клока делают такой что бы она была меньше D.

Вообщем, в ПЛИС синтезатор за вас решит эту задачу так что если комбинаторика успевает то схема будет в ПЛИС работать так же как и в RTL модели. В заказных схемах немного посложней. Но тоже большую часть на себя берет САПР.

Делая ступень триггеров по фронту, другую ступень по срезу - вы на самом деле сокращаете в два раза время для срабатывания комбинаторики, т.е. да, схема фактически будет надежней, но медленей.

Еще лично встречал разное поведение двух фирменных симуляторов в порядке обработки присвоений в одном дельта цикле. Так что можно сказать и наглядность для Программы



Противоречите "сокращаете в два раза время для срабатывания" и "медленей".
Вопрос был про последовательные присвоения - по сути конвейер.
По факту будет, что логика должна успеть сработать в полпериода (спад - это обычно 50% периода), а не через период.

При синтезе #1 игнорируется.
Что касается моделирования - читайте Полякова. Там все качественно описано.
И для затравки. Это ответы на ваши вопросы.

Спасибо. Осознал. Пошёл учить матчасть дальше.

Тааак, это уже интересно.
Расскажите подробнее какие конкретно симуляторы вели себя по разному?

Приветствую!


В AldecHDL у меня такое периодически встречалось (версий 5.. 6.. , в 7 вроде пока не попадалось).
В основном это выражалось в записи в тригер значения которое по логике формировалось ПОСЛЕ фронта по которому происходила запись. Какой либо закономерности появления этих глюков я не нашел, да вобщем сильно и не искал (но в основном это были довольно большие проекты с несколькими десятками модулей) . Но крови это мне на паре проектов попортило очень много. Причем появление глюка иногда зависело от расположения строк текста в исходнике.

Успехов! Rob.

одно время пользовал везде

parameter Tp = 1;

reg <= #Tp a;


потом, с переходом на SV перестал, лениво писать.

Кстати по стандарту в always_ff/always_comb конструкций управления задержками быть не должно.

Если речь идет о синтезе, то причем здесь #1.
А с расположением строк текста в исходнике (синтез). Так это другая песня. И не глюк совсем.
В Верилоге можно использовать при описании два оператора (=, <=).
Можно получить разную схемную реализацию. Обычно в один период клока.
Если используют <=, то без разницы позиция строки в процессе.

module blokir_oper
(
input clk,
output reg out_a,
output reg out_b
);

reg [3:0] ct_a;
reg [3:0] ct_b;

always @(posedge clk) begin
out_a = ct_a[3];
ct_a = ct_a + 1'b1; end

always @(posedge clk) begin
ct_b = ct_b + 1'b1;
out_b = ct_b[3]; end

endmodule

Да вообщем-то логика разночтения оказалась понятна, если разобраться.

Симуляторы Актив и Моделсим.

Отличие было в разном подходе к компиляции проекта. И из-за этого по разному формировалась порядок присвоений в одном дельта цикле.

Это было в одном сложном тестбенче и как правильно сказал sazh происходило из-за связки - позиции присвоения в тексте модуля и использования блокирующего присваивания.

Но эта "неоднозначность" выявилась случайно только в другом симмуляторе.
Если правильно помню встретилась она при переходе переменной в цикле for generate, который был описан блокирующими присваиваниями. Вылечалась добавление "#1;" в начале.

Приветствую!

to sazh
Я имел ввиду именно глюк симулятора ActivtHDL при симуляции неблокирующих присваиваний.
упрощенно это выглядело так

reg rA,rB;

wire input_regA, inpul_regB;

assign inpul_regA= логика для регистра rA

always @(posedge clk)
rA <= input_regA;

assign input_regB= логика для регистра rB зависящая от rA;

always @(posedge clk)
rB <= input_regB;

При глюке в регистр rB записывалось значение которое получалось ПОСЛЕ записи значения в регистр rA;

При перестановки местами always блоков в исходном файле глюк мог не проявлятся.

Успехов! Rob.

К сожалению, в этой ветке двусмысленность.
Непонятно про А, rА или inpul_regA
Но не суть.
Спасибо. Единственно, что хочу добавить.
Такая полемика негативно влияет на неокрепшие умы.
Обсуждение глюков пакета - это следующий этап роста разработчика.

Вот за такую информацию СПАСИБО.
К этому симулятору буду относиться осторожно.


Когда собственные ошибки - это ладно. Когда найден глюк симулятора - это другое. Косвенно это может говорить о подходе к разработке и ТЕСТИРОВАНИЮ ПО. Об организации предприятия.

при полноценном переходе на СВ проблемы с гонками решаются автоматически (более продвинутая событийная модель). а так глюков хватает не только в Активе