yes 7 27 февраля, 2010 Опубликовано 27 февраля, 2010 · Жалоба стандартная ситуация - сгенерированный клок с выхода регистра тактируемого мастером вот пример с альтеры http://www.altera.com/support/examples/tim...ated-clock.html при анализе пути видно, что launch и latch клоки совпадают, то есть мне (вернее апликэйшен инженерам Альтеры) вручную надо было прописать в команде create_generated_clock -add -source clock \ -name div2clock \ -divide_by 2 \ -master_clock clock_name \ [get_pins div2reg|regout] -offset __CLOCK_TO_DATA__ в случае EP2S из примера это __CLOCK_TO_DATA__ = 1.8ns ----------------------- правильно или я что-то не понимаю? может есть какая-то команда типа derive_pll_clock, которая этот offset умеет сама добавить? правильно ли я вычисляю этот офсет, если это надо таки делать вручную? то есть в беру clock|dataout у флипфлопа и задержку LE-вход тактового дерева - в даташите я это не нашел и смотрю либо по чип-планеру, либо по аннотированому технологи-мэппед схематику ----------------------- есть дизайн с достаточно жесткими требованиями на пути между такими генеренными клоками и как-то подглюкивает, пытаюсь понять, не облажался ли с констрейнами собственно проблема еще в том, что вторая часть офсета (LE->CT) не постоянна и зависит от трассировки, поэтому уверенности в том, что я правильно ее задам нету для анализа в таймквесте можно написать скрипт для ее вычисления, но хотелось бы более простой путь... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
slawikg 0 27 февраля, 2010 Опубликовано 27 февраля, 2010 · Жалоба -offset __CLOCK_TO_DATA__ в случае EP2S из примера это __CLOCK_TO_DATA__ = 1.8ns ----------------------- правильно или я что-то не понимаю? может есть какая-то команда типа derive_pll_clock, которая этот offset умеет сама добавить? Внутри кристала задержку рассчитывает сам Квартус Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 7 27 февраля, 2010 Опубликовано 27 февраля, 2010 · Жалоба Внутри кристала задержку рассчитывает сам Квартус на приложеной картинке видно, какие задержки расчитывает, а какие нет. Задержка между тактовыми сигналами (LATCH CLOCK и LAUNCH CLOCK) == 0, что не соответствует реальности а рассчитанные задержки "CLOCK DELAY" учитывают задержки тактовых деревьев и не учитывают задержку от тактового входа делителя до тактового дерева сгенеренного такта (которая достаточно большая 1.8нс) по крайней мере я так понял хотелось бы понять, можно ли заставить квартус "сгенерить" правильный констрейн так, как он это делает для derive_pll_clock или самому надо эту задержку добавлять. мое мнение - нужно добавлять самому, автоматически не умеет, но хотелось бы ошибится кстати, исполняя derive_pll_clock квартус почестному прописывает -phase или -offset в create_generated_clock Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 27 февраля, 2010 Опубликовано 27 февраля, 2010 · Жалоба на приложеной картинке видно, какие задержки расчитывает, а какие нет. Задержка между тактовыми сигналами (LATCH CLOCK и LAUNCH CLOCK) == 0, что не соответствует реальности на картинке он никогда явно не рисует эту задержку, она входит в вычисление Data Arrival/Data Required. Если посмотреть на пути, то видно что он сам учитывает задержку сгенерированного клока (рис 1). ЗЫ. Занятно, но на третьем сыклоне, по холду, у меня констрейны не сошлись %) UPD Неужели ква настолько отупел что не может пару LCELL ов вставить что бы путь по данным удлиннить... UPD2 стояло в настройках фиттера Auto Fit (reduce Fitter effort after meeting timing requirements), поставил Standart + Optimize Hold Timing == ALL Paths и у ква получилось свести все хорошо. Странно. UPD3 и в отчетах явно видно что он повел путь по-другому, удлинив его на 1нс (рис 2) %) кстати, исполняя derive_pll_clock квартус почестному прописывает -phase или -offset в create_generated_clock Кстати в примерах альтеровцы настоятельно забывают про derive_clock_uncertainty или про задание uncertainty внешнего источника. Это все при том, что ква нещадно кричит в случае отсутствия оного %) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Des333 0 27 февраля, 2010 Опубликовано 27 февраля, 2010 · Жалоба UPD Неужели ква настолько отупел что не может пару LCELL ов вставить что бы путь по данным удлиннить... Столкнулся тут как-то с интересным фактом. Некоторый модуль собирался в двух вариантах: как топ-левел и как часть более крупного проекта. При этом, когда собирается как топ-левел по констрейнам не укладывается, когда как часть проекта - все в норме. Все дело в том, что в первом случае задержка клока(при одинаковой задержке данных) намного меньше и в итоге все "валится" :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 28 февраля, 2010 Опубликовано 28 февраля, 2010 · Жалоба Все дело в том, что в первом случае задержка клока(при одинаковой задержке данных) намного меньше и в итоге все "валится" :) занятно, я давно заметил что у ква проблемы с выравниванием именно клока %) ну и это еще одно подтверждение что нужно смотреть не только на факт завала констрейнов, но и на то место где именно они валяться и почему %) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 28 февраля, 2010 Опубликовано 28 февраля, 2010 · Жалоба при анализе пути видно, что launch и latch клоки совпадают, Видимо с анализом что-то не то. Выведите в лог все пути полностью (есть там режим, где все задержки по гейтам и трассам выводятся), и будет видно, что тут не так. Квартус всегда сам рассчитывает все задержки, и это совершенно точно. Единственный вариант, когда нужно ставить оффсет/лэтенси - это если клок выходил на прогулку вне ПЛИСы... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 28 февраля, 2010 Опубликовано 28 февраля, 2010 · Жалоба вот пример: verilog: module time_test (input clk, input d, output o ) ; reg clkd; always @(posedge clk) clkd <= ~clkd; reg ra,rb; always @(posedge clk) ra <= d; always @(posedge clkd) rb <= ra; assign o = rb; endmodule SDC: create_clock -name mclk -period "100 MHz" [get_ports clk] create_generated_clock -name clkd -source clk -divide_by 2 [get_pins clkd|q] derive_clock_uncertainty log: report_timing -from_clock { mclk } -to_clock { clkd } -from [get_keepers {ra}] -to [get_keepers {rb}] -setup -npaths 1 -detail full_path Info: Report Timing: Found 1 setup paths (0 violated). Worst case slack is 8.826 Info: -setup Info: -from_clock [get_clocks { mclk }] Info: -to_clock [get_clocks { clkd }] Info: -from [get_keepers {ra}] Info: -to [get_keepers {rb}] Info: -npaths 1 Info: -detail full_path Info: Path #1: Setup slack is 8.826 Info: =================================================================== Info: From Node : ra Info: To Node : rb Info: Launch Clock : mclk Info: Latch Clock : clkd Info: Info: Data Arrival Path: Info: Info: Total (ns) Incr (ns) Type Element Info: ========== ========= == ==== =================================== Info: 10.000 10.000 launch edge time Info: 10.000 0.000 source latency Info: 10.000 0.000 clk Info: 10.000 0.000 RR IC clk~input|i Info: 10.791 0.791 RR CELL clk~input|o Info: 10.997 0.206 RR IC clk~inputclkctrl|inclk[0] Info: 10.997 0.000 RR CELL clk~inputclkctrl|outclk Info: 11.880 0.883 RR IC ra|clk Info: 12.481 0.601 RR CELL ra Info: 12.713 0.232 uTco ra Info: 12.713 0.000 FF CELL ra|q Info: 14.119 1.406 FF IC rb~feeder|datab Info: 14.549 0.430 FF CELL rb~feeder|combout Info: 14.549 0.000 FF IC rb|d Info: 14.655 0.106 FF CELL rb Info: Info: Data Required Path: Info: Info: Total (ns) Incr (ns) Type Element Info: ========== ========= == ==== =================================== Info: 20.000 20.000 latch edge time Info: 20.000 0.000 source latency Info: 20.000 0.000 clk Info: 20.000 0.000 RR IC clk~input|i Info: 20.791 0.791 RR CELL clk~input|o Info: 20.989 0.198 RR IC clk~inputclkctrl|inclk[0] Info: 20.989 0.000 RR CELL clk~inputclkctrl|outclk Info: 21.836 0.847 RR IC clkd|clk Info: 22.394 0.558 RR CELL clkd Info: 22.626 0.232 uTco clkd Info: 22.626 0.000 RR CELL clkd|q Info: 22.911 0.285 RR IC rb|clk Info: 23.469 0.558 RR CELL rb Info: 23.449 -0.020 clock uncertainty Info: 23.467 0.018 uTsu rb Info: Info: Data Arrival Time : 14.655 Info: Data Required Time : 23.467 Info: Clock Pessimism : 0.014 Info: Slack : 8.826 Info: =================================================================== Как видим - задержка на clkd полностью учтена при рассчете Data required path Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 7 1 марта, 2010 Опубликовано 1 марта, 2010 · Жалоба спасибо. был не прав, ввело в заблуждение то, что для PLL-ных клоков таймквест на картинке рисует задержку между launch clock и latch clock у report_timing есть опция -detail path_and_clock --------- derive_clock_uncertainty для 2-го циклона (в поекте, а не в примере) смысла, как я понимаю, не имеет и игнорируется Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться