[attaboy 0]

При просмотре лога синтеза обнаружил информационное сообщения такого рода (Vivado 2020.1):

Quote

WARNING: [Project 1-498] One or more constraints failed evaluation while reading constraint file [/home/user/prj/constr1.xdc] and the design contains unresolved black boxes. These constraints will be read post-synthesis (as long as their source constraint file is marked as used_in_implementation) and should be applied correctly.

INFO: [Project 1-236] Implementation specific constraints were found while reading constraint file [/home/user/prj/constr1.xdc]. These constraints will be ignored for synthesis but will be used in implementation. Impacted constraints are listed in the file [.Xil/constr1_propImpl.xdc].

Resolution: To avoid this warning, move constraints listed in [.Xil/constr1_propImpl.xdc] to another XDC file and exclude this new file from synthesis with the used_in_synthesis property (File Properties dialog in GUI) and re-run elaboration/synthesis

Посмотрел файл .Xil/constr1_propImpl.xdc. Там много констрейнов, причем как моих, так и от IP-ядер.

Возникла мысль разделить хотя бы свои констрейны на два файла - один для синтеза/имплементации и другой - только для имплементации. Однако я не нашел четкого критерия, когда нужно применять какие констрейны. В UG903 есть глава под названием "Creating Synthesis Constraints", там есть некоторые рекомендации. Но, например, в этой главе говорится, что для синтеза можно использовать команду set_clock_groups. А мне Вивадо порекомнедовала ограничение с такой командой перенести в имплементацию.

Соответственно вопрос: есть ли четкие критерии, какие ограничения использовать для синтеза, а какие - для имплементации?

[Nick_K 0]

Насколько мне известно прямо чёткого разграничения на констрейны нет.

Да обьявление частоты, создание генерированной и разные multicycle/false_path нужны для синтеза безусловно. Но вото ситуативные констрейны типа груп виртуальных клоков и т.д. являются именно ситуативными. Ибо если клоковая группа нужна для некого флорплана, тогда в синтезе она бесполезна, а вот если между клок группами обьявлен мультицикл - тогда это влияет на синтез напрямую.

Точно так же разные "физические" констрейны относятся только к имплементации, как локация на кристалле или специфические компоненты в схеме. Конечно это можно проанализировать для своего проекта и посортировать, но под глобальное правило это не вписывается.

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

Пусть меня поправят, но для чистоты отчётов я бы посоветовал перевести все констрейны с обращением к физическим обьектам в раздел имплементируемых констрейнов и оставить всё остальное для синтеза.

[attaboy 0]

2 hours ago, Nick_K said:

Пусть меня поправят, но для чистоты отчётов я бы посоветовал перевести все констрейны с обращением к физическим обьектам в раздел имплементируемых констрейнов и оставить всё остальное для синтеза.

Это наиболее логично.

По остальным ограничениям не все так просто. Например на команду:

set_false_path -from [get_clocks -ob_objects [get_pins instance_name/inst/mmcme3_adv_inst/CLKOUT0]]

синтезатор выдает предупреждение:

Quote

WARNING: [Vivado 12-508] No pins matched 'instance_name/inst/mmcme3_adv_inst/CLKOUT0'

И предлагает перенести это ограничение в implementation.

Я открываю пост-синтез дизайн и там есть этот объект.

В принципе можно игнорировать такие предупреждения, в расчете на то, что во время имплементации эти ограничения будут применены. Но есть опасность, что действительно путь будет записан неправильно и огнаничение не будет применено. Конечно можно проанализировать лог после имплементации и сравнить, не исчезло ли предупреждение. Но хотелось бы, чтобы таких предупреждений не было и на этапе синтеза.

Изменено 18 марта, 2021 пользователем attaboy

[Nick_K 0]

13 minutes ago, attaboy said:

По остальным ограничениям не все так просто. Например на команду:

set_false_path -from [get_clocks -ob_objects [get_pins instance_name/inst/mmcme3_adv_inst/CLKOUT0]]

синтезатор выдает предупреждение:

Всё правильно. Данный IP инстанциируется только после синтеза, а во время него присутствует только как black box. О чём также говорят названия портов. На синтезе их нет, вот и синтезатор ругается.

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