[5EN5E 0]

Добрый день, господа! В проекте имеется сигнал ready, формируемый на тактовом сигнале clk1. Есть фифо, в которое я пишу по сигналу ready на частоте clk2. Соотношение частот clk1/clk2 = 1.9. По факту, ready это сигнал link_up от корки, т.е. пишем в фифо по готовности корки, которая работает в своем клоковом домене. Поскольку клоки не кратны друг другу, то рано или поздно фронты обоих клоков наползут так, что вылезет метастабильность. С ней, по классике жанра, боремся при помощи пары регистров на clk2. Однако, временной анализатор ругается, предупреждая о негативных слаках. Собсно, вопрос: достаточно ли просто задать false_path на данный путь или есть еще какие-нибудь подводные камни, из-за которых в неожиданный момент запись в буфер встанет колом?

[RobFPGA 27]

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

2 minutes ago, 5EN5E said:

Добрый день, господа! В проекте имеется сигнал ready, формируемый на тактовом сигнале clk1. Есть фифо, в которое я пишу по сигналу ready на частоте clk2.

Это зачем?  Раз ready сидит в clk1 то и пишите в FIFO в этом же клоке.  А читайте из FIFO по clk2.  Dual clock асинхронное FIFO как раз для этого и придумано. И вся черная магия синхронизации будет происходить внутри FIFO.

Удачи! Rob.

[5EN5E 0]

На частоте clk2 у меня работает совсем другой интерфейс. Данные с clk2 я как раз и перевожу на clk1, но только в том случае, когда корка в домене clk1 поднимет свой link_up. 

[RobFPGA 27]

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

18 minutes ago, 5EN5E said:

На частоте clk2 у меня работает совсем другой интерфейс. Данные с clk2 я как раз и перевожу на clk1, но только в том случае, когда корка в домене clk1 поднимет свой link_up. 

А... тогда  если это асинхронщина то лучше сразу сделать эти клоки asynchronous через set_clock_groups чтобы еще где не вылезло. Тогда отдельно не нужно задавать false-path для каждой цепи. 

Удачи! Rob.

[5EN5E 0]

RobFPGA, низкий поклон!

[new123 0]

5 hours ago, RobFPGA said:

через set_clock_groups чтобы еще где не вылезло. Тогда отдельно не нужно задавать false-path для каждой цепи

у меня при таком подходе все равно анализатор ругается, добавляю false_path

[RobFPGA 27]

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

6 minutes ago, new123 said:

у меня при таком подходе все равно анализатор ругается

Значит что то не так делаете или у вас не этот случай.

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

Удачи! Rob.   

[gosha-z 2]

Про -include_generated_clocks не забыли?

[new123 0]

1 hour ago, RobFPGA said:

Если клоки объявлены асинхронными то  проверок на тайминги  между этими  клоками нет. 

Да, я не уточнил. Сейчас почитал, посмотрел свои sdc. У меня объявлены как --exclusive

1 hour ago, RobFPGA said:

отменили/перекрыли это объявлени

далее по sdc обложил их multicycle

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

[dxp 32]

@5EN5E, а целевая ПЛИС какая? За альтеру уже не скажу, не помню, а на Xilinx/Vivado вместо ручных синхронизаторов лучше использовать xpm_cdc_single (или подобное). Там сразу прикладывается правильный констрейн 'set_max_delay -datapath_only', что корректнее, нежели 'set_false_path'.

[5EN5E 0]

3 hours ago, dxp said:

@5EN5E, а целевая ПЛИС какая? За альтеру уже не скажу, не помню, а на Xilinx/Vivado вместо ручных синхронизаторов лучше использовать xpm_cdc_single (или подобное). Там сразу прикладывается правильный констрейн 'set_max_delay -datapath_only', что корректнее, нежели 'set_false_path'.

Kintex 7. Подменил рукописные синхронизаторы на макрос xpm_cdc_single и действительно, подцепилась цепочка синхронизации с соответствующими констрейнами. Анализатор молчит, чем меня радует Ради любопытства залез поглядеть на констрейн:

# 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. \n     Instance: [current_instance .] \n  This will add unnecessary latency to the design. Please check the design for the following: \n 1) Manually instantiated XPM_CDC modules: Xilinx recommends that you remove these modules. \n 2) Xilinx IP that contains XPM_CDC modules: Verify the connections to the IP to determine whether you can safely ignore this message."
}

Таки set_false_path кидается на путь.

[dxp 32]

Да, действительно, set_max_delay -datapath_only прикладывается только в xpm_cdc_handshake и xpm_cdc_gray. В случае xpm_cdc_single они посчитали это излишним. Наверное это правильно для такого простого случая.

[Flip-fl0p 4]

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

Я работаю с Xilinx.

Допустим у меня есть синхронизатор, с правильными атрибутами синтеза. Назовём его my_CDC Применяется для переноса одиночных сигналов между доменами.

У меня есть 2 клока. clk_a и clk_b. Они между собой асинхронны.

У меня есть передача данных из домена clk_a --> clk_b.

Часть данных передается через классическое дуалклоковое FIFO , сгенерированное в Vivado.

Другая часть данных передается через мои синхронизаторы my_CDC

Из за того, что я применил FIFO я не имею права объявлять клоки асинхронными: 

set_clock_groups -asynchronous -group {group_A  clk_a} \
                               -group {group_B  clk_b}

 Поскольку внутри FIFO уже есть встроенные констрейны set_max_delay -datapath_only, которые будут игнорироваться, т.к set_max_delay имеет меньший приоритет чем set_clock_groups.

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

А как мне бы это автоматизировать, или каким хитрым скриптом по названию модуля автоматически назначать set_false_path ?

 

[RobFPGA 27]

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

3 minutes ago, Flip-fl0p said:

Из за того, что я применил FIFO я не имею права объявлять клоки асинхронными: 

Вот так раз!  С чего бы это так? 

 Локальные констрейны  на отдельные цепи в IP  имеют более высокий приоритет чем глобальные. Вы можете убедится в этом выведя командой write_xdc -exclude_physical actual.xdc полный список актуальных констейнов после синтеза или P&R. 

К тому же  задавая локальные констрейны  привязанные к IP вы можете указать  когда их следует применять по отношению к пользовательским (early, normal, late).  Ну а пример как задавать локальные кострейны при CDC c автоматическим расчетом времени вы можете посмотреть в ..../Vivado/version/data/ip/xpm/xpm_cdc/tcl

Удачи! Rob.

[Avex 1]

Почему бы вместо set_clock_groups -async не воспользоваться исключением в виде set_false_path?  Я уже несколько лет вообще не пользуюсь set_clock_groups -async. Но, опять же - в эсик флоу.