Все не так страшно. Простой расчет: сигнал сопровождения к шине (т.е. строб) задерживается на 2 такта пересинхронизации в приемной части. Это значит, что данные могут задержаться не более чем на 2 такта относительно прихода строба. Если приемная частота 100 МГц, получаем 20нс - это очень много, откуда в ПЛИС такие задержки роутинга через матрицу интерконнекта? Далее, из приемной части должен прийти сигнал подтверждения приема. который задерживается на 2 такта в пересинхронизаторах передающей части, прежде чем выставятся новые данные. Итого, разброс задержек для шины между двумя клоковыми доменами составляет +/- 2 такта, или около +/- 20н (100 МГц), что очень много.
Опасность возникает, только если частоты под гигагерц, или если на границе клоковых доменов добавлена логика (изредка встречается, хотя я бы руки за такое отрывал) - вот тогда действительно нужно использовать малтисайкл 2.

Полностью согласен, задержка при передаче от триггера к триггеру (если между ними нет комбинационной логики) в современных ПЛИС занимает мало времени. Так что констрейтить, думаю там действительно не стоит, а то это уже какой то паранойей попахивает)

Что то я совсем не так делаю...

Не хочет Квартус отключать выбранные пути из анализа. Из-за этого к чертям все времянки летят. Когда анализирую отдельно основную часть проекта (которая на 156 Мгц работает) - он пишет, что может ее и на 230 МГц вытянуть. Когда подключаю дополнительный модуль, работающей на 50 МГц, который изредка обменивается данными с основным, то все рушится. Вместо 156 Квартус дает только 105 МГц (это при том, что раньше он 230 гарантировал!!!). И в отчете как раз междоменные и заваливают частоту.

И как мне этот проклятый констрейт правильно задать?!

Сообщение отредактировал gin - Mar 30 2017, 07:26

да вроде не сложно

set_false_path -from [get_clocks clk_1] -to [get_clocks clk_2]
set_false_path -from [get_clocks clk_2] -to [get_clocks clk_1]

или
set_false_path -rise_from <clk_1> -rise_to <clk_2>
set_false_path -rise_from <clk_2> -rise_to <clk_1>
ну и от падающего до восходящего и наоборот если есть работы по разным фронтам

не забывайте что надо как вперед, так и назад

Тоже так подумал, что надо в обе стороны описывать, вроде помогло. Вот что значит, поплакался на форуме, и заработало))

Очень заинтересовало Ваше сообщение. Надоело после команды derive_pll_clocks врукопашную править имена всех клоков на смысловые. Не сможете ли примерчик подкинуть?

Кстати да, а то писать эти длинные имена вручную очень утомительно. Да и при изменениях в проекте эти имена ведь тоже меняются. Хочется автоматизировать

Сделайте через GUI в TimeQues. Команда будет продублирована в командной строке. Скопируйте её и вставте в свой SDC файл.

Спасибо! Но это как раз понятно. Здесь строчку
rx_10g_inst|rx_10g_inst|xv_xcvr_10gbaser_nr_inst|ch[0].sv_xcvr_10gbaser_native_i
nst|g_fpll.altera_pll_156M~PLL_OUTPUT_COUNTER|divclk
всё равно придётся писать вручную (копипастить). Например у меня название клока такое spll1|pll1_inst|altera_pll_i|general[0].gpll~PLL_OUTPUT_COUNTER|vco1ph[0], а после пересборки проекта вполне может вместо vco1ph[0] оказаться vco1ph[1],естественно сыпятся все ограничения. Тогда приходится ручками перебивать все имена. Я эту ситуацию имел ввиду.

Можно попробовать получить идентификатор и имя выходного пина PLL по имени clock net:
А потом непосредственно сделать имя клока из имени пина, или, по-научному, перебрать все клоки, и выбрать те, у которых target равен $pin_name

Спасибо! Как появится "окно" в работе обязательно попробую.