Как побороть ситуацию, при которой Vivado "нагоняет" искусственную задержку на входных сигналах больше периода клока ?

Клок задерживается на BUFG, поэтому, с точки зрения Vivado, строб попадает на "предыдущий" клок. Но поскольку клок непрерывный, это не имеет никакого значения.
С другой стороны, если поставить false path или maxdelay, то можно попасть в область нестабильности - проверки не будет.

С формальной точки зрения он делает все правильно, посмотрите в сторону мультициклов (как задать в вивадо - не знаю).

С ультраскейл не работал, однако бегло глянув на ug572, я бы попробовал захватывать данные клоком не с глобального буфера, а непосредственно с пина.
"Thus, the 7 series regional clock buffers have been replaced by new clock buffers with more global reach while automatically utilizing local clock buffers for local distribution of the clocks."
Идея, возможно, в том, чтобы люди жали на кнопки и ни о чём не думали..

Увы, мне надо два разных региона синхронизировать потом.

Multicircle с 0, такое ощущение, что работает неправильно. Т.е. отсчитывать он начинает от правильного фронта, но строит что-то жуткое, и радостно рапортует от промахе больше, чем на период.

set_multicycle_path правильно работает для входов, если проделать неочевидные манипуляции с hold. Научился управлять через него.

Вообще, если это истинно синхронный интерфейс с стробирующим входным клоком, то можно еще попробовать воспользоваться ограничениями set_input_delay - max/min и Ваш период к этим значениям прибавить. Таким образом, временной анализатор будет считать, что данные в нулевой точке анализа будут задержаны на один период.

А виртуальный клок не для этого придуман?

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

Виртуальный клок нужен в основном для наглядности работы.

К сожалению, в обсуждении этой темы я не заметил конкретных цифр: периода тактовой, величин задержек в BUFG (для обоих крайних случаев), да и про данные, которые необходимо принимать - тоже мало что сказано.

А частичное описание проблемы, типа:
очень похоже на проблему, с которой я сталкивался в ISE при работе с Virtex-6 LX240T/SX315T: огромная неопределённость прохождения сигнала по BUFG.
Для расчёта Setup бралась величина от 3 до 5 нс (от ПЛИС зависело), а для расчёта Hold - около 0.5 нс. Естественно, при временном анализе проекта для передачи данных где-то на 200 MT/s получалась херня: по Setup улетаем на следующий период, а по Hold остаёмся в текущем.

У Вас, случаем, не подобная ситуация ?
И, пожалуста, если не сложно, укажите конкретные цифры.

Тактовая 300 Мгц, внутри местами 600 Мгц.

Проблема в способе отсчета фронта для hold по умолчанию - это описано в документации. Когда набегает задержка, сравнимая с периодом, это приводит к ошибке, если явно не задавать. Это, кажется, Vivado-специфичная вещь.
И второе, что не описано - если используется PLL с обратной связью через BUFG (phase aligned), похоже, для расчета setup прибавляется целый период, а при расчете hold - не прибавляется. (Я и от входного клока пробовал тактировать, и от PLLльного).

Вот я как раз и хотел посоветовать работать от PLL'ного Clock'а, с компенсацией кривизны BUFG, за счёт обратной сзязи. Но без конкретных цифр, это было бы неправильно.

К сожалению, с Vivado-специфичными бякостями я пока помочь не смогу - мне ещё не приходилось работать с Vivado. Так случилось, что сейчас меня используют на схемотехку вокруг ПЛИС (в т.ч. US/US+), а вот до внутренностей у меня руки пока ещё не дошли: есть другие люди, которые могут работать внутри ПЛИС и совсем не могут проектировать внешнюю обвязку.

И по такой входной частоте проконсультироваться не у кого из знакомых: либо передаём совсем медленные сигналы (до 50 MT/s), либо уже используем более высокоскоростные интерфейсы (DDR3/4) с тренировкой (подбором входной задержки). В обоих случаях на constraint’ы для I/O ног забивается. Ещё, конечно, очень активно используются MGT – но они к этой теме никак не относятся.

Аккуратная проверка с калькулятором показывает, что это самый плохой вариант, хотя интуитивно он кажется самым лучшим. Разница best/worst case для задержек в линиях превышает период для 300 Мгц, поэтому и сигнал где-то да и попадет в зону метастабильности.

Оптимальный вариант - стробировать входные входным же клоком, а то, что после PLL, считать асинхронным. При использовании PLL Vivado честно пытается "накрутить" трассы для компенсации ухода задержек по клок во всем диапазоне. В общем, работает, как задумано, но результат не соответствует усилиям.

Если нужно фиксировать фазу между входным и выходным клоком, надо это делать динамически с использованием iserdes/oserdes и приличного количества логики.

А Вы бы констрейнты свои запостили сюда. И тайминг-репорты, которые сомнения вызывают.
Дело в том, что set_input_delay надо констрейнить с обоими ключами max и min, как было сказано выше, причем max констрейнится по сетапу, а min - по холду от предыдущего цикла. То же касается и малтисайклов - они обычно используется парой по сетапу и холду, причем по холду указывается цифра на единичку меньше. Несоблюдение этих тонкостей иногда приводит к расколбасу в STA.

Я разобрался, у меня сейчас сомнений нет и все работает. Мультициклы в данном случае использовать просто нельзя. Они заставят пропустить софт возможные метастабильные состояния. По умолчанию он правильно считает и пытается скомпенсировать разбег клоков длиной пути (причем не с целью выровнять время, а с целью уменьшить разбег setup-hold), но при больших задержках в клоке это не помогает.