[RobFPGA 27]

Приветствую!

Just now, blackfin said:

Хмм. А можно ссылку на документ? Вот специально прошелся поиском по Quartus Handbook v17 и не нашел этого атрибута.. Видимо, какой-то новодел.

Это  обычные  assignments  Quartus  которые применяются непосредственно в коде к конкретному  инстансу.   Удобно чтобы  не делать это через assignments editor или ручками в qsf файле.  

set_instance_assignment -name SYNCHRONIZER_IDENTIFICATION <AUTO|"FORCED IF ASYNCHRONOUS"|FORCED|OFF> -to <register or instance name>

 

15 minutes ago, Dr.Alex said:

Вы всё точно понимаете, set_false_path НЕЛЬЗЯ (работать будет лишь случайно, хотя и в большинстве случаев), а set_max_delay - правильно и нужно.

Не  будет работать если лепить  false-path  глобально - на группы клоков.  О чем  и говорится в дискуссии.  Для  отдельных путей между регистрами битового синхронизатора false_path вполне используется.   Ну а на синхронизацию шин (группа связанных бит) false_path никогда нельзя применять. 

Удачи! Rob.

[dxp 34]

1 час назад, Dr.Alex сказал:

Вы всё точно понимаете, set_false_path НЕЛЬЗЯ (работать будет лишь случайно, хотя и в большинстве случаев), а set_max_delay - правильно и нужно.

set_max_delay надо обязательно с ключом -datapath_only. Но это расширение Xilinx Vivado, оно нестандартное (для sdc), в Quartus его скорее всего нет (не проверял).

[Dr.Alex 0]

11 minutes ago, dxp said:

set_max_delay надо обязательно с ключом -datapath_only. Но это расширение Xilinx Vivado, оно нестандартное (для sdc), в Quartus его скорее всего нет (не проверял).

1) Нет, datapath_only не обязателен, его наличие/отсутствие лишь влияет на задаваемую величину задержки.

2) Это значит лишь то, что для Шквартуса нужно искать адекватный констрейн, а не лакировать его отсутствие псевдоконстрейном сет_фолс_пас.

[andrew_b 14]

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

И как вы предлагаете воспользоваться атрибутом ASYNC_REG, которого в Quartus'е (да и в тулах Microchip'а, видимо тоже) нет в принципе?

А не хотите перечитать первую страницу этой темы?

Как вы совершенно справедливо заметили, автор в вопросе не указал вендора. А раз так, то можно предполагать всё что угодно. Сейчас лето, и телепаты в отпусках. Я предложил воспользоваться советом Xilinx'а. И только после этого высянилось, что у автора Microchip.

[Avex 1]

set_max_transition или set_max_skew (одно и то же) тоже неплохо бы использовать. Это констрейнт из группы DRV, ограничивает расползание фронта сигнала. Если фронт принудительно ограничить, тул будет стараться ставить приемник и передатчик поближе друг к другу - таким образом накладывается еще одно ограничение на длинну провода. Вторая причина использовать этот констрейнт - при коротком фронте реже сваливание в метастабильность в CDC синхронизаторе. Мелочь,, но полезно

Изменено 3 июля, 2021 пользователем Aleх

[Plain 168]

Прочёл тему несколько раз, но так и не понял, каким образом выравнивание может повлиять на синхронизацию рукопожатием.

[RobFPGA 27]

Приветствую!

On 7/3/2021 at 11:37 AM, Plain said:

Прочёл тему несколько раз, но так и не понял, каким образом выравнивание может повлиять на синхронизацию рукопожатием.

Вы имеете ввиду тему на форуме Xilinx? 
И может не выравнивание а макс. задержка?  Еще как может если вдруг окажется  что задержка  для пути данных больше чем суммарная задержка в цепочке синхронизации хендшейка.

 

Удачи! Rob.

[des00 25]

On 7/2/2021 at 7:23 PM, andrew_b said:

Вот что пишут на форуме Xilinx:

https://forums.xilinx.com/t5/Timing-Analysis/how-to-constrain-a-CDC/td-p/748174

 

ну пишет то по делу, не вижу раскорреляции в том что я написал, при этом он сам пишет что априори неизвестно как поведет пути роутер плис, там он называет задержку в 3 мкс. Теория то да, он абсолютно прав, но вы реально думаете что роутер будет там круги наворачивать вокруг плис что бы такую задержку сделать? Сколько не ковырялся с нетлистами, роутер всегда минимизировал трассировочный ресурс, укладывая его в 5-10нс, что достаточно для большинства случаев. Будет не хватать, добавить констрейны, но вот мне всегда хватало 3 триггеров и просто асинхронных групп, везет наверное)

Размышления про расположения триггеров синхронизатора в одном макроблоке не совсем понял что дает, ну выйдет метастабильность на роутинг, что катасрофического она даст? Всегда считал что без разницы какие это триггеры, главное что бы это были триггеры а не SRL конструкции на лютах.

3 hours ago, RobFPGA said:

Еще как может если вдруг окажется  что задержка  для пути данных больше чем суммарная задержка в цепочке синхронизации хендшейка.

ну вот вы считаете этот случай практически реальным с выской долей вероятности?  Давайте без теорий о сферическом коне в вакууме, с реальными тактовыми 100-300МГц, вы видели в своих проектах как данные выходят из одного блока, подаются в другой, где стоит hanshake CDC и сами стробы идут по прямому пути, а данные, супротив всякой логики, роутер ведет огородами, три раза?

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

[RobFPGA 27]

Приветствую!

25 minutes ago, des00 said:

... но вы реально думаете что роутер будет там круги наворачивать ...

А  у меня как раз и было однажды что при false_path для пути данных в хендшейк синхронизаторе, роутер развел несколько линий из шины с задержкой ~12-15 ns что было больше чем задержка на синхронизаторе (3 такта по 4ns). И вычислил я такой сюрприз чисто случайно. Представляю как бы "весело"  было с таким глюком в реальной железке. 

25 minutes ago, des00 said:

Размышления про расположения триггеров синхронизатора в одном макроблоке не совсем понял что дает

Уменьшение емкости нагрузки выхода триггера  дает ускорение выхода из метастабильного состояния. Отсюда и требование к физ. близкому расположению триггеров в цепочки синхронизации. 

 

Удачи! Rob.

[des00 25]

7 minutes ago, RobFPGA said:

А  у меня как раз и было однажды что на при false_path для пути данных роутер развел несколько линий из шины с задержкой ~12-15 ns что было больше чем задержка на синхронизаторе (3 такта по 4ns). И вычислил я такой сюрприз чисто случайно. Представляю как бы "весело"  было с таким глюком в реальной железке. 

4нс - 250МГц, а сами пути смотрели, почему он так их повел? плиса забита на 90 и выше процентов была? Как раз про такие случаи и писал "Будет не хватать, добавить констрейны"

Quote

Уменьшение емкости нагрузки выхода триггера  дает ускорение выхода из метастабильного состояния. Отсюда и требование к физ. близкому расположению триггеров в цепочки синхронизации.

эмм, там же стоят усилители-повторители, мультиплексоры и все такое, там нагрузка минимальная же, до первого повторителя. Уже плохо помню схемотехнику триггеров, но как то странно мне что выходная емкость влияет на время выхода из метастабильного состояния, на tco да, на крутизну фронта да, но на время выхода. Может есть какая ссылка почитать?

[RobFPGA 27]

Приветствую!

1 hour ago, des00 said:

а сами пути смотрели, почему он так их повел? плиса забита на 90 и выше процентов была? Как раз про такие случаи и писал "Будет не хватать, добавить констрейны"

Думаю  что несколько  факторов  -  общее заполнение было 70-80%, но несколько  блоков были критичны  по частоте и размещению, а данный синхронизатор оказался "растянут" по  разные стороны кристалла с двух сторон такой критичной области.  А раз на данных false_path то и роутинг  видно шел по остаточному принципу.
Сложность  таких  ситуаций как раз в непредсказуемости и неконтролируемости! По хорошему для контроля правильности кострейнов надо гонять пост-P&R timing верификацию. Но делать каждый раз долго и муторно. Проще сразу констрейнить все по правилам.
 

1 hour ago, des00 said:

эмм, там же стоят усилители-повторители, мультиплексоры и все такое, там нагрузка минимальная же, до первого повторителя

Увы - большая часть коммутации в FPGA на чисто-пассивных ключах.  Отсюда наверное и рост задержки в зависимости от fanout. 

 

IMHO выходная емкость напрямую влияет на быстродействие триггера (как и на скорость фронта). В равновесном состоянии неодинаковость токов плеч триггера перезаряжает  паразитные емкости стоков/затворов. И чем эти емкости больше тем длительнее может быть этот процесс пока разница напряжений не станет критической для сваливания.      

 

Удачи! Rob.

[blackfin 16]

On 7/2/2021 at 6:26 PM, Dr.Alex said:

2) Это значит лишь то, что для Квартуса нужно искать адекватный констрейн, а не лакировать его отсутствие псевдоконстрейном сет_фолс_пас.

В Quartus'е рекомендуют задавать оба констрейнта - set_min_delay + set_max_delay:

 

[dvladim 0]

05.07.2021 в 07:34, RobFPGA сказал:

Увы - большая часть коммутации в FPGA на чисто-пассивных ключах.

Абсолютно неверно. Коммутация в FPGA - это мультиплексор и буфер, поэтому fanout на задержку никак не влияет.

[Lutovid 0]

Вдруг будет полезно - в Vivado в Language templates есть макросы для CDC xpm_cdc_single, xpm_cdc_array_single, xpm_cdc_handshake - для них отдельно задавать тайминг констрэйнты не нужно, если их функционал устраивает.