[SM 0]

какие констрейны надо написать, чтобы указать, что время на прохождение сигнала от внешнего входа AS до входа триггера, не менее t_min и не более t_max(где t_min и t_max некоторые числовые константы)?

 

"set_max_delay -from порт -to регистр" и "set_min_delay -from порт -to регистр"

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

 

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

 

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

[Timmy 1]

"set_max_delay -from порт -to регистр" и "set_min_delay -from порт -to регистр"

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

Случаи всякие бывают. Я делал в FPGA эмулятор асинхронной памяти, управляемой микроконтроллером. В частности, входные сигналы синхронизировались, подавались на BRAM, а результат обратно на пины. И задержку по асинхронным цепям надо было, во-первых, ограничить, а во-вторых, точно знать максимальное значение задержки, чтобы научно рассчитать тайминги для контроллера RAM(который в микроконтроллере). set_max_delay/set_min_delay могут описывать асинхронный путь только между внешними портами, а если вклинивается триггер, то они описывают только синхронный путь с учётом клоковых задержек для launch и latch clocks. В нашем случае launch clock берётся со смещением 0, а latch - как повезёт. На практике я просто подгонял задержку под смещение latch clock, которое ещё и плавает в зависимости от fast/slow модели, но это как раз кривое решение, а хотелось бы попрямее.

 

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

Просто Таймквест не учитывает, что частота на выходе XOR будет в два раза выше.

[SM 0]

set_max_delay/set_min_delay могут описывать асинхронный путь только между внешними портами

Это не так. set_min/max_delay описывает любой асинхронный путь откуда угодно, и куда угодно, и не привязано к клокам вообще. просто надо уметь их готовить. Я ими , например, констрейнил пути между асинхронных доменов внутри ПЛИС, с целью, чтобы просто они не были слишком длинными, не вносили лишних тормозов (больше, чем пол-периода клока). Вообще без входных и выходных пинов. От пина Q одного DFF до пина D другого DFF.

 

 

Просто Таймквест не учитывает, что частота на выходе XOR будет в два раза выше.

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

[Timmy 1]

Это не так. set_min/max_delay описывает любой асинхронный путь откуда угодно, и куда угодно, и не привязано к клокам вообще. просто надо уметь их готовить. Я ими , например, констрейнил пути между асинхронных доменов внутри ПЛИС, с целью, чтобы просто они не были слишком длинными, не вносили лишних тормозов (больше, чем пол-периода клока). Вообще без входных и выходных пинов. От пина Q одного DFF до пина D другого DFF.

Хорошо, вот простой топовый модуль:

module async(clk1, clk2, i, o);
input clk1, clk2, i;
output reg o;
reg r1;
always @(posedge clk1) r1 <= i;
always @(posedge clk2) o <= r1;
endmodule

и sdc:

set_time_format -unit ns -decimal_places 3
create_clock -name {clk1} -period 10.000 -waveform { 0.000 5.000 } [get_ports {clk1}] -add
create_clock -name {clk2} -period 8.000 -waveform { 0.000 4.000 } [get_ports {clk2}] -add

set_output_delay -add_delay -max -clock [get_clocks {clk2}]  2.000 [get_ports {o}]
set_output_delay -add_delay -min -clock [get_clocks {clk2}]  -2.000 [get_ports {o}]

#set_clock_groups -exclusive -group [get_clocks {clk1}] -group [get_clocks {clk2}] 

#set_max_delay -from  [get_keepers {r1}]  -to  [get_keepers {o}] 0.0200
set_max_delay -from [get_pins {r1|regout}] -to [get_pins {o|datain}] 2
set_min_delay -from [get_pins {r1|regout}] -to [get_pins {o|datain}] -3

#set_max_delay -from [get_ports {i}] -to [get_pins {r1|datain}] 3
set_max_delay -from [get_ports {i}] -to [get_keepers {r1}] 3
set_min_delay -from [get_ports {i}] -to [get_keepers {r1}] -1

Путь i -> r1 анализируется с учётом clk1 и в текущем и в откоментированном вариантах(где get_pins {r1|datain}).

Путь r1 -> o в текущем варианте анализируется опять же с учётом clk1,clk2, а если раскомментировать set_clock_groups, то не игнорируется, но и не анализируется. Пожалуйста, подскажите кто-нибудь, как надо правильно делать, чтобы анализировались только асинхронные пути без клоков.

 

[SM 0]

Ну квартуса нету у меня на данный момент времени. Прямо сейчас показываю на примере Lattice Diamond. Модуль Ваш (только добавил // synthesis syn_useioff=0 на оба регистра, чтобы маппер не совал триггеры в I/O и мог править холды, иначе говорит, что violation hardwired и досвидания) . Констрейны (в переводе на латис):

 

FREQUENCY PORT "clk1" 60.000000 MHz;
FREQUENCY PORT "clk2" 70.000000 MHz;
USE PRIMARY PURE NET "clk1_c";
USE PRIMARY PURE NET "clk2_c";


MAXDELAY FROM PORT i TO CELL r1 5.000000 ns MIN 1 ns;

 

Что видим в результате:

 

во первых, в процессе разводки:

There are 1 hold time violations, the optimization is running ...
End of iteration 0
5 successful; 0 unrouted;  real time: 22 secs 

Hold time optimization iteration 1:
All hold time violations have been successfully corrected in speed grade M

 

сразу понятно, что констрейн работает, чтобы MIN выполнился, роутеру пришлось постараться отдельно.

 

смотрим отчеты тайминг анализатора:

 

setup/max:

Preference: MAXDELAY FROM PORT "i" TO CELL "r1" 5.000000 ns MIN 1.000000 ns ;
           1 item scored, 0 timing errors detected.
--------------------------------------------------------------------------------


Passed: The following path meets requirements by 1.074ns

Logical Details:  Cell type  Pin type       Cell/ASIC name  (clock net +/-)

  Source:         Port       Pad            i
  Destination:    FF         Data in        r1  (to clk1_c +)

  Delay:               3.778ns  (27.8% logic, 72.2% route), 1 logic levels.

Constraint Details:

     3.778ns physical path delay i to SLICE_1 meets
     5.000ns delay constraint less
     0.148ns M_SET requirement (totaling 4.852ns) by 1.074ns

Physical Path Details:

     Data path i to SLICE_1:

  Name    Fanout   Delay (ns)          Site               Resource
PADI_DEL    ---     1.049         77.PAD to       77.PADDI i
ROUTE         1     2.729       77.PADDI to     R14C28C.M0 i_c
                 --------
                   3.778   (27.8% logic, 72.2% route), 1 logic levels.

 

hold/min:

reference: MAXDELAY FROM PORT "i" TO CELL "r1" 5.000000 ns MIN 1.000000 ns ;
           1 item scored, 0 timing errors detected.
--------------------------------------------------------------------------------


Passed: The following path meets requirements by 0.019ns

Logical Details:  Cell type  Pin type       Cell/ASIC name  (clock net +/-)

  Source:         Port       Pad            i
  Destination:    FF         Data in        r1  (to clk1_c +)

  Delay:               1.005ns  (29.2% logic, 70.8% route), 1 logic levels.

Constraint Details:

     1.005ns physical path delay i to SLICE_1 meets
    -0.014ns M_HLD and
     1.000ns delay constraint requirement (totaling 0.986ns) by 0.019ns

Physical Path Details:

     Data path i to SLICE_1:

  Name    Fanout   Delay (ns)          Site               Resource
PADI_DEL    ---     0.293         77.PAD to       77.PADDI i
ROUTE         1     0.712       77.PADDI to     R14C28C.M0 i_c
                 --------
                   1.005   (29.2% logic, 70.8% route), 1 logic levels.

Report:    1.005ns is the minimum delay for this preference.

 

видим, что анализируются только задержки от порта до регистра, а никакие задержки распространения клоков в расчете не участвуют. Правда, в расчете участвуют M_SET и M_HLD, но об этом предупреждено документацией, и констрейн можно скорректировать на это значение, если нужно. В общем, что хотели, то и обконстрейнили.

 

 

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

 

UPD.... дальше...

 

добавляем констрейнов:

CLKSKEWDIFF  CLKPORT "clk1" CLKPORT "clk2" 0;
MAXDELAY FROM CELL r1 TO CELL o 5.000000 ns MIN 1 ns;

 

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

второй - задаем параметры пути.

 

смотрим... уже 2 холда стало... логично. :

 

Hold time optimization iteration 0:
There are 2 hold time violations, the optimization is running ...

 

смотрим setup/max по новому констрейну:

===============================================================================
Preference: MAXDELAY FROM CELL "r1" TO CELL "o" 5.000000 ns MIN 1.000000 ns ;
           1 item scored, 0 timing errors detected.
--------------------------------------------------------------------------------


Passed: The following path meets requirements by 0.949ns

Logical Details:  Cell type  Pin type       Cell/ASIC name  (clock net +/-)

  Source:         FF         Q              r1  (from clk1_c +)
  Destination:    FF         Data in        o  (to clk2_c +)

  Delay:               3.903ns  (9.8% logic, 90.2% route), 1 logic levels.

Constraint Details:

     3.903ns physical path delay SLICE_1 to SLICE_0 meets
     (delay constraint based on source clock period of 16.666ns and destination clock period of 14.285ns)
     5.000ns delay constraint less
     0.000ns skew and
     0.148ns M_SET requirement (totaling 4.852ns) by 0.949ns

Physical Path Details:

     Data path SLICE_1 to SLICE_0:

  Name    Fanout   Delay (ns)          Site               Resource
REG_DEL     ---     0.383    R14C28C.CLK to     R14C28C.Q0 SLICE_1 (from clk1_c)
ROUTE         1     3.520     R14C28C.Q0 to     R14C28A.M0 r1 (to clk2_c)
                 --------
                   3.903   (9.8% logic, 90.2% route), 1 logic levels.

Clock Skew Details: 

     Source Clock Path clk1 to SLICE_1:

  Name    Fanout   Delay (ns)          Site               Resource
PADI_DEL    ---     1.049         61.PAD to       61.PADDI clk1
ROUTE         1     1.233       61.PADDI to    R14C28C.CLK clk1_c
                 --------
                   2.282   (46.0% logic, 54.0% route), 1 logic levels.

     Destination Clock Path clk2 to SLICE_0:

  Name    Fanout   Delay (ns)          Site               Resource
PADI_DEL    ---     1.049         56.PAD to       56.PADDI clk2
ROUTE         1     1.233       56.PADDI to    R14C28A.CLK clk2_c
                 --------
                   2.282   (46.0% logic, 54.0% route), 1 logic levels.

 

Видим, что все логично, только в расчете участвует clock skew (а не сами клоки и их периоды!!!!), об этом мы знали заранее.

 

смотрим hold/min:

 

Preference: MAXDELAY FROM CELL "r1" TO CELL "o" 5.000000 ns MIN 1.000000 ns ;
           1 item scored, 0 timing errors detected.
--------------------------------------------------------------------------------


Passed: The following path meets requirements by 0.013ns

Logical Details:  Cell type  Pin type       Cell/ASIC name  (clock net +/-)

  Source:         FF         Q              r1  (from clk1_c +)
  Destination:    FF         Data in        o  (to clk2_c +)

  Delay:               0.999ns  (12.0% logic, 88.0% route), 1 logic levels.

Constraint Details:

     0.999ns physical path delay SLICE_1 to SLICE_0 meets
     (delay constraint based on source clock period of 16.666ns and destination clock period of 14.285ns)
    -0.014ns M_HLD and
     1.000ns delay constraint less
     0.000ns skew requirement (totaling 0.986ns) by 0.013ns

Physical Path Details:

     Data path SLICE_1 to SLICE_0:

  Name    Fanout   Delay (ns)          Site               Resource
REG_DEL     ---     0.120    R14C28C.CLK to     R14C28C.Q0 SLICE_1 (from clk1_c)
ROUTE         1     0.879     R14C28C.Q0 to     R14C28A.M0 r1 (to clk2_c)
                 --------
                   0.999   (12.0% logic, 88.0% route), 1 logic levels.

Clock Skew Details: 

     Source Clock Path clk1 to SLICE_1:

  Name    Fanout   Delay (ns)          Site               Resource
PADI_DEL    ---     0.440         61.PAD to       61.PADDI clk1
ROUTE         1     0.300       61.PADDI to    R14C28C.CLK clk1_c
                 --------
                   0.740   (59.5% logic, 40.5% route), 1 logic levels.

     Destination Clock Path clk2 to SLICE_0:

  Name    Fanout   Delay (ns)          Site               Resource
PADI_DEL    ---     0.440         56.PAD to       56.PADDI clk2
ROUTE         1     0.300       56.PADDI to    R14C28A.CLK clk2_c
                 --------
                   0.740   (59.5% logic, 40.5% route), 1 logic levels.

Warning:   0.999ns is the minimum delay for this preference.

 

видим, и тут все как надо. Все обконстрейнено безотносительно клока.

 

 

 

PS

Я думаю, что если внимательно разобраться в отчетах анализатора квартуса, то, скорее всего, там тоже, что-то типа того должно быть, что клоки анализируются, но только на перекос, и учитываются DI_SET/DI_HLD триггеров. Квартус попродвинутее латиса будет на порядок, года три-четыре назад я с ним работал и констрейны меж доменов FF-FF точно писал! (это нужно было для прототипа заказной ИМС) Собственно, set_max_delay изначально придумал Synopsys DC и PrimeTime, и там он работает именно так, как положено (я пользовался, завтра, если интересно, могу показать отчеты из Synopsys, доступ к нему у меня есть).

[Timmy 1]

Ну квартуса нету у меня на данный момент времени. Прямо сейчас показываю на примере Lattice Diamond. Модуль Ваш (только добавил // synthesis syn_useioff=0 на оба регистра, чтобы маппер не совал триггеры в I/O и мог править холды, иначе говорит, что violation hardwired и досвидания) .

Спасибо, но про Латтис и Ксайлинкс я знаю, интересно именно для Альтеры. Читал статью, где автор решал данную задачу с помощью set_max/min_delay, создавая виртуальные копии всех клоков, и с помощью специальной команды обнулял задержки всем виртуальным клокам. Проблема в том, что в Квартусе команда обнуления clock delays не реализована, статья, очевидно, писалась для оригинального Синопсиса. А без обнуления клоковых задержек set_max/min_delay в принципе работают, но кривенько.

Дополню: в моем вышеприведённом варианте путь r1->o по умолчанию анализируется командой [report_timing -setup -from {r1} -to {o~reg0} -from_clock {clk1} -to_clock {clk2} -panel_name "Report Timing (Worst-Case Path)" ], которая работает с клоками, что естественно, так как они не описаны, как асинхронные. Если же включить clock_groups, то set_max_delays теоретически должна описать асинхронную задержку, как в случае асинхронного пути между портами, однако для внутренних пинов, в отличие от портов, set_max_delays не учавствует в анализе(можно ставить любое значение задержки в плюс/минус, ошибки не будет), хотя и не игнорируется. Возможно, что у Синопсиса такой вариант(который мне представляется наиболее прямым) работает, в отличие от Альтеры.

Изменено 30 января, 2014 пользователем Timmy

[SM 0]

Если же включить clock_groups, то set_max_delays теоретически должна описать асинхронную задержку,

 

вот тут как раз не так - если включить clock_groups, то это будет эквивалент множеству set_false_path всем путям из домена в домен, что просто отключит весь анализ - false path имеет приоритет выше всех max_delay, так что, логично, что он перестает работать. Именно поэтому я латису задавал CLKSKEWDIFF - так как у латиса по умолчанию все такие клоки асинхронные, анализ таких путей выключен и его надо включать руками

 

А приведите отчет анализатора, интересно посмотреть. Разве таймквестом нельзя проанализировать не сетап, а именно max_delay от пада до пина?

 

а у ксилинкса, по крайней мере у ISE, оказалось, что вообще MIN никак не задать для выходных сигналов, даже для clock-to-out. Там облом полный с нормальными констрейнами, недавно обсуждение было, как там хотя бы холд обконстрейнить. Говорят, в виваде сделали...

[topor_topor 0]

Никакой констрейн не нужен вообще в этом случае. И set_false_path тоже - он предназначен для убирания конкретного пути из множества обконстрейненных, так что, сам по себе констрейном не является.

А что делает анализатор если никакой констрейн не задан для пути?

Не по дефолтным-ли правилам (по дефолтному констрейну) он его обрабатывает?

Если по дефолтному, то что это за дефолтный констрейн интересно узнать....

 

[Timmy 1]

вот тут как раз не так - если включить clock_groups, то это будет эквивалент множеству set_false_path всем путям из домена в домен, что просто отключит весь анализ - false path имеет приоритет выше всех max_delay, так что, логично, что он перестает работать. Именно поэтому я латису задавал CLKSKEWDIFF - так как у латиса по умолчанию все такие клоки асинхронные, анализ таких путей выключен и его надо включать руками

 

А приведите отчет анализатора, интересно посмотреть. Разве таймквестом нельзя проанализировать не сетап, а именно max_delay от пада до пина?

 

а у ксилинкса, по крайней мере у ISE, оказалось, что вообще MIN никак не задать для выходных сигналов, даже для clock-to-out. Там облом полный с нормальными констрейнами, недавно обсуждение было, как там хотя бы холд обконстрейнить. Говорят, в виваде сделали...

Вручную проанализировать max_delay я могу, не могу его правильно оконстрейнить. Вот анализ, тут всё нормально:

report_path -from [get_ports {i}] -to [get_pins {r1|datain}] -npaths 1
Info: Path #1: Delay is 3.365
    Info: ===================================================================
    Info: From Node    : i
    Info: To Node      : r1|datain
    Info: 
    Info: Path:
    Info: 
    Info: Total (ns)  Incr (ns)     Type  Element
    Info: ==========  ========= ==  ====  ===================================
    Info:      0.000      0.000           i
    Info:      0.870      0.870 RR  CELL  i|combout
    Info:      3.216      2.346 RR    IC  r1~feeder|datad
    Info:      3.365      0.149 RR  CELL  r1~feeder|combout
    Info:      3.365      0.000 RR    IC  r1|datain
    Info: 
    Info: Total Path Delay :     3.365
    Info: ===================================================================
    Info:

А set_max_delay с теми же конечными точками подвязывается ещё и к clk1, хотя, казалось бы, для синхронных констрейнов предназначен set_input_delay.

 

[EgorT 0]

Я помню, задавал я set_max_delay и set_min_delay между регистрами, чтобы подвинуть их поближе друг к другу, так ни таймквест (не ругался), ни квартус (не двигал) на это никак не реагировал. Сейчас может еще раз попробую.

 

 

Ну а чтобы избавиться от распространения "Х" в моделировании надо добавить +no_notifier.

http://electronix.ru/forum/index.php?showtopic=86076

[Timmy 1]

Я помню, задавал я set_max_delay и set_min_delay между регистрами, чтобы подвинуть их поближе друг к другу, так ни таймквест (не ругался), ни квартус (не двигал) на это никак не реагировал. Сейчас может еще раз попробую.

В таком варианте set_max_delay позволяет переопределить интервал между launch и latch clocks, который по умолчанию в случае одного клока равен периоду клока. Длина пути при этом расчитывается с учётом разницы clock delays для источника и приёмника, а не чисто асинхронно.

[SM 0]

В таком варианте set_max_delay позволяет переопределить интервал между launch и latch clocks

 

Так по сути то это тоже самое, что задать просто констрейн на путь, только через ж. автогеном. Разница то это clock skew, который обычно микроскопический, и им можно либо пренебречь, либо учесть в констрейне. А прибавкой/вычитанием требований сетапов/холдов на внутренние регистры грешат все среды одинаково.

[Timmy 1]

Так по сути то это тоже самое, что задать просто констрейн на путь, только через ж. автогеном. Разница то это clock skew, который обычно микроскопический, и им можно либо пренебречь, либо учесть в констрейне. А прибавкой/вычитанием требований сетапов/холдов на внутренние регистры грешат все среды одинаково.

Разница - это clock2 delay - clock1 delay + clock skew, к сожалению, разница задержек может достигать чуть ли не 5 нс, и ещё на 1-2нс плавать в зависимости от модели. Я именно так и делал, с ручной компенсацией клоковых задержек в констрейне, но это не совсем точно и именно что через ж. автогеном. Ещё пробовал условным оператором ставить разные задержки в зависисти от модели, но это не работает, так как при сборке проекта SDC интепретируется только один раз для первой модели.

 

CLKSKEWDIFF CLKPORT "clk1" CLKPORT "clk2" 0;

MAXDELAY FROM CELL r1 TO CELL o 5.000000 ns MIN 1 ns;

Кстати, у Латтиса можно сделать лучше:

MAXDELAY FROM CELL "r1" TO CELL "o" 5.000000 ns min 1.0 ns DATAPATH_ONLY;

В результате CLKSKEWDIFF писать не надо, путь анализируется без участия клоков. Вот почему Альтера так не могёт, при том, что во всём остальном Таймквест на голову выше? :crying:

 

[SM 0]

В результате CLKSKEWDIFF писать не надо, путь анализируется без участия клоков

 

CLKSKEWDIFF не для того пишется, чтобы участия клоков убрать, а чтобы ВООБЩЕ ВКЛЮЧИТЬ любой тайминг анализ для цепей между указанными клок доменами. Без него MAXDELAY на эти пути игнорируется в любом виде, в отчете пишет 0 paths.

 

выписка из доки:

Two clock signals are defined as unrelated if they are not driven by the same clock input pad and you have not defined a relationship between them using the CLKSKEWDIFF preference.

 

Prior to ispLEVER 7.2, data transfers between unrelated clocks were reported as if those clocks were related and had a skew of 0. In ispLEVER 7.2 and later, data transfers between unrelated clocks are not reported. If you want to have those transfers reported, they must define a clock relationship between the two external clocks using the CLKSKEWDIFF preference. This updated behavior in TRACE avoids needlessly over-constraining a design. For example, data crossing between two asynchronous clocks should be analyzed during simulation. Static timing analysis cannot be used to guarantee proper operation. The former default constraint adds no value, and could negatively impact design performance.

 

то есть, начиная с ispLEVER 7.2, чтобы хоть что-то проанализировать между асинхронных доменов, надо указать CLKSKEWDIFF, а там дальше уже всякие MAXDELAY для чего надо, и BLOCK PATH для чего не надо. А по умолчанию теперь все домены асинхронные, если клоки не прямо в ПЛИС не делаются друг из друга (логикой, PLL, и т.п.)

 

за DATAPATH_ONLY спасибо, как-то я упустил его, вручную корректировал констрейны на M_SET/M_HLD/DI_SET/DI_HLD

[COMA 1]

Добрый день,

 

Есть описание схемы - 8-Bit Identity Comparator на Verilog:

 

assign eq_AB_n = (A[7:0] == B[8:0]) ? 1'b0 : 1'b1;

 

Как можно "обконстрейнить" такую конструкцию, чтобы обеспечить миниальную задержку межжду входами и выходами?