[new123 0]

Привет, коллеги )

Задам вам вопрос о правильности применения констрейнов и их эффекте.

1. Создаю PLL в Vivado. Привык давно, что либо в Quartus особо на них констрейнов писать не надо, само подхватит при спец команде. Так и с Xilinx в Vivado особо не заморачивался, никогда не создавал (вроде само формирует xdc файл по ним, лень смотреть). В Vivado главное смотрю timing report, что все частоты совпадают и на месте

 

2. Обратил внимание, что один коллега, к этой pll прикрутил `create_clock` на каждый выход этой PLL (CLKOUT0,1,2,3,4)

 

И хожу я теперь в замешательстве, что с этим делать? на сколько это корректно?

Это еще не все.

Стали анализировать, и вот что вышло:

1. Дизайн с create_clock на выходах pll заметно быстрее собирается и с таймингами нет проблем

2. Дизайн по умолчанию без них собирается прям сложнее, дольше. Иногда надо что нибудь такое придумать, оптимизировать, чтобы тайминги свелись

И вот вроде бы я бы рад оставить констрейны, эффект вау, но как то на подсознании понимаю, что пути клока могут обсчитываться короче и из за этого сводится все без проблем.

 

Знатоки, рассудите, корректно ли применять дополнительно create_clock к выходам PLL?

 

ps. Советы типа, проверь периоды в pll и create_clock или номера выходов после синтеза не сработают ) проверил все от и до.

[blackfin 75]

On 8/12/2025 at 5:05 PM, new123 said:

... корректно ли применять дополнительно create_clock к выходам PLL?

create_generated_clock

[new123 0]

10 minutes ago, blackfin said:

create_generated_clock

про PLL прочитал, спасибо ) Что констрейн просто переименует клок на PLL и все.

пока тогда не могу найти ответа, почему сборка дизайна лучше становится. Ну кроме как совпадения

[Freibier 21]

1 час назад, new123 сказал:

create_clock к выходам PLL

Вы бы показали свои SDC файлы, без и с "эффектом вау".

[_4afc_ 46]

2 hours ago, new123 said:

пока тогда не могу найти ответа, почему сборка дизайна лучше становится. Ну кроме как совпадения

Я бы посмотрел, ставятся ли буфера на клок после PLL в обоих случаях.

[RobFPGA 81]

5 hours ago, new123 said:

1. ...(вроде само формирует xdc файл по ним, лень смотреть).

Если вам смотреть лень то уж нам, да еще и писать про них,  и подавно лень ... 
 

5 hours ago, new123 said:

1. Дизайн с create_clock на выходах pll заметно быстрее собирается и с таймингами нет проблем

2. Дизайн по умолчанию без них собирается прям сложнее, дольше. Иногда надо что нибудь такое придумать, оптимизировать, чтобы тайминги свелись

Констрейн констрейну не ровня. 
Констрейны автоматические  создаваемые на выходах PLL (и ряда других примитивов)  это фактически create_generated_clock. Это создаёт связанные клоки которые имеют жёстко заданные временные и фазовые соотношения  определяемые конфигурацией PLL и параметрами входного клока.   
Констрейны созданные  create_clock создают ряд независимых клоков (с источником в точке создания клока),  временные и фазовые соотношения которых в общем случае не определены (или задаются отдельными констрейнами).
А раз неопределённы то и соблюдать их необязательно - вот значит нет проблем по таймингам ...

Поэтому не ленитесь - смотрите репорты в общем по клокам,  по clock interaction, по общему списку и порядку применения констрейнов, етц.  Благо в Vivado этого добра (репортов) хватает ...   

[new123 0]

4 hours ago, Freibier said:

Вы бы показали свои SDC файлы, без и с "эффектом вау".

дак самые простые.

Вот так объявлены на выходы PLL

create_clock -period 10.000   -name name0_clk [get_pins my_mmcm/inst/mmcme4_adv_inst/CLKOUT0]
create_clock -period 50.000   -name name1_clk [get_pins my_mmcm/inst/mmcme4_adv_inst/CLKOUT1]
create_clock -period 10.000   -name name2_clk [get_pins my_mmcm/inst/mmcme4_adv_inst/CLKOUT2]
create_clock -period 12.500   -name name3_clk [get_pins my_mmcm/inst/mmcme4_adv_inst/CLKOUT3]
create_clock -period 3.333333 -name name4_clk [get_pins my_mmcm/inst/mmcme4_adv_inst/CLKOUT4]

3 minutes ago, RobFPGA said:

Констрейны созданные  create_clock создают ряд независимых клоков (с источником в точке создания клока), 

ага, спасибо большое. Я примерно представлял, что есть разница между create_clock и create_generated_clock

6 minutes ago, RobFPGA said:

,  по clock interaction, п

за наводку спасибо

[dxp 175]

Тут есть такой нюанс: считать ли клоки по умолчанию связанными или нет, зависит от конкретного тула. Насколько помню, в Quartus и Vivado клоки по умолчанию считаются связанными, поэтому если есть взаимодействие логики, тактируемой клоками, то STA будет пытаться навести тайминги. Чтобы развязать клоки, нужно это делать с помощью соответствующих констрейнов.

Что касается PLL/MMCM в Vivado, то там оно автоматом выходные клоки констрейнит, специально ничего делать не надо. В Quartus нужно для этого давать команду derive_pll_clocks. В Vivado можно добавить для клоков PLL/MMCM create_generated_clock, но только с целью переименования клока с целью получения более удобного имени.

Про входной клок PLL не помню, обязательно ли его констрейнить, если он больше никуда не идёт и никак не привязан по задержки от входного пина (такое требуется для некоторых режимов PLL/MMCM). Тул выдаёт варнинг на необконстрейненный клок, поэтому я всегда это делаю.

[RobFPGA 81]

3 hours ago, dxp said:

Про входной клок PLL не помню, обязательно ли его констрейнить

Обязательно,  а иначе как тул узнает какие величины использовать для генерации автоматических клоков на выходе PLL 

[dxp 175]

17 минут назад, RobFPGA сказал:

Обязательно,  а иначе как тул узнает какие величины использовать для генерации автоматических клоков на выходе PLL 

Так там же в свойствах IP ядра задаются все параметры -- и входная частота, а выходные.

[new123 0]

3 hours ago, dxp said:

Тут есть такой нюанс: считать ли клоки по умолчанию связанными или нет, зависит от конкретного тула.

каждый клок я добавил в отдельную асинхронную группу. То есть они не связанные

3 hours ago, dxp said:

Про входной клок PLL не помню, обязательно ли его констрейнить

вот именно в виваде очень долгое время не законстрейнил внешний входящий клок на PLL. И не придал этому значение, потому что он взял и законстрейнил сам входящий клок. А я в clock summаry смотрел, что все частоты на месте и не видел недочета

а вот вроде в квартусе такая штука не прокатила бы

[fpga_dev 11]

Сначала используете create_generated_clock чтобы переименовать сгенерированные имена во чтото удобоваримое, затем:

set_max_delay <period> -datapath_only from clock1 to clock2;
set_max_delay <period> -datapath_only from clock2 to clock1;

для каждой пары между которыми есть обмен данными. <period> соответственно выбираете меньший из двух.
Это для случая если частоты используются как независимые.

А вообще Vivado может сгенерировать целую пачку репортов, надо их внимательно изучать, много интересного можно обнаружить :)
 

[dxp 175]

2 часа назад, fpga_dev сказал:

set_max_delay <period> -datapath_only from clock1 to clock2;
set_max_delay <period> -datapath_only from clock2 to clock1;

для каждой пары между которыми есть обмен данными. <period> соответственно выбираете меньший из двух.
Это для случая если частоты используются как независимые.

Если частоты независимые, т.е. клоки асинхронные, то обмен должен осуществляться через CDC, и эти констрейны применяются уже к этим элементам. В Vivado есть специальная библиотека xpm_cdc, где есть CDC блоки для самых разнообразных случаев. И указанные констрейны применяются с этими блоками автоматически, вручную ничего делать не приходится.

[fpga_dev 11]

15 hours ago, dxp said:

Если частоты независимые, т.е. клоки асинхронные, то обмен должен осуществляться через CDC, и эти констрейны применяются уже к этим элементам. В Vivado есть специальная библиотека xpm_cdc, где есть CDC блоки для самых разнообразных случаев. И указанные констрейны применяются с этими блоками автоматически, вручную ничего делать не приходится.

Все так но есть нюанс :) 
xpm_cdc никак не покрывают всех случаев, типичный пример это память. Скажем нужен нам двойной буфер в DistRAM, пока одна сторона пишет одну страницу, лругая читает другую. Допустим номер страницы мы аккуратно переслали через xpm_cdc, а дальше все равно появляется путь RAM.WCLK -> RAM.DO -> {logic} -> FD.D -> FD.CLK и на него констрейны в xpm_cdc не распространяются. В результате путь будет либо проигнорирован (если клоки изначально не связаны) либо зарубит на корню весь тайминг. Потому что это мы решили рассматривать клоки как независимые но если Vivado об этом не сказать он будет гнуть свою линию, выберет минимальное расстояние между фронтами двух клоков (а оно может быть совсем малым в зависимости от делителей PLL), добавит до кучи clock skew и будет долго рожать слона свести тайминг.

И вообще ничего особенного в xpm_cdc нет, а внутре у нее нейонка все те же set_max_delay, описано напр здесь: https://adaptivesupport.amd.com/s/article/67738

[dxp 175]

2 часа назад, fpga_dev сказал:

Скажем нужен нам двойной буфер в DistRAM, пока одна сторона пишет одну страницу, лругая читает другую.

Это зачем? Чем xpm_async_fifo не устраивает? И даже если нужно именно страницами, то механизм ровно такой же, как в упомянутой xpm_async_fifo, сиречь -- через xpm_cdc.

2 часа назад, fpga_dev сказал:

внутре у нее нейонка все те же set_max_delay

Я так и сказал.

Использование xpm_cdc избавляет от необходимости писать эти констрейны внучную и следить за их корректностью при изменении дизайна. Кроме того, помимо констрейнов там ещё применяются директивы типа ASYNC_REG, что тоже актуально для CDC.