что использовать для описания pll - create_generaned_clock или derive_pll_clocks? Опции

[S_Hawk]

(после прочтения "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


Сообщение отредактировал S_Hawk - Jul 7 2018, 14:09

[dxp]

Примерно так. Входной клок нужно указывать потому, что этого требует функция create_generated_clock (его параметры нужны для расчёта сгенерированного клока), анализатор будет считать, что фазовый сдвиг между клоками равен нулю, если не указано иное. В реальности в обычном (кажется, он называется Normal) режиме PLL у альтер обеспечивает синфазность между входным пином (внутренним) PLL и выходным пином клока. Поэтому если использовать входной клок для тактирования логики (а не только для подачи на PLL), то связанность, вроде, там должна быть. Другое дело, что параметры джиттера и прочее подобное у этого клока будут отличаться от выходного клока PLL, что и понятно. Для учёта этих эффектов там есть функция defive_clock_uncertainty, квартус выдаёт предупреждение, если её не вызывать.

Если нужна привязка именно ко входу, то это уже надо включать режим компенсации.

Будет ли STA считать клоки связанными, зависит от тула. TimeQuest, насколько помню, считает все клоки связанными, поэтому если есть увязки в коде между этими клоками (переходы между этими клоковыми доменами), то ТК будет их учитывать. Если это не то, что вам надо, то объявить эти клоки асинхронными.

Там как-то можно посмотреть, какой скрипт рожает квартус по derive_pll_clocks, вот его можно взять за основу. Если хочется руками поупражняться или сильно не нравятся автоматически сгенерированные имена.

[dima32rus]

Там как-то можно посмотреть, какой скрипт рожает квартус по derive_pll_clocks, вот его можно взять за основу. Если хочется руками поупражняться или сильно не нравятся автоматически сгенерированные имена.

Да, кстати. Никак нельзя указать какой-нибудь паттерн на генерируемые командой derive_pll_clocks имена? Они действительно получаются длинные и неудобные. Как-то задавался этим вопросом, но так ничего и не нашел, или может плохо или не там искал...