Dr.Alex 0 23 декабря, 2016 Опубликовано 23 декабря, 2016 · Жалоба Думаю понятно что set_max_delay здесь в контексте именно задания сетап/холда (потому я и сравниваю с set_input_delay), а то конечно им можно что угодно констрейнить. Так в чём же разница? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shivers 0 24 декабря, 2016 Опубликовано 24 декабря, 2016 · Жалоба Разница принципиальная, что следует из названия. set_max_delay - контролирует длины любых арок графа. А set_input_delay относится только к интерфейсам - часть графа, которая достраивается вокруг схемы на основе констрейнтов. p.s. set_max_delay обычно не используют, он избыточен, поскольку пути reg2reg контролируются периодом клока, а интерфейсы - input_delay/output_delay Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dr.Alex 0 24 декабря, 2016 Опубликовано 24 декабря, 2016 · Жалоба Разница принципиальная, что следует из названия. 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 7 24 декабря, 2016 Опубликовано 24 декабря, 2016 · Жалоба разница в привязке set_input_delay к конкретному тактовому сигналу, а set_max_delay распространяется на все клоки, на те которые есть и которых еще даже и нет. по-моему я уже писал, что для одного азика пришлось внутри возится с multicycle путями вместо того, чтобы описать min/max delay, так как команда бэкенда категорически не воспринимала min/max, аргументируя это тем, что сильно увеличивается время трассировки с такими констрейнами. может это из-за оптимизации бд внутри синопсиса, а может и вообще лишние операции добавляются в пересчете min/max на период - не могу сейчас об этом подумать :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shivers 0 24 декабря, 2016 Опубликовано 24 декабря, 2016 · Жалоба Принципиальное отличие в том, что set_input_delay выглядит на графе как виртуальный триггер, работающий на одном из клоков. Т.е. этот констрейнт используется при накладывании ограничений на синхронный интерфейс. Если же интерфейс асинхронный, то с set_input_delay нужно использовать с виртуальным клоком. А set_max_delay - это ограничение на задержку асинхронных арок (т.е. не привязано к клоку), очень редко используется внутри схемы. Для синхронных интерфейсов этот констрейнт совершенно бессмысленен, а для асинхронных - все же обычно используют виртуальный клок с set_input_delay. p.s. вот, меня опередили =) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dr.Alex 0 24 декабря, 2016 Опубликовано 24 декабря, 2016 · Жалоба set_max_delay распространяется на все клоки Не понял. Ведь я констрейню не что-то абстрактное, а путь от пина до триггера, который тактируется конкретным клоком, единственным. Для синхронных интерфейсов этот констрейнт совершенно бессмысленен Совсем не понял. Это значит что я вообще не могу им пользоваться. Но я пользуюсь и вижу, что Вивада обходится с ним гораздо опрятнее чем с set_input_delay. Клок скью учитывается? Учитывается. И всё остальное, что нужно чтобы законстрейнить сетап, тоже. Так почему же он бессмысленен? И ещё раз напоминаю, что констрейнится путь от шарика микросхемы до первого триггера, а не что-либо другое. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shivers 0 24 декабря, 2016 Опубликовано 24 декабря, 2016 · Жалоба Так почему же он бессмысленен? Сделайте report_timing до входа Вашего триггера через входной пин. С set_input_delay получите честный синхронный путь с правильным launch clock и capture clock. А если наложен констрейнт set_max_delay то в репорте, насколько я понимаю (сам никогда такими экспериментами не занимался) должна получиться ерунда (асинхронный или анконстрейнед путь). Еще момент - Вы check_timing делаете? По идее, если интерфейсы обконстрейнены через set_max_delay, то должны посыпаться ошибки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dr.Alex 0 24 декабря, 2016 Опубликовано 24 декабря, 2016 · Жалоба Сделайте 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 24 декабря, 2016 Опубликовано 24 декабря, 2016 · Жалоба О чем я и писал - Вы привели репорт для асинхронного пути. Если делать репорт для синхронного интерфейса, то в Source будет Launch clock, а не входной пин. Попробуйте выписать timing_report для любого пути register 2 register, и сравните. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dr.Alex 0 24 декабря, 2016 Опубликовано 24 декабря, 2016 · Жалоба О чем я и писал - Вы привели репорт для асинхронного пути. Если делать репорт для синхронного интерфейса, то в 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 25 24 декабря, 2016 Опубликовано 24 декабря, 2016 · Жалоба Если верить первоисточнику - UG903: Page 126. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dr.Alex 0 24 декабря, 2016 Опубликовано 24 декабря, 2016 · Жалоба Если верить первоисточнику Вот именно:: сплошные typically (4 раза на абзац) да however. Но это я и так знаю, потому и вопрос задал. А оказывается что разницы нет, если не считать что пользоваться set_max_delay гораздо удобнее. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shivers 0 24 декабря, 2016 Опубликовано 24 декабря, 2016 · Жалоба Отлично, Вы привели второй репорт для Setup. Что в нем есть: clk_bf - это интерфейсный клок. input delay - внешняя задержка. Есть приемный клок- тоже clk_bf. Это чистый синхронный путь, такой каким он и должен быть. Слэк положительный - нарушений Setup нет. Такие же пути должны быть во всем проекте, если он синхронен. Резюмирую: с input delay Вы получаете правильный граф и правильный STA, а с max_delay получается недоконстрейненный проект, и из-за этого асинхронные пути. Делать вывод о работоспособности схемы основываясь на асинхронных репортах - неправильно. При чем тут Vivado или ASIC мне не понятно - у Вас STA не работает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dr.Alex 0 24 декабря, 2016 Опубликовано 24 декабря, 2016 · Жалоба Отлично, Вы привели второй репорт для Setup. Что в нем есть: clk_bf - это интерфейсный клок. В первом тоже есть: rising edge-triggered cell FDRE clocked by rxclk input delay - внешняя задержка. В первом вместо этого Requirement: 2.200ns (это же другой констрейн, и requirement другой) Есть приемный клок- тоже clk_bf. В первом тоже есть: rxclk Слэк положительный - нарушений Setup нет. В первом то же самое. Итого: репорты идентичны с точностью до имён сигналов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
blackfin 25 24 декабря, 2016 Опубликовано 24 декабря, 2016 · Жалоба Итого: репорты идентичны с точностью до имён сигналов. Ну, чисто формально, если для констрейнта set_max_delay в качестве одного из сигналов выбран клок, то вся конструкция по логике вещей, как раз и соответствует констрейнту set_input_delay -max ... Так что, ничего удивительного в этой идентичности нет.. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться