Перейти к содержанию

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Задержка от входного пина до PLL не влияет на расчёт задержек по сгенерированному клоку, т.к. входной клок PLL и её выходные клоки - разные сигналы, разделённые изрядным набором разнообразных устройств (делители, фазовый детектор, ГУН и т.д.). Исключением является случай, когда PLL включена в режиме компенсации задержки - тут задержка учитывается для внесения правильного фазового сдвига (для компенсации), этот режим нужен для Source-Synchronous Input.

 

Разница между crezte_generated_clock и derive_pll_clocks состоит в том, что во втором случае генерируется весь набор create_generated_clock автоматом. Это исключает ошибки, когда поменяли параметры PLL и забыли откоррктировать констрейны. Недостатком derive_pll_clocks являются длинные и неудобные (уродливые) имена сгенерированных клоков. При ручном описании имена можно сделать такими, какие нравятся. Это единственное преимущество этого подхода.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Задержка от входного пина до 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 например?

Изменено пользователем S_Hawk

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

 

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

Поделиться сообщением


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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Похоже, что нет - не нравятся сгенерённые, пишите руками все констрейны. Тов. Ryan Scoville, автор замечательного (я бы сказал - лучшего) мануала по TimeQuest (TimeQuest User's Guide), насколько помню, про это прямо так написал.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти
Авторизация