S_Hawk 0 7 июля, 2018 Опубликовано 7 июля, 2018 (изменено) · Жалоба (после прочтения "Synopsys Design Constraint — язык задания временных ограничений на примере Altera TimeQuest. Часть 2" вопрос возник) Развейте, плиз, мои сомнения: Если выход PLL в .sdc-файле описать через create_generated_clock -name clk2 -source [get_ports {iclk}] [get_pins {plllaltpll_componentlauto_generated|plniclk[0]}] , то при трассировке путей временной анализатор в пути нового клока не учтет задержку от входа исходного клока iclk до входа PLL и, тем самым будет вносить ошибку в расчет времянок? В отличие от использования derive_pll_clocks, который сгенерирует строку: create_generated_clock -source {plllaltpll_componentlauto_ generated|pll1linclk[0]} -name {plllaltpll_componentlauto_generated|pll1lclk[0]} {plllaltpll_ componentlauto_generated|pll1lclk[0]} и в этой строке, по идее, должна быть учтена задержка между iclk и входом PLL? Или я что-то неправильно понимаю? Т.е. вопрос, конечно, не в выборе команд, а правильности указания в create_generated_clock порта iclk вместо выхода PLL Изменено 7 июля, 2018 пользователем S_Hawk Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 58 8 июля, 2018 Опубликовано 8 июля, 2018 · Жалоба Задержка от входного пина до PLL не влияет на расчёт задержек по сгенерированному клоку, т.к. входной клок PLL и её выходные клоки - разные сигналы, разделённые изрядным набором разнообразных устройств (делители, фазовый детектор, ГУН и т.д.). Исключением является случай, когда PLL включена в режиме компенсации задержки - тут задержка учитывается для внесения правильного фазового сдвига (для компенсации), этот режим нужен для Source-Synchronous Input. Разница между crezte_generated_clock и derive_pll_clocks состоит в том, что во втором случае генерируется весь набор create_generated_clock автоматом. Это исключает ошибки, когда поменяли параметры PLL и забыли откоррктировать констрейны. Недостатком derive_pll_clocks являются длинные и неудобные (уродливые) имена сгенерированных клоков. При ручном описании имена можно сделать такими, какие нравятся. Это единственное преимущество этого подхода. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
S_Hawk 0 8 июля, 2018 Опубликовано 8 июля, 2018 (изменено) · Жалоба Задержка от входного пина до PLL не влияет на расчёт задержек по сгенерированному клоку, т.к. входной клок PLL и её выходные клоки - разные сигналы, разделённые изрядным набором разнообразных устройств (делители, фазовый детектор, ГУН и т.д.). т.е. сгенерированный клок после PLL будет сдвинут относительно входящего в микросхему? тогда, получается, неправильно писать create_generated_clock -name clk2 -source [get_ports {iclk}] ... т.к. clk2, который после выхода PLL не совпадет по фазе с iclk? точнее так сформулирую вопрос: есть разница в двух описаниях create_generated_clock -source {iclk} ... create_generated_clock -source {inst_pll|pll_inst|altera_pll_i|general[0].gpll~FRACTIONAL_PLL|refclkin} ... между iclk и inst_pll|pll_inst|altera_pll_i|general[0].gpll~FRACTIONAL_PLL|refclkin есть, ведь, задержка? P.S. аа... понял... т.е. временной анализатор не учитывает этих задержек, что внутри PLL, что на пути к PLL? тогда тактовую до PLL и после PLL нужно разносить в разные группы? или предпринимать дополнительные танцы для их синхронизации, что может быть нужно в Source-Synchronous Input например? Изменено 8 июля, 2018 пользователем S_Hawk Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 58 9 июля, 2018 Опубликовано 9 июля, 2018 · Жалоба Примерно так. Входной клок нужно указывать потому, что этого требует функция create_generated_clock (его параметры нужны для расчёта сгенерированного клока), анализатор будет считать, что фазовый сдвиг между клоками равен нулю, если не указано иное. В реальности в обычном (кажется, он называется Normal) режиме PLL у альтер обеспечивает синфазность между входным пином (внутренним) PLL и выходным пином клока. Поэтому если использовать входной клок для тактирования логики (а не только для подачи на PLL), то связанность, вроде, там должна быть. Другое дело, что параметры джиттера и прочее подобное у этого клока будут отличаться от выходного клока PLL, что и понятно. Для учёта этих эффектов там есть функция defive_clock_uncertainty, квартус выдаёт предупреждение, если её не вызывать. Если нужна привязка именно ко входу, то это уже надо включать режим компенсации. Будет ли STA считать клоки связанными, зависит от тула. TimeQuest, насколько помню, считает все клоки связанными, поэтому если есть увязки в коде между этими клоками (переходы между этими клоковыми доменами), то ТК будет их учитывать. Если это не то, что вам надо, то объявить эти клоки асинхронными. Там как-то можно посмотреть, какой скрипт рожает квартус по derive_pll_clocks, вот его можно взять за основу. Если хочется руками поупражняться или сильно не нравятся автоматически сгенерированные имена. ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
demon3200 0 9 июля, 2018 Опубликовано 9 июля, 2018 · Жалоба Там как-то можно посмотреть, какой скрипт рожает квартус по derive_pll_clocks, вот его можно взять за основу. Если хочется руками поупражняться или сильно не нравятся автоматически сгенерированные имена. ;) Да, кстати. Никак нельзя указать какой-нибудь паттерн на генерируемые командой derive_pll_clocks имена? Они действительно получаются длинные и неудобные. Как-то задавался этим вопросом, но так ничего и не нашел, или может плохо или не там искал... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 58 9 июля, 2018 Опубликовано 9 июля, 2018 · Жалоба Похоже, что нет - не нравятся сгенерённые, пишите руками все констрейны. Тов. Ryan Scoville, автор замечательного (я бы сказал - лучшего) мануала по TimeQuest (TimeQuest User's Guide), насколько помню, про это прямо так написал. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться