Tik31 0 2 июля, 2021 Опубликовано 2 июля, 2021 · Жалоба Здравствуйте! Имеется мультиклоковый проект с передачей данных из одного домена в другой. Необходимо сформировать файл ограничений. Для синхронизации сигналов, передаваемых между доменами, применяется стандартный 2FF синхронизатор. module sync #( parameter int unsigned STAGES = 2 ) ( input clk_i, input rst_ni, input serial_i, output serial_o ); logic [STAGES-1:0] reg_q; always_ff @(posedge clk_i, negedge rst_ni) begin if (!rst_ni) begin reg_q <= 'h0; end else begin reg_q <= {reg_q[STAGES-2:0], serial_i}; end end assign serial_o = reg_q[STAGES-1]; endmodule В качестве ограничений изначально я хотел использовать команду вида: set_false_path -to [ get_pins { */sync_inst/reg_q[0]/D} ] Однако во время изучения вопроса я обнаружил, что некоторые источники указывают, что нужно применять конструкцию вида: # Период принимающего домена set BCLK 10 set_max_delay $BCLK -to [ get_pins { */sync_inst/reg_q[0]/D} ] Сейчас у меня сформировалось следующее мнение: Если я передаю отдельный сигнал, не связанный с другими, то мне следует использовать set_false_path. Если же я передаю, например, пару сигналов (DATA, WE), то нужно использовать set_max_delay, чтобы сигналы достигли приемника в пределах одного такта (Мне почему-то кажется, что я не верно это понимаю). Прошу подтвердить или опровергнуть корректность моих суждений. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
blackfin 24 2 июля, 2021 Опубликовано 2 июля, 2021 · Жалоба 8 minutes ago, Tik31 said: ... некоторые источники указывают, что ... Не нужно пользоваться "некоторыми источниками".. Пользуйтесь только проверенными источниками: set_clock_groups ‑asynchronous ‑group <args> Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 2 июля, 2021 Опубликовано 2 июля, 2021 · Жалоба 23 minutes ago, Tik31 said: Если же я передаю, например, пару сигналов (DATA, WE), то нужно использовать set_max_delay, чтобы сигналы достигли приемника в пределах одного такта (Мне почему-то кажется, что я не верно это понимаю). для самого строба через CDC достаточно задать асинхронные группы, но если по этому стробу, в другой домен передаются данные, то, в общем случае, надо действительно ограничить задержку их пути распространения до длины синхронизатора, во избежание проблем. Но в ПЛИС это редко делают, т.к. роутер минимизирует длинну разводки и типовые длины там в пределах 5-10нс, что достаточно для частот 200-300МГц. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tik31 0 2 июля, 2021 Опубликовано 2 июля, 2021 · Жалоба Спасибо за ответы. Единственное, как мне кажется, это применение фальш путей вместо асинхронных групп позволит выявить при анализе пути не проведенные через CDC. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 2 июля, 2021 Опубликовано 2 июля, 2021 · Жалоба 27 minutes ago, Tik31 said: Спасибо за ответы. Единственное, как мне кажется, это применение фальш путей вместо асинхронных групп позволит выявить при анализе пути не проведенные через CDC. хозяин барин, но вообще там отдельная проверка на синхронизаторы идет Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
new123 0 2 июля, 2021 Опубликовано 2 июля, 2021 (изменено) · Жалоба Сама альтера рекомендует асинхр группы + задание set_net_delay set_max_skew. Так они кстати в своих фифошках делают. Не могу сходу найти отдельный мануал у них. Там подробно рассказывается, почему это немного лучше false_path. Но вот тоже ихhttps://www.intel.com/content/www/us/en/programmable/support/support-resources/knowledge-base/tools/2017/how-do-i-constrain-my-clock-domain-crossing-.html Изменено 2 июля, 2021 пользователем new123 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
blackfin 24 2 июля, 2021 Опубликовано 2 июля, 2021 · Жалоба 38 minutes ago, new123 said: Сама альтера рекомендует асинхр группы + задание set_net_delay set_max_skew. На кой тут set_max_skew ? ТС собирается передавать через CDC один-единственный сигнал! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andrew_b 16 2 июля, 2021 Опубликовано 2 июля, 2021 · Жалоба 1 час назад, des00 сказал: для самого строба через CDC достаточно задать асинхронные группы, но если по этому стробу, в другой домен передаются данные, то, в общем случае, надо действительно ограничить задержку их пути распространения до длины синхронизатора, во избежание проблем. Но в ПЛИС это редко делают, т.к. роутер минимизирует длинну разводки и типовые длины там в пределах 5-10нс, что достаточно для частот 200-300МГц. Вот что пишут на форуме Xilinx: Цитата Цитата or can I just tell Vivado that these 2 clocks are unrelated, so I don't need to specify the paths in detail? Absolutely not. https://forums.xilinx.com/t5/Timing-Analysis/how-to-constrain-a-CDC/td-p/748174 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
blackfin 24 2 июля, 2021 Опубликовано 2 июля, 2021 · Жалоба 3 minutes ago, andrew_b said: Вот что пишут на форуме Xilinx: А как вы догадались, что ТС пишет код для Xilinx'а ? В самом первом сообщении ТС'а об этом не сказано ни слова.. А в Quartus'е подобные атрибуты отсутствуют, ЕМНИП.. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tik31 0 2 июля, 2021 Опубликовано 2 июля, 2021 · Жалоба Пишу для Microchip. Нашел в UG: производитеь рекамендует использовать set_clock_group. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andrew_b 16 2 июля, 2021 Опубликовано 2 июля, 2021 · Жалоба 20 минут назад, blackfin сказал: А как вы догадались, что ТС пишет код для Xilinx'а ? В самом первом сообщении ТС'а об этом не сказано ни слова. Раз конкретики нет, почему бы не воспользоваться тем, что рекомендуют для Xilinx? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
blackfin 24 2 июля, 2021 Опубликовано 2 июля, 2021 · Жалоба 29 minutes ago, andrew_b said: Раз конкретики нет, почему бы не воспользоваться тем, что рекомендуют для Xilinx? И как вы предлагаете воспользоваться атрибутом ASYNC_REG, которого в Quartus'е (да и в тулах Microchip'а, видимо тоже) нет в принципе? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 30 2 июля, 2021 Опубликовано 2 июля, 2021 · Жалоба Приветствую! 2 hours ago, Tik31 said: Если я передаю отдельный сигнал, не связанный с другими, то мне следует использовать set_false_path. Если же я передаю, например, пару сигналов (DATA, WE), то нужно использовать set_max_delay, чтобы сигналы достигли приемника в пределах одного такта (Мне почему-то кажется, что я не верно это понимаю). Через обычный синхронизатор нельзя передавать "связанные" данные. Такой синхронизатор не гарантирует одновременность передачи таких данных даже если зададите конкретные задержки для данных между доменами. Связанные данные передают только через синхронизаторы с хэндшейком!. И в этом случае задержка для пути данных должна быть меньше задержки в цепочке синхронизации хендшейка. Поэтому для одиночных синхронизаторов без разницы - false-path или max_delay, во втором случае вы лишь будете уверенны что сигнал по не будет "гулять" непонятно где. 20 minutes ago, blackfin said: И как вы предлагаете воспользоваться атрибутом ASYNC_REG, которого в Quartus'е (да и тулах Microchip'а, видимо тоже) нет в принципе? У каждого вендора должно быть нечто похожее - у Qu например есть (* ALTERA_ATTRIBUTE = "-name SYNCHRONIZER_IDENTIFICATION FORCED_IF_ASYNCHRONOUS" *) Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dr.Alex 0 2 июля, 2021 Опубликовано 2 июля, 2021 · Жалоба 3 hours ago, Tik31 said: Однако во время изучения вопроса я обнаружил, что некоторые источники указывают, что нужно применять конструкцию вида: # Период принимающего домена set BCLK 10 set_max_delay $BCLK -to [ get_pins { */sync_inst/reg_q[0]/D} ] Сейчас у меня сформировалось следующее мнение: Если я передаю отдельный сигнал, не связанный с другими, то мне следует использовать set_false_path. Если же я передаю, например, пару сигналов (DATA, WE), то нужно использовать set_max_delay, чтобы сигналы достигли приемника в пределах одного такта (Мне почему-то кажется, что я не верно это понимаю). Вы всё точно понимаете, set_false_path НЕЛЬЗЯ (работать будет лишь случайно, хотя и в большинстве случаев), а set_max_delay - правильно и нужно. Ломал тут копья много лет назад на эту тему, ссылку на дискуссию специально не привожу, хотя она сохранилась, так как аргументы обычно никому не нужны, а нужен лишь конечный результат. Вот он. https://forums.xilinx.com/t5/Vivado-TCL-Community/How-to-set-timing-constraint-in-this-case/td-p/510641 avrumw (Expert): Except for the "single slow changing signal" clock crosser, almost all clock crossing circuits need constraints - setting them as false paths underconstrains the clock crossing circuit, which can result in system failure. For most circuits, you need a set_max_delay -datapath_only constraint on the path between the domains. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
blackfin 24 2 июля, 2021 Опубликовано 2 июля, 2021 · Жалоба 11 minutes ago, RobFPGA said: У каждого вендора должно быть нечто похожее - у Qu например есть (* ALTERA_ATTRIBUTE = "-name SYNCHRONIZER_IDENTIFICATION FORCED_IF_ASYNCHRONOUS" *) Хмм. А можно ссылку на документ? Вот специально прошелся поиском по Quartus Handbook v17 и не нашел этого атрибута.. Видимо, какой-то новодел. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться