[dxp 36]

24 минуты назад, des00 сказал:

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

Т.е. руками в проект зацеплять надо, не забыть. И жесткая привязка к именам тож не айс.

2 минуты назад, Nick_K сказал:

В случае для Vivado есть мозможность создать кастомный IP для отдельного компонента, в котором указать все нужные констрейны, при подтягивании которого всё добавляется автоматически. У Альтеры может тоже есть такой рподукт, но я не пользовался.

Разработать свои гибкие модули, чтобы уйти от деревянных корок, чтобы потом их опять засунуть в корки? :)

[des00 25]

1 minute ago, dxp said:

Т.е. руками в проект зацеплять надо, не забыть. И жесткая привязка к именам тож не айс.

согласен, ну а других вариантов особо нет. В код, в комментарии вставлять тоже не вариант, хранить готовые шаблоны и по месту править в них параметры(если надо), все же удобнее. А без привязки, тяжко будет, модуль же может быть с любыми именем инстанса, если еще и имена править по месту(в скрипте) совсем тяжко будет

[Nick_K 0]

2 minutes ago, dxp said:

Разработать свои гибкие модули, чтобы уйти от деревянных корок, чтобы потом их опять засунуть в корки? :)

Ну понятно, что вариант не айс. Но для моих целей так было проще ибо модуль был один и создавался он в общем, не для дикого дублирования, а скорее для "изоляции" внутреннойстей от необходимости длугим разработчикам из команды лезть внутрь модуля. Просто подключить в BD и забыть.

Опять таки, пример достаточно гибкий в настройке и переделке, а своя корка отличается от проприетарной - возможностью полного контроля и подстройки под личные нужды (к примеру FIFO с программируемыми значениями almost_full и almost_empty)

5 minutes ago, des00 said:

согласен, ну а других вариантов особо нет. В код, в комментарии вставлять тоже не вариант, хранить готовые шаблоны и по месту править в них параметры(если надо), все же удобнее. А без привязки, тяжко будет, модуль же может быть с любыми именем инстанса, если еще и имена править по месту(в скрипте) совсем тяжко будет

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

[des00 25]

4 minutes ago, Nick_K said:

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

ну это по сути оно и есть. подключение своих sdc файлов, вид сбоку)

[blackfin 18]

2 hours ago, dxp said:

Дано два клока с периодами 10 нс и 8 нс (100 МГц и 125 МГц).

И сразу вопрос: "Как нам поможет код Грея, если мы хотим передать данные из домена с большей частотой в домен с меньшей частотой?"

 

То есть, если Fsrc = 125 МГц, Fdst = 100 МГц.

[Avex 1]

3 hours ago, dxp said:

Дано два клока с периодами 10 нс и 10 нс, но источниками клоков являются разные внешние генераторы. Вопрос: какой будет setup relationship? Моё понимание: 0! Т.е. так как источники разные и неидеальные, то частота и фаза одного постоянно плывут относительного частоты и фазы другого. Т.е. рано или поздно наступает момент, когда от Launch Clock Edge до Latch Clock Edge временной промежуток стремится к нулю. Как в этой ситуации работать с этими клоками, объявив их синхронными? Вот этого я и не понимаю. Объясните, пожалуйста?

Вы правильно описали явление асинхронности, плывущие фазы и т.д.. Но вот вопрос - а что вообще зависит от констрейнтов? Ответ - задержки внутри CDC, и больше ничего. Вопрос - а какая будет задержка, если обьявить клоки синхронными? Ответ - не ноль точно. Потому, что есть такая штука как clock latency. Пусть в вашем примере в блоке CDC у первого клока летенси 2.5нс, а у второго 7.5нс (я писал выше, что деревья надо разделять, делать независимыми). Это значит, что тул будет считать (при условии, что клоки объявлены синхронными), что клоки приходят с фазой, сдвинутой на 5нс отн. друг друга. Получаем ограничение на сигналы в CDC - 5нс в одну сторону и 5нс в другую. Т.е. после синтеза у вас в чипе в этом CDC сигналы будут разбредаться не более чем на полтакта. Вас это устроит? Если да, то подход имеет право на жизнь. Если нет - обьявляйте клоки асинхронными и далее как обычно.

[Avex 1]

56 minutes ago, blackfin said:

Как нам поможет код Грея, если мы хотим передать данные из домена с большей частотой в домен с меньшей частотой?

На мой взгляд, единственное преимущество кода Грея - это отправлять данные (значения счетчика) в другой клоковый домен - без хендшейка (подтверждения приема). И работает это только при условии, что коды на шине меняются реже, чем их успевают принимать. Как только это условие перестает выполняться, код Грея становится бесполезен, и надо искать другое решение. К примеру - отправлять бинарное (не кодированное) значение счетчика, но с хендшейком. В этом случае синхронизатор нужен только в хендшейке, а шинные сигналы можно протащить через CDC напрямую.

[dxp 36]

24 минуты назад, Aleх сказал:

Пусть в вашем примере в блоке CDC у первого клока летенси 2.5нс, а у второго 7.5нс (я писал выше, что деревья надо разделять, делать независимыми). Это значит, что тул будет считать (при условии, что клоки объявлены синхронными), что клоки приходят с фазой, сдвинутой на 5нс отн. друг друга. Получаем ограничение на сигналы в CDC - 5нс в одну сторону и 5нс в другую. Т.е. после синтеза у вас в чипе в этом CDC сигналы будут разбредаться не более чем на полтакта.

Так эти временные соотношения справедливы для какого-то конкретного текущего момента. А через полчаса фазы уплыли, потому что у одного генератора период был 10.0001 нс, а у другого 9.9999 нс. Да и при включении питания какие были начальные фазы, когда генераторы начали выдавать клоки? Это всё полный рандом. И как тут взаимные фазы (сдвиги) клоков оценить?

[dxp 36]

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

И сразу вопрос: "Как нам поможет код Грея, если мы хотим передать данные из домена с большей частотой в домен с меньшей частотой?"

 

То есть, если Fsrc = 125 МГц, Fdst = 100 МГц.

И в чём вы видите проблему? Например, исходное значение счётчика на передающей стороне было 000 и приёмная сторона сграбила это значение, дальше передатчик гонит 001, 011, 010, 110, 111... В какой-то момент времени приёмная сторона сэмплирует значение, передаваемое ей через синхронизаторы, пусть, например, это момент, когда на вход синхронизатора попадает переход 010->110 (т.е. поменялось два бита относительно исходного значения. Из-за возможной метастабильности приёмник может увидеть одно из: 010, 110. В обоих случаях никакой катастрофы нет - либо видим текущее значение, либо предыдущее. Главное, чтобы все сигналы этой шины укладывались в ограничения, чтобы не было перекоса, чтобы за такт менялся только один бит. Это гарантирует, что на приёмной стороне мы получим валидное значение. И не важно, как часто или редко мы его сэмплируем. Конечно, будет некий "джиттер" получаемого значения, что может приводить к "плавающей" латентности получения информации (read_data_count порт будет подвирать в меньшую сторону) , но это неизбежное "зло". Но передача работает корректно.

[blackfin 18]

2 minutes ago, dxp said:

Но передача работает корректно.

OK

[RobFPGA 27]

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

4 hours ago, des00 said:

5 hours ago, dxp said:

 А как в случае собственных модулей автоматизировать подключение констрейнов? Существует какой-нибудь способ или только руками не забывать и ничего не путать?

Хоть и не Rob, но если я правильно помню, есть же возможность подключить свой cdc файл, где описать требуемые соотношения чем маску объявления модуля. Правда в таком случае требуется уникальность имен. 

Да так и есть - Основное место где сосредоточенно CDC (и соответственно тайминги) в асинхронном FIFO это  модуль gray-code CDC.  Соответственно мной отдельно писан такой модуль,  а к нему  TCL констрейн  на подобии  такого-же  как и для xpm_cdc_gray.

В Vivado  у меня этот  констрейн указан как SCOPED_TO_REF=gray_cdc и и PROCESSING_ORDER=late  к моему модулю gray_cdc. Соответственно если где я использую  такой CDC модуль (не важно в FIFO или как отдельный модуль)  Vivado берет этот констрейн  и применяет его ко всем инстансам  gray_cdc. И при этом эти инстансы выступают как current_instance для данного констрейна - то есть как топ, без всякой иерархии. В самом  же  констрейне  берутся имена и значения таймингов клоков на портах wr_clk|rd_clk модуля. Вычисляется минимальный из двух и задаются ограничения на пути синхронизации между регистрами взятыми по маске " set_bus_skew  -from [get_cells wr_gray*] -to [get_cells rd_gray*] [expr 0.9 * (min ($wr_clk_period, $rd_clk_period))]".

Похожее фактически и в Qu -  только там нет механизма привязки констрейнов к рефернс модулю (или я не нашел)
Пришлось в скрипте констрейна ваять функцию  поиска всех инстансов  gray_cdc  в нетлисте и затем уж, в цикле, выделения клоков, регистров и расчет и задание ограничений.

4 hours ago, dxp said:

Т.е. руками в проект зацеплять надо, не забыть. И жесткая привязка к именам тож не айс.

Чтобы не забыть - я  такие готовые модули упаковываю в IP library, которая доступна  в репозитории для всех моих проектов. 

Удачи! Rob.

 

[dxp 36]

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

В Vivado  у меня этот  констрейн указан как SCOPED_TO_REF=gary_cdc и и PROCESSING_ORDER=late  к моему модулю gray_cdc. 

Это в свойствах проекта вы указываете? Или где? А если новый проект начинаете? Или у вас есть "болванка" проекта, где уже это всё добавлено?

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

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

Но Вивада же не сама их назначает current_instance. Это у вас в скрипте оно по именам модулей фильтрует и дальше уже работает с ними или вы явно прописываете имена (с путями)?

[RobFPGA 27]

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

23 minutes ago, dxp said:

Это в свойствах проекта вы указываете? Или где? А если новый проект начинаете? Или у вас есть "болванка" проекта, где уже это всё добавлено?

У меня все такие основные  RTL модули собраны и упакованы в IP library, которая доступна  в репозитории для всех моих проектов.  На эту  library я ссылаюсь если использую какой либо модуль (FIFO, CDC,...) в любом своем IP core. На из этой же  library я вставляю модуль в совой RTL проекта. 

Хотя можно такое и в болванке проекта  в TCL скрипте сделать - SCOPED_TO_REF=gray_cdc и и PROCESSING_ORDER=late задаются в свойствах конкретного файла констрейна.

4 hours ago, dxp said:

Разработать свои гибкие модули, чтобы уйти от деревянных корок, чтобы потом их опять засунуть в корки? :)

Это не IP core,  это именно RTL library без всякого GUI  - только сборник нужных RTL и констренов к ним.   А в Qu  все тоже в  .qip "упакованно".

23 minutes ago, dxp said:

Но Вивада же не сама их назначает current_instance. Это у вас в скрипте оно по именам модулей фильтрует и дальше уже работает с ними или вы явно прописываете имена (с путями)?

Сама - если указали SCOPED_TO_REF=имя_модуля Vivado сама найдет все инстансы  этого модуля  и применит к каждому из них этот констрейн,  причем как к топу (без иерархии).  При этом на входах модуля будут актуальные клоки.

Удачи!  Rob.

[gin 0]

4 часа назад, Aleх сказал:

На мой взгляд, единственное преимущество кода Грея - это отправлять данные (значения счетчика) в другой клоковый домен - без хендшейка (подтверждения приема). И работает это только при условии, что коды на шине меняются реже, чем их успевают принимать. Как только это условие перестает выполняться, код Грея становится бесполезен, и надо искать другое решение. К примеру - отправлять бинарное (не кодированное) значение счетчика, но с хендшейком. В этом случае синхронизатор нужен только в хендшейке, а шинные сигналы можно протащить через CDC напрямую.

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

Изменено 20 апреля, 2020 пользователем gin

[RobFPGA 27]

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

4 hours ago, Aleх said:

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

Это не так -  Грей  работает нормально (при соблюдении условий линейности и ограничения  skew) при любом соотношении частот - от дробных до  кратных. 

2 minutes ago, gin said:

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

Так и есть  - если код не линейный  Грей не работает вообще.  
Причем это принципиально разные ситуации -  подавать на gray_cdc  нелинейный код  или случайно сэмплировать на приемной частоте выход с gray  с линейным кодом. 

Удачи! Rob.