Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Новичковое: тайминг
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
ReedCat
Разглядывая различные дизайны встретил вот такого типа конструкцию:

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

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

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

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

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

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

always @(posedge clk) R12<= L11;
...
always @(negedge clk) L11<=R17;
Есть в этом решении какие-то подводные камни?
Kopart
Цитата(ReedCat @ Jan 29 2008, 17:13) *
Собственно два вопроса:
1. Достаточно ли в таких случаях одной единицы времени и как понять, если недостаточно?
2. Почему не используется (привычное мне smile.gif "разведение" сигналов типа

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


1. В поиске найдете тему, где обсуждали добавление #1 . Там вроде описана суть этой "заплатки"
2. Это аналогично работе на удвоенной частоте для синхроного дизайна. Камни думаю - это усложнение оценки адекватной частоты работы дизайна.
-=Sergei=-
Цитата(ReedCat @ Jan 29 2008, 17:13) *
Разглядывая различные дизайны встретил вот такого типа конструкцию:

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

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

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

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

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

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

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



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

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

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

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

Делая ступень триггеров по фронту, другую ступень по срезу - вы на самом деле сокращаете в два раза время для срабатывания комбинаторики, т.е. да, схема фактически будет надежней, но медленей.
Kopart
Цитата(-=Sergei=- @ Jan 29 2008, 17:43) *
Иногда добавляют #1 но это только для наглядности, с такими вещами лучше оценивать зависимости в комбинаторике.

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


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

Противоречите "сокращаете в два раза время для срабатывания" и "медленей".
Вопрос был про последовательные присвоения - по сути конвейер.
По факту будет, что логика должна успеть сработать в полпериода (спад - это обычно 50% периода), а не через период.
sazh
Цитата(ReedCat @ Jan 29 2008, 17:13) *
always @(posedge clk) R12 <= #1 L11;
...
always @(posedge clk) L11 <= #1 R17;

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


При синтезе #1 игнорируется.
Что касается моделирования - читайте Полякова. Там все качественно описано.
И для затравки. Это ответы на ваши вопросы.
ReedCat
Спасибо. Осознал. Пошёл учить матчасть дальше. smile3046.gif
dvladim
Цитата(NiOS @ Jan 29 2008, 17:58) *
Еще лично встречал разное поведение двух фирменных симуляторов в порядке обработки присвоений в одном дельта цикле.

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


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

Успехов! Rob.
des00
одно время пользовал везде

parameter Tp = 1;

reg <= #Tp a;


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

Кстати по стандарту в always_ff/always_comb конструкций управления задержками быть не должно.
sazh
Цитата(RobFPGA @ Jan 29 2008, 23:51) *
Приветствую!
В AldecHDL у меня такое периодически встречалось (версий 5.. 6.. , в 7 вроде пока не попадалось).
В основном это выражалось в записи в тригер значения которое по логике формировалось ПОСЛЕ фронта по которому происходила запись. Какой либо закономерности появления этих глюков я не нашел, да вобщем сильно и не искал (но в основном это были довольно большие проекты с несколькими десятками модулей) . Но крови это мне на паре проектов попортило очень много. Причем появление глюка иногда зависело от расположения строк текста в исходнике.

Успехов! Rob.


Если речь идет о синтезе, то причем здесь #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
Kopart
Цитата(dvladim @ Jan 29 2008, 22:46) *
07.gif
Тааак, это уже интересно.
Расскажите подробнее какие конкретно симуляторы вели себя по разному?

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

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

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

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

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

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.
sazh
Цитата(RobFPGA @ Jan 30 2008, 14:12) *
to sazh

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


К сожалению, в этой ветке двусмысленность.
Непонятно про А, rА или inpul_regA
Но не суть.
Спасибо. Единственно, что хочу добавить.
Такая полемика негативно влияет на неокрепшие умы.
Обсуждение глюков пакета - это следующий этап роста разработчика.
dvladim
Цитата(RobFPGA @ Jan 30 2008, 14:12) *
Я имел ввиду именно глюк симулятора ActivtHDL при симуляции неблокирующих присваиваний.

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

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

Когда собственные ошибки - это ладно. Когда найден глюк симулятора - это другое. Косвенно это может говорить о подходе к разработке и ТЕСТИРОВАНИЮ ПО. Об организации предприятия.
CaPpuCcino
Цитата(dvladim @ Jan 30 2008, 23:25) *
Когда собственные ошибки - это ладно. Когда найден глюк симулятора - это другое.

при полноценном переходе на СВ проблемы с гонками решаются автоматически (более продвинутая событийная модель). а так глюков хватает не только в Активе
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.