[Tik31 0]

Здравствуйте!

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

Для синхронизации сигналов, передаваемых между доменами, применяется стандартный 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 32]

8 minutes ago, Tik31 said:

... некоторые источники указывают, что ...

Не нужно пользоваться "некоторыми источниками"..

Пользуйтесь только проверенными источниками: set_clock_groups ‑asynchronous ‑group <args>

[des00 25]

23 minutes ago, Tik31 said:

Если же я передаю, например, пару сигналов (DATA, WE), то нужно использовать set_max_delay, чтобы сигналы достигли приемника в пределах одного такта (Мне почему-то кажется, что я не верно это понимаю).

для самого строба через CDC достаточно задать асинхронные группы, но если по этому стробу, в другой домен передаются данные, то, в общем случае, надо действительно ограничить задержку их пути распространения до длины синхронизатора, во избежание проблем. Но в ПЛИС это редко делают, т.к. роутер минимизирует длинну разводки и типовые длины там в пределах 5-10нс, что достаточно для частот 200-300МГц.

[Tik31 0]

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

[des00 25]

27 minutes ago, Tik31 said:

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

хозяин барин, но вообще там отдельная проверка на синхронизаторы идет

[new123 0]

Сама альтера рекомендует асинхр группы + задание 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 32]

38 minutes ago, new123 said:

Сама альтера рекомендует асинхр группы + задание set_net_delay set_max_skew. 

На кой тут set_max_skew ?

ТС собирается передавать через CDC один-единственный сигнал!

[andrew_b 17]

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 32]

3 minutes ago, andrew_b said:

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

А как вы догадались, что ТС пишет код для Xilinx'а ? В самом первом сообщении ТС'а об этом не сказано ни слова.. А в Quartus'е подобные атрибуты отсутствуют, ЕМНИП..

[Tik31 0]

Пишу для Microchip. Нашел в UG: производитеь рекамендует использовать set_clock_group.

 

[andrew_b 17]

20 минут назад, blackfin сказал:

А как вы догадались, что ТС пишет код для Xilinx'а ? В самом первом сообщении ТС'а об этом не сказано ни слова.

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

[blackfin 32]

29 minutes ago, andrew_b said:

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

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

[RobFPGA 35]

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

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]

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 32]

11 minutes ago, RobFPGA said:

У каждого вендора должно  быть нечто похожее - у Qu например  есть 
(* ALTERA_ATTRIBUTE = "-name SYNCHRONIZER_IDENTIFICATION  FORCED_IF_ASYNCHRONOUS" *) 

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