[Golikov 0]

только мы уже обсуждали, что это не правила verilog, а скорее правило конкретного семейства синтезаторов, фирм и так далее... Некая негласная договоренность или я что-то не так понял?

 

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

 

как кнопка самоликвидации зеленого цвета%)

[SM 14]

Я согласен с тем что ошибка вызвана неопытностью

 

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

 

http://www.cis.upenn.edu/~milom/cse372-Spr.../xilinx/xst.pdf - стр. 71-73

http://www.altera.com/literature/hb/qts/qts_qii51007.pdf - стр. 12-36...12-37

http://homepages.cae.wisc.edu/~ece554/webs...docs/hdlref.pdf - стр. 6-32

http://book.huihoo.com/pdf/crafting-a-chip...sys/hdlcv_6.pdf - 6-35...6-36

 

Ну и т.д., документов на эту тему, как правильно писать синтезируемые описания на Verilog, хренова туча на каждом углу. Все они учат одному и тому же. И эти примеры должен знать каждый HDL-разработчик наизусть! Гугль в руки, если лекции пропустили. Не надо ничего изобретать самому, надо делать так, как надо.

[topor_topor 0]

cadence Encounter так понял код:

module DFFEA
(
    aload, 
    adata,    
    clk,
    sdata,    
    Q
);
input  aload, adata;
input  clk, sdata;
output Q;

reg Q;

always @(posedge clk or posedge aload)
begin
   if(aload == 1'b1)
     Q <= adata;
   else
     Q <= sdata;
end

endmodule

2 флопа и муксы не вышло как в примере....

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;

Получившаяся схема плоха тем, что после SP&R может случится так, что на оба R и S входы тригера будет подан активный уровень втечение времени почти равному 1 CLK (при дефолтных STA констрейнах и в худшем конечно случае)

Схема кстати совпадает с примером http://book.huihoo.com/pdf/crafting-a-chip...sys/hdlcv_6.pdf Figure 6-15

[SM 14]

cadence Encounter так понял код:

 

А он так и должен был понять. Как и Synopsys DC делает (это, кстати, прямо в его документации написано и нарисовано, см. мои ссылки). Потом, P&R все грамотно разведет с учетом времен removal и recovery - таков подход к синтезу такой схемы для ASIC, если нет элемента с aload...

 

Lattice нагородил латчей с мультиплексорами лишь потому, что у него нету в арсенале триггеров, у которых есть одновременно и сброс, и установка асинхронные. В латисе один вход есть асинхронный, программируемый либо на reset, либо на set, поэтому там без вариантов такое сложное решение.

 

Кстати, если бы в технологической либе к энкаунтеру не было бы триггера с S и R одновременно, вот тогда, может быть, он бы тоже сделал схему с муксом (у меня это synplify сделал).

 

Кстати2 - я такую схему тут тоже описывал, как вариант реализации - http://electronix.ru/forum/index.php?showt...t&p=1276370

[topor_topor 0]

А он так и должен был понять.

Вопрос в том эквивалентно ли это DFFEA

Ибо после SP&R, как я говорил, на оба R и S входы тригера может быть подан активный уровень втечение времени почти равному 1 CLK, соотв. Q в метастабилности.....

Пропагейшен делей from ADATA\ALOAD to RN может быть почти на 1 CLK больше чем to SN

 

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

Кстати

кеденс енкаунтер может синтезить

module DFFEA
(
    aload,
    adata,    
    clk,
    sdata,    
    Q
);
input  aload, adata;
input  clk, sdata;
output Q;

reg Q;

always @(posedge clk or posedge aload)
begin
   if(aload == 1'b1)
     Q <= adata;
   else
     Q <= sdata;
end

endmodule

только если есть в библиотеке тригер с асинхронным СЕТОМ и РЕСЕТОМ.

Если есть только тригер с РЕСЕТОМ (или только сетом) или вообще без асинхронных вховов то:

Error : Unable to map design without a suitable flip-flop. [MAP-2] [synthesize]

: Instance 'Q_reg' requires an async preset, async clear flip-flop.

[Golikov 0]

Получившаяся схема плоха тем, что после SP&R может случится так, что на оба R и S входы тригера будет подан активный уровень втечение времени почти равному 1 CLK

 

можно чуть подробнее почему так?

[topor_topor 0]

можно чуть подробнее почему так?

Пропагейшен делей from ADATA\ALOAD to RN может быть почти на 1 CLK больше\меньше чем to SN при дефолтным STA установках SP&R

 

[Golikov 0]

я не понимаю как в этом деле клок замешан? Типа без явного указания сколько может сигнал распространяться проверяться будет что не дольше клока что ли? Об этом речь?

[topor_topor 0]

я не понимаю как в этом деле клок замешан? Типа без явного указания сколько может сигнал распространяться проверяться будет что не дольше клока что ли? Об этом речь?

тулзы аднака независимо от того что вы нарисовали в верилоге (хоть одну комбинаторику, хоть асинхронный латч) всё равно считают дизайн строго синхронным, а значит и клок надо указать и все задержки будут выполнены в соответствие с STA правилами, хоть вы задавали их констрейнами хоть нет (т.е. по дефолтным установкам, кстати немного разным в разных тулзах...)

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

 

[SM 14]

Пропагейшен делей from ADATA\ALOAD to RN может быть почти на 1 CLK больше\меньше чем to SN при дефолтным STA установках SP&R

 

А с какого перепуга то? При работе с асинхронными загрузками (даже просто латчами, а не только такими хитрыми триггерами), и правильных опциях и констрейнах у синтезатора и P&R, все aload-ы рассматриваются как клоки, соотв. и распространение aload->RN и aload->SN будут оптимизироваться по правилам клокодеревьев (конкретно, это "gated clock получается"), а значит, больше, чем на clock skew, им разбежаться не удастся. А adata будет проанализирован как данное относительно клока aload. Главное тут - правильно указать опции, и все будет ОК. Я лично синтезировал проекты в ASIC (а энкаунтером именно их делают, а не FPGA), где было задействовано под тысячу aload-ов (латчи и вообще асинхронщина заметно экономят area супротив полностью синхронных FF-ов, а такие FF-ы с асинхронной загрузкой я использовал в счетчиках, которые считают по одному клоку, а грузятся из ядра процессора по aload). Короче, просто "их надо уметь готовить".

 

А вот то, что энкаунтер не шмог синтезировать то, что synplify с закрытыми глазами делает (схему с латчем и муксом), это меня не особо удивило. Кэденс в синтезе всегда сзади от синопсиса плелся, в отличие от P&R, где они соревнуются на одном уровне. А, с другой стороны, я и ни разу еще не видел техн. либ для ASIC без FF-ов с RN и SN одновременно, поэтому синтезаторам для ASIC это простительно.

[Des333 0]

только мы уже обсуждали, что это не правила verilog, а скорее правило конкретного семейства синтезаторов, фирм и так далее... Некая негласная договоренность или я что-то не так понял?

 

1364.1-2002 - IEEE Standard for Verilog Register Transfer Level Synthesis

 

5.2.2.1 Edge-sensitive storage device modeling with asynchronous set-reset

 

 

IEEE_Std_1364.1_2002.pdf

[SM 14]

5.2.2.1 Edge-sensitive storage device modeling with asynchronous set-reset

 

К сожалению, это не распространяется на асинхронную загрузку. Только на set/reset

[topor_topor 0]

А с какого перепуга то? При работе с асинхронными загрузками (даже просто латчами, а не только такими хитрыми триггерами), и правильных опциях и констрейнах у синтезатора и P&R, все aload-ы рассматриваются как клоки, соотв. и распространение aload->RN и aload->SN будут оптимизироваться по правилам клокодеревьев (конкретно, это "gated clock получается"), а значит, больше, чем на clock skew, им разбежаться не удастся. А adata будет проанализирован как данное относительно клока aload.

Короче, просто "их надо уметь готовить". - 100%

 

1) "aload-ы рассматриваются как клоки" - да (именно так они описываются в LIB)

2) "распространение aload->RN и aload->SN будут оптимизироваться по правилам клокодеревьев" - нет

В нашем случае мы не имеем дела с ALOAD, а имеем дело с RN\SN в результате синтеза. См. схему выше.

RN\SN - это данные относительно CLK. так оно по дефолту обычно и есть.

3) Как я показал (надеюсь теперь вы согласны) - DFFEA и синтеззённая схема выше - не одно и то-же.

С DFFEA - нет проблем.

А вот чтобы схема заработала эквивалентно DFFEA - надо те самые "правильных опциях и констрейнах у синтезатора и P&R"

Вот это и есть ключевой момент :)

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

[Golikov 0]

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

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

 

Смешно ей богу. Ваше мышление в элементах посильнее моего в поведении, только вы никак не можете об элементе договориться. Разные синтезаторы - разные схемы, а поведение одно....

[SM 14]

В нашем случае мы не имеем дела с ALOAD, а имеем дело с RN\SN в результате синтеза. См. схему выше.

RN\SN - это данные относительно CLK. так оно по дефолту обычно и есть.

 

RN/SN по дефолту именно асинхронные - по дефолту анализ recovery/removal, обычно, выключен вообще. А setup/hold таймингов у этих пинов нет.

 

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

 

То есть да, бывают редкие случаи, когда, почему-то, синтезатор/STA не проанализировал эту схему с SN/RN как ендпойнт клока, и тогда ему надо помочь руками. Но, как правило, оно само все получается, так как, как правило, на этом же инициаторе aload-а висят еще кучи разных других латчей.

 

 

а поведение одно....

 

Если бы... Речь ушла в ASIC, а там из-за этих "нюансов" можно попасть на лимон-другой у.е. на пустом месте... Который, если что, вычтут из зарплаты "горе-программиста", не догадивающегося о таких "мелочах". Это Вам не месяц-другой потрахаться с метастабильностью в фпга за положенную зарплату, делая видимость умной работы.

Да и "программистам на верилоге" похрену на то, что "оно" потом засбоит в условиях крайнего севера через год на другой партии ФПГА. Ведь "программу" поправить можно. А тут ничего нельзя поправить - надо делать сразу как надо.