SM 0 12 декабря, 2014 Опубликовано 12 декабря, 2014 · Жалоба Он должен был туда и derive_clocks записать. Видимо, вопрос опций. А Synplify + Diamond все это делают сами молча и по умолчанию. Отчет покажите таймквеста, про междоменный переход. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
topor_topor 0 12 декабря, 2014 Опубликовано 12 декабря, 2014 · Жалоба Он должен был туда и derive_clocks записать. Видимо, вопрос опций. А Synplify + Diamond все это делают сами молча и по умолчанию. Именно как create_generated_clock создаёт с root=CLK, и с такойже частотой как и root ? Интересно...Quartus вот протупил.... А как оно generated_clock к глобальному клоковому дереву подключает? или не подключает.... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 12 декабря, 2014 Опубликовано 12 декабря, 2014 · Жалоба Именно как create_generated_clock создаёт с root=CLK, и с такойже частотой как и root ? Интересно...Quartus вот протупил.... А как оно generated_clock к глобальному клоковому дереву подключает? или не подключает.... Вот по порядку: 1) исходный код. module tst (clk, in, out); input clk, in; output reg out; reg ckff; always @(posedge clk) ckff <= ~ckff; reg ff_a; always @(posedge clk) ff_a <= in; always @(posedge ckff) out <= ff_a; endmodule Констрейны: BLOCK RESETPATHS; BLOCK ASYNCPATHS; FREQUENCY PORT clk 125 MHZ; Синплифаю запретил clock conversion, иначе он, шибко умный, убьет второй клок и преобразует в работу с сигналом разрешения. Смотрим лог синтеза: #### START OF CLOCK OPTIMIZATION REPORT #####[ Clock optimization not enabled 1 non-gated/non-generated clock tree(s) driving 2 clock pin(s) of sequential element(s) 1 gated/generated clock tree(s) driving 1 clock pin(s) of sequential element(s) 0 instances converted, 1 sequential instance remains driven by gated/generated clocks =========================== Non-Gated/Non-Generated Clocks ============================ Clock Tree ID Driving Element Drive Element Type Fanout Sample Instance --------------------------------------------------------------------------------------- @K:CKID0002 clk port 2 ckff ================================================================================ ======= ==================================================== Gated/Generated Clocks ==================================================== Clock Tree ID Driving Element Drive Element Type Fanout Sample Instance Explanation -------------------------------------------------------------------------------------------------------------------------------- @K:CKID0001 ckff FD1S3AX 1 out_0io FF-derived clock conversion disabled ================================================================================ ================================================ ##### END OF CLOCK OPTIMIZATION REPORT ######] Ага, он увидел генерацию клока триггером. Дальше PAR: WARNING - par: The following clock signals will be routed by using generic routing resource and may suffer from excessive delay and/or skew. Signal=clk_c loads=2 clock_loads=2 Signal=ckff loads=2 clock_loads=1 Ну, логично. Чтобы ОНО его автозапихала в глобальное клокодерево, 1-2 load-ов это крайне мало. Надо 10-15 хотя бы. Но, уверяю, если будет достаточно разветвлений, оно его заведет в глобальное дерево. Дальше. Самое главное!!!! Hold time optimization iteration 0: There are 1 hold time violations, the optimization is running ... End of iteration 0 8 successful; 0 unrouted; real time: 10 secs Hold time optimization iteration 1: All hold time violations have been successfully corrected in speed grade M Это говорит о том, что PAR правильно понял генерацию клока - и ему пришлось исправлять HOLD на междоменном переходе, вставляя туда задержку. Ну и, наконец, САМОЕ ГЛАВНОЕ, STA: Passed: The following path meets requirements by 7.178ns Logical Details: Cell type Pin type Cell/ASIC name (clock net +/-) Source: FF Q ff_a_0io (from clk_c +) Destination: FF Data in out_0io (to ckff +) Delay: 1.929ns (20.3% logic, 79.7% route), 1 logic levels. Constraint Details: 1.929ns physical path delay in_MGIOL to out_MGIOL meets 8.000ns delay constraint less -1.217ns skew and 0.110ns ONEG0_SET requirement (totaling 9.107ns) by 7.178ns IOL_B7A attributes: FINE=FDEL0 Physical Path Details: Data path in_MGIOL to out_MGIOL: Name Fanout Delay (ns) Site Resource C2OUT_DEL --- 0.391 IOL_B8A.CLK to IOL_B8A.INFF in_MGIOL (from clk_c) ROUTE 1 1.538 IOL_B8A.INFF to IOL_B7A.ONEG0 ff_a (to ckff) -------- 1.929 (20.3% logic, 79.7% route), 1 logic levels. Clock Skew Details: Source Clock Path clk to in_MGIOL: Name Fanout Delay (ns) Site Resource PADI_DEL --- 1.063 36.PAD to 36.PADDI clk ROUTE 2 1.653 36.PADDI to IOL_B8A.CLK clk_c -------- 2.716 (39.1% logic, 60.9% route), 1 logic levels. Destination Clock Path clk to out_MGIOL: Name Fanout Delay (ns) Site Resource PADI_DEL --- 1.063 36.PAD to 36.PADDI clk ROUTE 2 1.038 36.PADDI to R25C2C.CLK clk_c REG_DEL --- 0.404 R25C2C.CLK to R25C2C.Q0 SLICE_0 ROUTE 2 1.428 R25C2C.Q0 to IOL_B7A.CLK ckff -------- 3.933 (37.3% logic, 62.7% route), 2 logic levels. Report: 823.723MHz is the maximum frequency for this preference. ВНИМАТЕЛЬНО смотрим Source Clock Path clk to in_MGIOL и Destination Clock Path clk to out_MGIOL !!!! Первый идет от пада clk через разводку, и все. Второй - тоже от пада clk, через разводку, регистр (REG_DEL), и опять разводку (ckff). Короче, усё у полном у порядке! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
topor_topor 0 12 декабря, 2014 Опубликовано 12 декабря, 2014 · Жалоба PADI_DEL --- 1.063 36.PAD to 36.PADDI clk ROUTE 2 1.038 36.PADDI to R25C2C.CLK clk_c REG_DEL --- 0.404 R25C2C.CLK to R25C2C.Q0 SLICE_0 Короче, усё у полном у порядке! Похоже.... А SDC ваша тулза не пишет? --- У квартуса таки не впорядке.... generated_clock с выхода делителя начинает отсчёт с НУЛЕВОЙ source_latency, если он create_clock Тайминги считает как будто оба на одной частоте. Если задать как положено - create_generated_clock, то в репорте generated_clock тоже с выхода делителя начинает отсчёт но с НЕНУЛЕВОЙ source_latency Ну и тайминги считает как один быстрый а второй медленее. --- Автоматическое распознавание чегото + констрейны по умолчанию = ЗЛО Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 12 декабря, 2014 Опубликовано 12 декабря, 2014 · Жалоба Похоже.... А SDC ваша тулза не пишет? А хрен ее знает... Вроде, нет. И не моя она, а латисовская. Она наоборот может, взять SDC-констрейны (и то, немного своеобразные, это ж synplify), и экспортировать их в виде для PAR. Но я обычно и SDC-констрейны синтезатору, и констрейны для PAR, пишу сам, я не пользовался этой возможностью. В данном случае синтезатору вообще констрейнов никаких не дал, а для PAR задал входной клок только. Что касается частоты этого generated clock, то да, конечно, если не писать на него констрейн, он будет считаться как клок той же частоты, какая его и генерировала. Но нам-то важна коррекция холдов на перекрестке доменов, то есть анализ задержки между source и destination clock. От частоты это не зависит. Если надо указать другую частоту, то надо писать констрейн руками. Я об этом, кстати, сразу сказал. И еще, добавлю - это ведь пришлось запрещать синтезатору clock conversion - а совсем-совсем по умолчанию он бы синтезировал бы систему с одним клоком и разрешением от ckff. Вдогонку. К тому, что тулза все правильно поняла. Еще вырезка из отчета STA: Clock Domains Analysis ------------------------ Found 2 clocks: Clock Domain: clk_c Source: clk.PAD Loads: 2 Covered under: FREQUENCY PORT "clk" 125.000000 MHz; Clock Domain: ckff Source: SLICE_0.Q0 Loads: 2 No transfer within this clock domain is found Data transfers from: Clock Domain: clk_c Source: clk.PAD Covered under: FREQUENCY PORT "clk" 125.000000 MHz; Transfers: 1 PS К хорошему быстро привыкаешь. Я всегда считал квартус самым продвинутым тулом. А оказывается, не во всем. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться