[topor_topor 0]

Я об этом тоже всегда говорю! От этого [почти] все беды, ошибки и тупые вопросы.

Не ну простые случаи нам не интересны... это я говорю задля направление тех кто только встал на этот склизкий путь...

По мне - DFFEA это как уши на пятках - неестественно и в жизни ненужно...

Но можно и этот изврат обсудить :) розвлечения для....

-------------

Переформулирую проблему.

 

1) У нас нашлось Verilog RTL описание которое приводит к синтезу именно в DFFEA.

lways @(posedge clk or posedge reset)
begin
   if(reset == 1'b1)
     signal <= init_val;
   else
     signal <= ~signal;
end

// init_val - NOT a constant!

 

2) Verilog UDP модель DFFEA - точна

3) Наше Verilog RTL описание симулится не так как работает DFFEA и его UDP модель потому, что init_val нет в списке чувствительности.

4) Вопрос - как создать Verilog RTL DFFEA чтобы и синтезилось и симулилось правильно?

 

Я правильно понимаю проблему?

 

[SM 0]

Я правильно понимаю проблему?

 

Вообще, IMHO неправильно. Вопрос был, как правильно описать этот блок для синтеза (а правильно именно так, с aload в списке чувсвительности, а adata - нет). А как обойти synthesis/simulation mismatch - вопроса не было, но я только что выше написал. Если, конечно, синтезатор это правильно поймет, и синтезирует именно DFFEA с использованием aload/adata. Но это уже все наша болтовня вне основной темы, но около нее.

[topor_topor 0]

....я только что выше написал. Если, конечно, синтезатор это правильно поймет, и синтезирует именно DFFEA с использованием aload/adata....

Вы имеете ввиду конструкцию

wire arst = aload && !data;
wire aset = aload && data;

always @(posedge clk or posedge arst or posedge aset)
if (arst)
  ff <= 1'b0;
else if (aset)
  ff <= 1'b1;
else if (ena)
  ff <= data;

думаю получится синхронный D тригер с клок енейбелом "ena" и асинхронными входами R\S + внешняя логика на них.

Я не одобряю wire arst = aload && !data; и wire aset = aload && data; - подача 2 активных сигналов одновременно приводит к метастабильности...

SP&R может (хоть и редко) но затянуть время 2 активных на целый CLK период (несмотря на то что кажется, что это время должно быть на уровне задержки на инверторе )....

[Golikov 0]

Передергиваете господа

 

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

 

никак не связано ни с мышлением схемой ни с мышлением поведением.

 

Проблема заключается в том, что описание

 

lways @(posedge clk or posedge reset)
begin
   if(reset == 1'b1)
     signal <= init_val;
   else
     signal <= ~signal;
end

 

в силу каких то причин стало при ресете == 1 менять сигнал в след за изменениями init_val не по клокам, а асинхронно. Это просто так принято и все, что такой блок делает такую схему и все. Это как исключение в грамматике и прочее... Да это приходит с опытом, но не меняет концепции мышления и не делает какой-то из путей невозможным.

 

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

 

А в этом случае я бы предпочел варнинг, что данная схема при асинхронном сигнале будет его менять. Или вообще на запрет не констант под ресет == 1.

 

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

[topor_topor 0]

Вопрос был, как правильно описать этот блок для синтеза (а правильно именно так, с aload в списке чувсвительности, а adata - нет).

...честно говоря как DFFEA описать на уровне Verilog RTL чтобы оно всеми тулзами однозначно и правильно синтезилось пока не знаю...

что делать синтезатору когда нет примитива DFFEA тож не могу особенно представить...

 

1) Как вариант можно разложить структуру DFFEA на части (FF & LATCH) и описать это всё Verilog RTL как модуль, правда и синтезится она будет с отдельных FF & LATCH.

это решение для случая когда нет примитива DFFEA.

2) Когда он есть - лутше прямая инстанциация.

3) в универсальном IP - define c инстанциацией либо примитива либо RTL модуля

4) Всегда-ли и у всех-ли тулзах однозначно получается DFFEA с описания

lways @(posedge clk or posedge reset)
begin
   if(reset == 1'b1)
     signal <= init_val;
   else
     signal <= ~signal;
end

..не уверен...особенно если в библиотеке нет примитива DFFEA то результаты могут быть вообще разные...

 

в силу каких то причин стало при ресете == 1 менять сигнал в след за изменениями init_val не по клокам, а асинхронно. Это просто так принято и все, что такой блок делает такую схему и все. Это как исключение в грамматике и прочее...

Кто-то может подтвердить что согласно Верилог стандарту это синтезится обязано именно так что "менять сигнал в след за изменениями init_val не по ЕДЖАМ, а асинхронно"?

Может так получается только в конкретном синтезаторе

[SM 0]

что делать синтезатору когда нет примитива DFFEA тож не могу особенно представить...

 

Синтезатор Lattice (synplify for Lattice), в условиях отсутствия аналога DFFEA, генерирует примерно вот такое (и оно работает):

 

wire latch_part = aload ? adata : latch_part;

reg ff_part;
always @(posedge clk)
  if (ena)
     ff_part <= sdata;

reg mux_part_ctrl;
always @(posedge clk or posedge aload)
   if (aload) mux_part_ctrl <= 1'b1;
   else mux_part_ctrl <= 1'b0;

wire reg_out = mux_part_ctrl ? latch_part : ff_part;

 

Кто-то может подтвердить что согласно Верилог стандарту это синтезится обязано именно так

 

Это так не по verilog стандарту, а по некоему принятому между производителями синтезаторов "стандарту" синтеза - и описано в synthesis coding guidelines у каждого из них (конкретно, для xilinx, я приводил тут ссылку, еще такое я читал у Synopsys для DC и для Synplify, за других поручиться не могу). И оно, лично мной проверено, работает с Synplify (lattice), Altera (quartus), Xilinx (xst, synplify), ASIC (Synopsys DC).

 

Проблема заключается в том, что описание

...

в силу каких то причин стало

 

Проблема заключается в том, что если описывать схему, зная и понимая, из чего и как она строится в железе, то этой проблемы, как и многих других (в т.ч. с метастабильностью, глитчами, логическими гонками, и т.п.), не будет изначально. То есть, это надуманная проблема, которой на самом деле нет, если ее самому себе специально не создавать придуманным "образом мышления".

[Golikov 0]

Это так не по verilog стандарту, а по некоему принятому между производителями синтезаторов "стандарту" синтеза

Вот это основное, и именно то что такое описание делает такой хитрый триггер - это привязано к производителю, синтезатору и среде. И если вам надо получить именно этот триггер, то надо лезть в описание синтезатора и глядеть как он описывается.

А если вам нужен сигнал с асинхронным сбросом или установкой, пишите такое описание и не думаете есть ли там такие триггеры в ПЛИС или нет, уверен что для плис без этих элементов синтезатор чего то придумает:)

 

А то что сигнал асинхронно будет выходить дальше - это бонус, отклочить сигнал всегда можно. Просто надо запомнить это.

 

 

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

а так вы ограничиваете себя от технологий. Строя схему из фиксированных элементов вы пропустите появление новых, и код будет не масштабируемым. Найдут ваш код через 200 лет, а он еле работает:) Описание поведение практичней:)

 

Но это очередная священная война...

[SM 0]

а так вы ограничиваете себя от технологий.

Это как раз Вы ограничиваете себя от технологий. Я, прежде чем начать описывать систему для той технологии (конкретная ПЛИС, или конкретная технология ASIC), которую выбрал для ее построения, очень подробно изучаю эту технологию, чтобы знать, что она позволяет, какие примитивы в ней имеются, какие особенности трассировки в ней, и т.п., и, в результате, как сделать тот или иной блок оптимальным именно под эту технологию. В результате чего получаю блоки, либо работающие быстрее, чем у конкурентов, либо, занимающие меньше места, за счет чего и получаю дивиденты в виде наличных денег :)

 

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

[Golikov 0]

Аминь... :)

 

у меня тоже если я за каким то диагностическим хреном частоту на входе в модуль на 2 не поделю тоже тьфу тьфу тьфу проблем нет%)

 

но кто бы как бы не делал, я уверен что делаю лучше:) так же думаю уверены и вы%)...

[topor_topor 0]

Синтезатор Lattice (synplify for Lattice), в условиях отсутствия аналога DFFEA, генерирует примерно вот такое (и оно работает):

 

wire latch_part = aload ? adata : latch_part;

reg ff_part;
always @(posedge clk)
  if (ena)
     ff_part <= sdata;

reg mux_part_ctrl;
always @(posedge clk or posedge aload)
   if (aload) mux_part_ctrl <= 1'b1;
   else mux_part_ctrl <= 1'b0;

wire reg_out = mux_part_ctrl ? latch_part : ff_part;

 

Случайно исходника того во что оно синтезилось віше нету?

Попробую у себя синтезнуть. Просто для однозначности сравнения результатов

 

[SM 0]

Случайно исходника того во что оно синтезилось віше нету?

Попробую у себя синтезнуть. Просто для однозначности сравнения результатов

 

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

А в исходнике было так, как там - http://electronix.ru/forum/index.php?showt...t&p=1276129

[Golikov 0]

кстати хорошее описание и понятное

 

wire latch_part = aload ? adata : latch_part;

reg ff_part;
always @(posedge clk)
  if (ena)
     ff_part <= sdata;

reg mux_part_ctrl;
always @(posedge clk or posedge aload)
   if (aload) mux_part_ctrl <= 1'b1;
   else mux_part_ctrl <= 1'b0;

wire reg_out = mux_part_ctrl ? latch_part : ff_part;

 

описывает именно то что должно быть с сигналом, а не специальный элемент который может это сделать, и которого может не быть.

[SM 0]

кстати хорошее описание и понятное

Плохое описание, и излишне длинное.

А) По нему ни квартус не ставит DFFEA, а огород глитчный городит, ни Synopsys DC не ставит триггеры с асинхронной загрузкой из технологической либы, тоже огород городит.

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

В) При наличии нужного элемента, эта конструкция проигрывает ему, и сильно проигрывает, как по времянкам, из-за мультиплексора на выходе, так и по area, два лута и два FF вместо всего одного FF.

[Golikov 0]

зависит от целей.

Если понятность и поддерживаемость проекта, то это описание превращающиеся в схему которая делает ровно то что написано гораздо лучше. Если нужен конкретный элемент, то лучше описывать его через инстанс, так опять понятнее что происходит, и по мне правильнее. Чем использовать что описание не совсем такое как кажется превращается почему то в него. Но это ИМХО

 

А длинна не проблема, запас буков в компутере неограничен.

[SM 0]

почему то

Только не "почему то", а по правилам синтезируемого подмножества Verilog.

Как раз для понятности и поддерживаемости следует применить конструкцию, положенную по правилам, которая по этой причине сразу понятна всем (кто аккуратно изучал синтезируемое подмножество Verilog), чем городить путаную схему с мультиплексором, в которую без поллитры не въедешь.