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

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

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

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

Почитайте нашего коллегу с форума http://www.kit-e.ru/articles/plis/2010_10_54.php

А вообще - это команда, использовать которую *нельзя*.
Надо сетфальспасить только конкретные пути. Это приходит с опытом, поэтому убеждать не буду.

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

Для задания асинхронных клоков нужно пользоваться командой set_clock_groups а не set_false_path.
Чтобы автоматически описать клоки от внутренних PLL, есть команда derive_pll_clocks.
Также можно вручную их описать с помощью create_generated_clock.
Для сокращения длинных плохо читаемых автоматически созданных имён можно использовать макроподстановки TCL.

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



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

Узнать - из отчёта 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

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

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

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

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

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

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

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

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 просто убирает из анализа данные пути (которые между двумя клоками), так как их фактически невозможно обконстрейтить, они ведь асинхронные.

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

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

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