set_false_path Как правильно задать в TimeQuest Опции

[gin]

Всем добрый день!
Есть следующий вопрос - в проекте имеется 2 клоковых домена. Между ними происходит обмен данными. Как задать в TimeQuest условие, чтобы он не учитывал пути между этими доменами в расчете?
Как я понимаю, есть команда set_false_path :

set_false_path -from [get_clocks __sourceClock] -to [get_clocks __destinationClock]

но как в ней описать клоки, которые формируются на внутренних PLL?

Сообщение отредактировал gin - Mar 7 2017, 11:08

[Shivers]

но как в ней описать клоки, которые формируются на внутренних PLL?

Сначала объявить эти клоки, а потом сделать их асинхронными через set_false_path.

[gin]

Сначала объявить эти клоки, а потом сделать их асинхронными через set_false_path.

Я наверное не совсем точно описал задачу.
Описаны входные клоки:

Код

derive_clock_uncertainty
create_clock -period "50 MHz" -name {clk_sys} {clk_sys}
create_clock -period "322.265625 MHz" -name {clk_ref} {clk_ref}
derive_pll_clocks

Из этих входных клоков затем формируются клоки (на PLL), на которых работает внутренняя логика. И для этих внутренних клоков нужно написать false path. Но эти внутренние клоки имеют какие то сложные внутренние названия. Вот как их узнать и задать?

[Timmy]

Из этих входных клоков затем формируются клоки (на PLL), на которых работает внутренняя логика. И для этих внутренних клоков нужно написать false path. Но эти внутренние клоки имеют какие то сложные внутренние названия. Вот как их узнать и задать?

Узнать - из отчёта TimeQuest по всем клокам.

[gin]

Узнать - из отчёта TimeQuest по всем клокам.

То есть я правильно понял Вас?
Вот например, в отчете у меня есть клок 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
и есть клок pll_sys_inst|pll_sys_inst|altera_pll_i|general[0].gpll~PLL_OUTPUT_COUNTER|divclk

и я могу их использовать в команде set_false_path как sourceClock и destinationClock

[Timmy]

То есть я правильно понял Вас?
Вот например, в отчете у меня есть клок 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
и есть клок pll_sys_inst|pll_sys_inst|altera_pll_i|general[0].gpll~PLL_OUTPUT_COUNTER|divclk

и я могу их использовать в команде set_false_path как sourceClock и destinationClock

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

[gin]

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

Спасибо!
Т.е. команда будет выглядеть следующим образом?

set_false_path -from {get_clocks 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} -to {get_clocks pll_sys_inst|pll_sys_inst|altera_pll_i|general[0].gpll~PLL_OUTPUT_COUNTER|divclk
}
И чем отличаются фигурные скобки от квадратных? В Альтеровском примере они вроде как квадратные

Если таки "происходит обмен данными", то фолспасить есесно нельзя.

Можно правда и совсем не констрейнить, но только если этот обмен идёт через чужую корку (например фифо), которая уже правильно законстрейнена внутри.

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

Сообщение отредактировал gin - Mar 7 2017, 14:45

[Timmy]

Спасибо!
Т.е. команда будет выглядеть следующим образом?

set_false_path -from {get_clocks 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} -to {get_clocks pll_sys_inst|pll_sys_inst|altera_pll_i|general[0].gpll~PLL_OUTPUT_COUNTER|divclk
}
И чем отличаются фигурные скобки от квадратных? В Альтеровском примере они вроде как квадратные

set_false_path -from [get_clocks {rx_10g_inst|rx_10g_inst|xv_xcvr_10gbaser_nr_inst|ch[0].sv_xcvr_10gbaser_native_
inst|g_fpll.altera_pll_156M~PLL_OUTPUT_COUNTER|divclk}] -to [get_clocks {pll_sys_inst|pll_sys_inst|altera_pll_i|general[0].gpll~PLL_OUTPUT_COUNTER|divcl
k}]
По поводу скобок учебник языка TCL почитайте. В большинстве примеров фигурные скобки не нужны, так как имена клоков не содержат внутри себя символов макроподстановки( [] и $ )

[gin]

set_false_path -from [get_clocks {rx_10g_inst|rx_10g_inst|xv_xcvr_10gbaser_nr_inst|ch[0].sv_xcvr_10gbaser_native_
inst|g_fpll.altera_pll_156M~PLL_OUTPUT_COUNTER|divclk}] -to [get_clocks {pll_sys_inst|pll_sys_inst|altera_pll_i|general[0].gpll~PLL_OUTPUT_COUNTER|divcl
k}]
По поводу скобок учебник языка TCL почитайте. В большинстве примеров фигурные скобки не нужны, так как имена клоков не содержат внутри себя символов макроподстановки( [] и $ )

Спасибо! Буду теперь знать, а то с tcl практически не приходилось иметь дело

Сами-то поняли чё сказали? Если УЖЕ всё по феншую, то и никаких указаний от вас уже не требуется.

Если же переход через клок-домены всё-таки самопальный и никто кроме вас его ещё не констрейнил, то констрейнить НАДО, но ФОЛСПАСИТЬ НЕЛЬЗЯ.

Не понял, а почему собственно нельзя?
Ведь false path просто убирает из анализа данные пути (которые между двумя клоками), так как их фактически невозможно обконстрейтить, они ведь асинхронные.

[Dr.Alex]

Ведь false path просто убирает из анализа данные пути (которые между двумя клоками), так как их фактически невозможно обконстрейтить, они ведь асинхронные.

Их не только можно обконстрейнить, а нужно.
Если разброс в длинах путей превысит 1 период приёмного клока, то ваш клок-домэйн-кроссинг работать не будет.
Конечно, если вы сделаете строб, запаздывающий на 100 тактов от данных, то можно и не констрейнить. Но вряд ли кто-то так делает.

Shivers говорит что он не встречал, чтобы такой разброс был, а вот я встречал.
Зато к примеру я не встречал, чтобы какой-то прожект не разводился на 10 МГц тактовой.
Но это не значит что тактовую не надо констрейнить, тем более что это просто.

[Shivers]

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