[Dr.Alex 0]

Думаю понятно что set_max_delay здесь в контексте именно задания сетап/холда (потому я и сравниваю с set_input_delay), а то конечно им можно что угодно констрейнить.

 

Так в чём же разница?

 

 

[Shivers 0]

Разница принципиальная, что следует из названия. set_max_delay - контролирует длины любых арок графа.

А set_input_delay относится только к интерфейсам - часть графа, которая достраивается вокруг схемы на основе констрейнтов.

p.s.

set_max_delay обычно не используют, он избыточен, поскольку пути reg2reg контролируются периодом клока, а интерфейсы - input_delay/output_delay

[Dr.Alex 0]

Разница принципиальная, что следует из названия. set_max_delay - контролирует длины любых арок графа.

А set_input_delay относится только к интерфейсам - часть графа, которая достраивается вокруг схемы на основе констрейнтов.

p.s.

set_max_delay обычно не используют, он избыточен, поскольку пути reg2reg контролируются периодом клока, а интерфейсы - input_delay/output_delay

 

Но я же сразу сказал, что set_max_delay можно констрейнить что угодно,

но меня интересует только сетап/холд на входах.

 

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

и я как раз всегда использую set_max_delay для входов и выходов,

Поэтому, с моей точки зрения, как раз set_input_delay/output_delay это избыточный хлам.

 

Обратное возможно если кто-то всё-таки укажет на принципиальную разницу.

[yes 5]

разница в привязке set_input_delay к конкретному тактовому сигналу, а set_max_delay распространяется на все клоки, на те которые есть и которых еще даже и нет.

по-моему я уже писал, что для одного азика пришлось внутри возится с multicycle путями вместо того, чтобы описать min/max delay, так как команда бэкенда категорически не воспринимала min/max, аргументируя это тем, что сильно увеличивается время трассировки с такими констрейнами.

может это из-за оптимизации бд внутри синопсиса, а может и вообще лишние операции добавляются в пересчете min/max на период - не могу сейчас об этом подумать :)

[Shivers 0]

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

 

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

 

p.s. вот, меня опередили =)

[Dr.Alex 0]

set_max_delay распространяется на все клоки

Не понял.

Ведь я констрейню не что-то абстрактное, а путь от пина до триггера,

который тактируется конкретным клоком, единственным.

 

 

Для синхронных интерфейсов этот констрейнт совершенно бессмысленен

Совсем не понял.

Это значит что я вообще не могу им пользоваться.

Но я пользуюсь и вижу, что Вивада обходится с ним гораздо опрятнее чем с set_input_delay.

Клок скью учитывается? Учитывается. И всё остальное, что нужно чтобы законстрейнить сетап, тоже.

Так почему же он бессмысленен?

 

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

[Shivers 0]

Так почему же он бессмысленен?

Сделайте report_timing до входа Вашего триггера через входной пин. С set_input_delay получите честный синхронный путь с правильным launch clock и capture clock. А если наложен констрейнт set_max_delay то в репорте, насколько я понимаю (сам никогда такими экспериментами не занимался) должна получиться ерунда (асинхронный или анконстрейнед путь).

 

Еще момент - Вы check_timing делаете? По идее, если интерфейсы обконстрейнены через set_max_delay, то должны посыпаться ошибки.

 

[Dr.Alex 0]

Сделайте report_timing до входа Вашего триггера через входной пин. С set_input_delay получите честный синхронный путь с правильным launch clock и capture clock. А если наложен констрейнт set_max_delay то в репорте, насколько я понимаю (сам никогда такими экспериментами не занимался) должна получиться ерунда (асинхронный или анконстрейнед путь).

 

Еще момент - Вы check_timing делаете? По идее, если интерфейсы обконстрейнены через set_max_delay, то должны посыпаться ошибки.

 

Видимо вы погрязли в асиках, а от народа и фпга далеки :-))))

Ну конечно же set_max_delay ГОДЕН для синхронных путей,

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

 

Вот пример:

 

Констрейн был:

set_max_delay 2.2 -from [get_ports rd[*]] -to [get_cells rf_pos_reg[*]] -rise

 

report_timing -from [get_ports rd[0]] -to [get_cells rf_pos_reg[0]]

 

Рапорт:

 

Slack (MET) :             0.390ns  (required time - arrival time)
  Source:                 rd[0]
                            (input port)
  Destination:            rf_pos_reg[0]/D
                            (rising edge-triggered cell FDRE clocked by rxclk  {[email protected] [email protected] period=16.000ns})
  Path Group:             rxclk
  Path Type:              Setup (Max at Slow Process Corner)
  Requirement:            2.200ns  (MaxDelay Path 2.200ns)
  Data Path Delay:        5.986ns  (logic 0.989ns (16.526%)  route 4.997ns (83.474%))
  Logic Levels:           1  (IBUF=1)
  Clock Path Skew:        4.229ns (DCD - SCD + CPR)
    Destination Clock Delay (DCD):    4.229ns
    Source Clock Delay      (SCD):    0.000ns
    Clock Pessimism Removal (CPR):    0.000ns
  Clock Uncertainty:      0.025ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
    Total System Jitter     (TSJ):    0.050ns
    Total Input Jitter      (TIJ):    0.000ns
    Discrete Jitter          (DJ):    0.000ns
    Phase Error              (PE):    0.000ns
  Timing Exception:       MaxDelay Path 2.200ns

    Location             Delay type                Incr(ns)  Path(ns)    Netlist Resource(s)
  -------------------------------------------------------------------    -------------------
    H3                                                0.000     0.000 r  rd[0] (INOUT)
                         net (fo=0)                   0.000     0.000    rd[0]
    H3                   IBUF (Prop_ibuf_I_O)         0.989     0.989 r  rd_IBUF[0]_inst/O
                         net (fo=2, routed)           4.997     5.986    rd_IBUF[0]
    SLICE_X12Y66         FDRE                                         r  rf_pos_reg[0]/D
  -------------------------------------------------------------------    -------------------

                         max delay                    2.200     2.200    
    H4                                                0.000     2.200 r  rxclk (IN)
                         net (fo=0)                   0.000     2.200    rxclk
    H4                   IBUF (Prop_ibuf_I_O)         0.847     3.047 r  rxclk_IBUF_inst/O
                         net (fo=1, routed)           1.862     4.909    rxclk_IBUF
    BUFGCTRL_X0Y16       BUFG (Prop_bufg_I_O)         0.091     5.000 r  rxclk_IBUF_BUFG_inst/O
                         net (fo=98, routed)          1.430     6.429    rxclk_IBUF_BUFG
    SLICE_X12Y66         FDRE                                         r  rf_pos_reg[0]/C
                         clock pessimism              0.000     6.429    
                         clock uncertainty           -0.025     6.404    
    SLICE_X12Y66         FDRE (Setup_fdre_C_D)       -0.028     6.376    rf_pos_reg[0]
  -------------------------------------------------------------------
                         required time                          6.376    
                         arrival time                          -5.986    
  -------------------------------------------------------------------
                         slack                                  0.390

[Shivers 0]

О чем я и писал - Вы привели репорт для асинхронного пути. Если делать репорт для синхронного интерфейса, то в Source будет Launch clock, а не входной пин. Попробуйте выписать timing_report для любого пути register 2 register, и сравните.

[Dr.Alex 0]

О чем я и писал - Вы привели репорт для асинхронного пути. Если делать репорт для синхронного интерфейса, то в Source будет Launch clock, а не входной пин. Попробуйте выписать timing_report для любого пути register 2 register, и сравните.

Асинхронный путь, в которм учтены:

- Clock Path Skew

- clock pessimism

- clock uncertainty

- сетап триггера

 

Ну тогда я не знаю даже, как быть :-))))))))))

Просто не надо переносить ваши знания какой-то другой системы на Виваду, о которой идёт речь.

 

Вот пример других пинов, законстрейненных set_input_delay:

 

Slack (MET) :             7.516ns  (required time - arrival time)
  Source:                 ams
                            (input port clocked by clk_bf  {[email protected] [email protected] period=15.000ns})
  Destination:            rf_fifo_inst/mem_inst/ram_name_reg_0_22/ENBWREN
                            (rising edge-triggered cell RAMB36E1 clocked by clk_bf  {[email protected] [email protected] period=15.000ns})
  Path Group:             clk_bf
  Path Type:              Setup (Max at Slow Process Corner)
  Requirement:            15.000ns  (clk_bf [email protected] - clk_bf [email protected])
  Data Path Delay:        7.572ns  (logic 1.257ns (16.604%)  route 6.315ns (83.396%))
  Logic Levels:           3  (IBUF=1 LUT3=1 LUT6=1)
  Input Delay:            3.700ns
  Clock Path Skew:        4.267ns (DCD - SCD + CPR)
    Destination Clock Delay (DCD):    4.267ns = ( 19.267 - 15.000 ) 
    Source Clock Delay      (SCD):    0.000ns
    Clock Pessimism Removal (CPR):    0.000ns
  Clock Uncertainty:      0.035ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
    Total System Jitter     (TSJ):    0.071ns
    Total Input Jitter      (TIJ):    0.000ns
    Discrete Jitter          (DJ):    0.000ns
    Phase Error              (PE):    0.000ns

    Location             Delay type                Incr(ns)  Path(ns)    Netlist Resource(s)
  -------------------------------------------------------------------    -------------------
                         (clock clk_bf rise edge)     0.000     0.000 r  
                         input delay                  3.700     3.700    
    AA21                                              0.000     3.700 f  ams (IN)
                         net (fo=0)                   0.000     3.700    ams
    AA21                 IBUF (Prop_ibuf_I_O)         1.009     4.709 f  ams_IBUF_inst/O
                         net (fo=5, routed)           1.407     6.117    ams_IBUF
    SLICE_X0Y36          LUT6 (Prop_lut6_I0_O)        0.124     6.241 f  bus_oe_i_2/O
                         net (fo=25, routed)          4.182    10.423    rf_fifo_inst/mem_inst/pwropt
    SLICE_X58Y68         LUT3 (Prop_lut3_I1_O)        0.124    10.547 r  rf_fifo_inst/mem_inst/ram_name_reg_0_22_ENBWREN_cooolgate_en_gate_31/O
                         net (fo=1, routed)           0.726    11.272    rf_fifo_inst/mem_inst/ram_name_reg_0_22_ENBWREN_cooolgate_en_sig_16
    RAMB36_X2Y14         RAMB36E1                                     r  rf_fifo_inst/mem_inst/ram_name_reg_0_22/ENBWREN
  -------------------------------------------------------------------    -------------------

                         (clock clk_bf rise edge)    15.000    15.000 r  
    V18                                               0.000    15.000 r  clk_bf (IN)
                         net (fo=0)                   0.000    15.000    clk_bf
    V18                  IBUF (Prop_ibuf_I_O)         0.835    15.835 r  clk_bf_IBUF_inst/O
                         net (fo=1, routed)           1.868    17.703    clk_bf_IBUF
    BUFGCTRL_X0Y0        BUFG (Prop_bufg_I_O)         0.091    17.794 r  clk_bf_IBUF_BUFG_inst/O
                         net (fo=247, routed)         1.473    19.267    rf_fifo_inst/mem_inst/clk_bf_IBUF_BUFG
    RAMB36_X2Y14         RAMB36E1                                     r  rf_fifo_inst/mem_inst/ram_name_reg_0_22/CLKBWRCLK
                         clock pessimism              0.000    19.267    
                         clock uncertainty           -0.035    19.231    
    RAMB36_X2Y14         RAMB36E1 (Setup_ramb36e1_CLKBWRCLK_ENBWREN)
                                                     -0.443    18.788    rf_fifo_inst/mem_inst/ram_name_reg_0_22
  -------------------------------------------------------------------
                         required time                         18.788    
                         arrival time                         -11.272    
  -------------------------------------------------------------------
                         slack                                  7.516

[blackfin 16]

Если верить первоисточнику - UG903:

 

Page 126.

[Dr.Alex 0]

Если верить первоисточнику

Вот именно:: сплошные typically (4 раза на абзац) да however.

Но это я и так знаю, потому и вопрос задал.

 

А оказывается что разницы нет, если не считать что пользоваться set_max_delay гораздо удобнее.

[Shivers 0]

Отлично, Вы привели второй репорт для Setup. Что в нем есть:

clk_bf - это интерфейсный клок. input delay - внешняя задержка. Есть приемный клок- тоже clk_bf. Это чистый синхронный путь, такой каким он и должен быть. Слэк положительный - нарушений Setup нет. Такие же пути должны быть во всем проекте, если он синхронен.

 

Резюмирую: с input delay Вы получаете правильный граф и правильный STA, а с max_delay получается недоконстрейненный проект, и из-за этого асинхронные пути. Делать вывод о работоспособности схемы основываясь на асинхронных репортах - неправильно. При чем тут Vivado или ASIC мне не понятно - у Вас STA не работает.

[Dr.Alex 0]

Отлично, Вы привели второй репорт для Setup. Что в нем есть:

clk_bf - это интерфейсный клок.

В первом тоже есть:

rising edge-triggered cell FDRE clocked by rxclk

 

input delay - внешняя задержка.

В первом вместо этого Requirement: 2.200ns

(это же другой констрейн, и requirement другой)

 

Есть приемный клок- тоже clk_bf.

В первом тоже есть: rxclk

 

Слэк положительный - нарушений Setup нет.

В первом то же самое.

 

Итого: репорты идентичны с точностью до имён сигналов.

[blackfin 16]

Итого: репорты идентичны с точностью до имён сигналов.

Ну, чисто формально, если для констрейнта set_max_delay в качестве одного из сигналов выбран клок, то вся конструкция по логике вещей, как раз и соответствует констрейнту set_input_delay -max ...

 

Так что, ничего удивительного в этой идентичности нет..