[1891ВМ12Я 0]

Есть прошивка на базе Virtex-7 и она не работает. При компиляции жалуется на множество не выполняющихся требований таймингов. Я создал новый top-модуль и стал постепенно подключать всё новые свои модули. И столкнулся с тем, что нужно правильно перенести регистр, который к слову меняется раз в сотни тактов а не на каждый такт, между доменами тактовых сигналов.

 

В исходных кодах обвязки GTX-трансивера видел схему синхронизации на основе примитива FD с аттрибутами (* shreg_extract = "no", ASYNC_REG = "TRUE" *). Исходный код моей версии, расширенной до многоразрядной версии (для удобства), прилагаю в файле sync.v

 

Юмор в том, что на то место, где один FS тактируется clki (входной) а следующий clko - оно жалуется что вот тут не выполняются тайминги, negative slack и тому подобное. Перемещаю дальше момент перехода - там уже жалуется. Так как же регистр перекинуть, да хоть однобитный, между доменами, чтобы оно не рычало что неверны тайминги? Вот всё же как тут сделал: https://marsohod.org/11-blog/190-meta1

sync.v

[alexadmin 0]

Прописать set_clock_groups или set_false_path в констрейны для соответствующих клоков или сигналов.

[Yuri124 1]

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

Если же, например, данные записались в регистр по clk1, а понадобятся в домене с clk2 не ранее, чем через какое-то короткое время после этого (например, 20 нс) - то кроме  set_clock_groups я бы дописал set_max_delay

2 hours ago, AVR said:

sync.v

Посмотрел прикрепленный файл - в синхронизатор регистров не пожалели. Тем не менее, кмк не факт, что весь байт данных на выходе будет выведен правильно - синхронно с со.

Изменено 30 октября, 2018 пользователем Yuri124

[des00 25]

3 hours ago, AVR said:

Есть прошивка на базе Virtex-7 и она не работает. При компиляции жалуется на множество не выполняющихся требований таймингов. Я создал новый top-модуль и стал постепенно подключать всё новые свои модули. И столкнулся с тем, что нужно правильно перенести регистр, который к слову меняется раз в сотни тактов а не на каждый такт, между доменами тактовых сигналов.

Для управления анализом выполнения временных ограничений, нужно описать файл временных ограничений (констрейнов). В файле указать частоты и частотные группы, между которыми есть передача данных. Напишите конкретно, что именно вам нужно сделать. Если передать данные, меняющиеся раз в пятилетку в другой домен, то нужно:

1. Обеспечить стабильность данных между изменениями 

2. Синхронизовать сигнал валидности данных на импульсном синхронизаторе 

3. Защелкнуть асинхронные данные, по синхронизированному сигналу в новом домене. 

4. Если уж совсем надежно, то прописать максимальную задержку между регистрами данных пункта 1 и 3. 

Quote

В исходных кодах обвязки GTX-трансивера видел схему синхронизации на основе примитива FD с аттрибутами (* shreg_extract = "no", ASYNC_REG = "TRUE" *). Исходный код моей версии, расширенной до многоразрядной версии (для удобства), прилагаю в файле sync.v

Вам такая схема не пойдет. Потому что там синхронизируется кое что другое) 

[Flood 12]

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

1. Обеспечить стабильность данных между изменениями 

2. Синхронизовать сигнал валидности данных на импульсном синхронизаторе 

3. Защелкнуть асинхронные данные, по синхронизированному сигналу в новом домене. 

4. Если уж совсем надежно, то прописать максимальную задержку между регистрами данных пункта 1 и 3. 

Если сигнал валидности поднимется после стабилизации данных и через время, гарантированно большее тактового периода приемного домена, п. 4 должен быть излишним. Поправьте, если это не так.

[des00 25]

1 hour ago, Flood said:

Если сигнал валидности поднимется после стабилизации данных и через время, гарантированно большее тактового периода приемного домена, п. 4 должен быть излишним. Поправьте, если это не так.

все так, но для любителей использовать два презерватива, можно и пункт 4)

[RobFPGA 27]

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

1 hour ago, Flood said:

Если сигнал валидности поднимется после стабилизации данных и через время, гарантированно большее тактового периода приемного домена, п. 4 должен быть излишним. Поправьте, если это не так.

Не совсем так -  если клоковые домены объявлены асинхронными то при P&R  время распространение сигнала между ними не проверяется никак, а значит и не гарнируется! Поэтому теоретически ничего не мешает трассировщику забубенить  соединение с суммарной задержкой и 10 и 20  и все 50 нс (да еще и разные для разных бит) :(  А сигнал валидности обычно задержан всего на 2-4 такта тактовой назначение Поэтому  чтобы быть уверенным что задержка распространения меньше чем задержка valid и нужно задавать max_delay для таких сигналов (равно как для cdc перехода valid).

Удачи! Rob.

[des00 25]

6 hours ago, RobFPGA said:

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

Не совсем так -  если клоковые домены объявлены асинхронными то при P&R  время распространение сигнала между ними не проверяется никак, а значит и не гарнируется! Поэтому теоретически ничего не мешает трассировщику забубенить  соединение с суммарной задержкой и 10 и 20  и все 50 нс (да еще и разные для разных бит) :(  А сигнал валидности обычно задержан всего на 2-4 такта тактовой назначение Поэтому  чтобы быть уверенным что задержка распространения меньше чем задержка valid и нужно задавать max_delay для таких сигналов (равно как для cdc перехода valid).

Удачи! Rob.

Это если только роутер сойдет с  ума и будет круги по чипу наворачивать. 4-5 тактов частоты нового домена сигнала валидности более чем достаточно чтобы не греть эту голову. Да, это не совсем верно, но более чем достаточно.

[RobFPGA 27]

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

2 hours ago, des00 said:

Это если только роутер сойдет с  ума и будет круги по чипу наворачивать. 4-5 тактов частоты нового домена сигнала валидности более чем достаточно чтобы не греть эту голову. Да, это не совсем верно, но более чем достаточно.

Может и в здравом уме такое сделать -  например если тактовая назначения высокая (например 400 MHz) а чип плотненько так упакован.

Основная засада в такой ситуации в том что тяжело отслеживается в работе. Так что лучше double-перебдеть :) Тем более сейчас в Vivado можно "привязать" к модулю СDС  файл constrain.tcl  и в нем автоматом рассчитывать требуемые задержки в зависимости от частоты тактовых на пинах модуля.

Успехов! Rob.

[1891ВМ12Я 0]

18 hours ago, alexadmin said:

Прописать set_clock_groups или set_false_path в констрейны для соответствующих клоков или сигналов.

Я дилетант и не увидел в тексте статьи "марсохода", что нужно что-то там прописывать, чтобы успокоить тайминг-анализатор. Стало быть, просто насыпать кучу регистров недостаточно? Надо еще и set_false_path прописать?

18 hours ago, Yuri124 said:

Тем не менее, кмк не факт, что весь байт данных на выходе будет выведен правильно - синхронно с со.

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

11 hours ago, RobFPGA said:

нужно задавать max_delay для таких сигналов

Понятно, и про это тоже не написано в статье "марсохода". Если в самом деле в схеме с этими регистрами задержка может быть произвольно большой, то это что-то объясняет.

15 hours ago, des00 said:

Вам такая схема не пойдет. Потому что там синхронизируется кое что другое)

Почему не пойдет? А какая тогда пойдет? Мне бы просто сделать один какой-то модуль и констрейны к нему, чтобы везде где я его влеплю - было безопасное пересечение клок-доменов у отдельных битов, и чтобы анализатор не ругался.

[Yuri124 1]

Если передаете всего лишь один независимый бит - то достаточно поставить синхронизатор из 2-3 регистров, и он перейдет в другой домен корректно. Чтобы при этом успокоить анализатор (если автоматом при компиляции не увидится этот синхронизатор), достаточно прописать set_clock_groups.

Если через синхронизаторы передавать группу сигналов, и важно, чтобы они пришли правильно синхронно сразу же - такой метод с синхронизаторами на каждый бит не подойдет. Почитайте статью И. Каршенбойма на эту тему. 

Допустим, нужно передать группу сигналов из clk1 в clk2.

Пишете по фронту clk1 эту группу в reg1 и одновременно бит готовности данных по этому же фронту в reg_data_ready.

Потом reg_data_ready передаете в другой домен по clk2 через цепочку регистров (допустим, 3 шт).

Т.е. в худшем случае через 2 такта частоты clk2 в этом домене домене имеете сигнал, что данные готовы. Т.е. с третьим фронтом частоты clk2 Вы уже вроде бы можете пользоваться этими данными в домене clk2.

Чтобы гарантировать это, нужно обеспечить, чтобы эти данные успели дойти до цели в домене clk2 за время, меньшее 3-х тактов clk2 (меньшее на хотя бы tsu).

Пишите на эти сигналы set_max_delay от reg1 до clk2 и указываете время в зависимости от clk2 и примерного tsu, а лучше - еще с запасиком.

 

И все- теперь можно фронтом clk2 записать из reg1 в reg2 (при необходимости, если через какое-то время в reg1 данные могут уже измениться, но они еще нужны в домене clk2.

Изменено 31 октября, 2018 пользователем Yuri124

[RobFPGA 27]

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

40 minutes ago, AVR said:

Я дилетант и не увидел в тексте статьи "марсохода", что нужно что-то там прописывать, чтобы успокоить тайминг-анализатор. Стало быть, просто насыпать кучу регистров недостаточно? Надо еще и set_false_path прописать?

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

...

Почему не пойдет? А какая тогда пойдет? Мне бы просто сделать один какой-то модуль и констрейны к нему, чтобы везде где я его влеплю - было безопасное пересечение клок-доменов у отдельных битов, и чтобы анализатор не ругался.

Когда у вас связанные клоки - (чаще всего когда генерируются из одного источника) то анализатор по умолчанию вычисляет худший вариант соотношений времянки межу ними для проверки ограничений. И не важно сколько при этом регистров между ними (это служит для других целей - для устранение метастабильности). Проблема анализатора всегда между выходом регистра в одной тактовой и входом регистра в другой тактовой.  Поэтому либо кладем болт глобально (если конечно по дизайну это допустимо!) - объявляя клоки асинхронными.   Либо посылаем локально - указывая set_false_path для конкретных цепей. 

Тут вам надо определится - если это просто отдельный сигнал то достаточно  перехода через 2-4 регистра без всякого handshake. Тоже и для группы сигналов которые не связанны между собой.  Если же это шина данных (сигналы зависимы) то тут либо синхронизатор как описал des00  для медленных сигналов - либо fifo для быстрых.  

В Vivado есть библиотека XPM в ней есть готовые модули CDC как для одиночных/группы сигналов так и для шины. Посмотрите в визарде.

P.S.  Ну и можно не только использовать модули из XPM, а подсмотреть как задавать constrain для таких случаев :

..../data/ip/xpm/xpm_cdc/tcl/xpm_cdc_single.tcl 

# Scoped constraints for xpm_cdc_single
set src_clk  [get_clocks -quiet -of [get_ports src_clk]]
set dest_clk [get_clocks -quiet -of [get_ports dest_clk]]

if {($src_clk != $dest_clk) || ($src_clk == "" && $dest_clk == "")} {
    set_false_path -to [get_cells syncstages_ff_reg[0]]
} elseif {$src_clk != "" && $dest_clk != ""} {
    common::send_msg_id "XPM_CDC_SINGLE: TCL-1000" "WARNING" "The source and destination clocks are the same. ....
}

Удачи! Rob.

 

 

[Flood 12]

Интересный вопрос - а что со связанными клоками?

Например, наиболее интересный и простой случай - переход шины через связанные клоковые домены, первый частотой f и шириной 2n, а второй - частотой 2f и шириной n. Такой переход (как в одну сторону, так и в другую) возможен без развязывающего fifo, вопрос - как его корректно реализовать и отконстрейнить?

[des00 25]

5 hours ago, Flood said:

Интересный вопрос - а что со связанными клоками?

Например, наиболее интересный и простой случай - переход шины через связанные клоковые домены, первый частотой f и шириной 2n, а второй - частотой 2f и шириной n. Такой переход (как в одну сторону, так и в другую) возможен без развязывающего fifo, вопрос - как его корректно реализовать и отконстрейнить?

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

[Flip-fl0p 4]

4 часа назад, des00 сказал:

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

А можно чуть подробнее что имеется ввиду под фразой: "все точно также" ?

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