Разве бэк-энд делает расстановку макроблоков с оптимизацией по временным параметрам? У меня сложилось впечатление, что он их от балды расставляет. Это ведь делается на этапе планирования, когда еще ничего о задержках неизвестно. Я думаю пока ручками расставлять, вроде не сильно сложно.

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

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

А вот интересно, DC Graphical это отдельная приблуда, или просто фича обычного DC Topo?

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

Eto kakoi add on na sushestvuyushii DC topo. Kak ya ponyal licenzia nujna.



Da eto ojidayemi resultat. poskolku tooli ne silni dlya macro placementa. Luchshe samim posmotret leyaout i postavit tak chtobi dlina routinga bila naskolko vozmojna korotkoi.

Лицензия не вопрос. Главное - это отдельно устанавливаемый пакет, или оно уже включено в пакет syn ?

оно уже включено в пакет syn, topographical shell (dc_shell-topo).

Хм. А доки на этот режим есть? Хотелось бы узнать, как им пользоваться, но sold у меня всего лишь 2007.09, и там ни слова.

doka netu. sorry.
sam ne proboval ya prosto sleju za novosyam u synopsysa vot tut
http://www.synopsys.com/Tools/Implementati...rGraphical.aspx

DC-topo Synthesis Training

Пожалуйста, будьте внимательнее. Я не просил документации и тренинга по topographical, я в нем работаю уже года полтора.

Назрел тут еще один вопрос.
А как правильно определять DRC констрейны, в смысле, исходя из каких соображений? Например, в доках рекомендуется задавать либо max_fanout и max_transition, либо max_fanout и max_capacitance. Какой вариант лучше и как выбрать значения? Или можно положиться на заданные в библиотеке значения?
Что делает DC при обнаружении нарушения DRC?
Еще непонятно в чем смысл приоритетов этих констрейнов. Например, max_transition имеет приоритет над max_fanout. По смыслу ведь все констрейны должны быть выполнены, какие тут могут быть приоритеты?

Сообщение отредактировал starley - Mar 20 2009, 07:23

Если max_tran не определён в либе, то DC использует max tran из индексов для LUT. То, есть тот диапазон, в котором была отхарактеризована ячейка (то же самое и для max_cap).

Какой ставить max_tran
- обычно характеризуют ячейку на больший диапазон, поэтому полагаться на max tran из LUT индекса не стоит, ставить на поменьше. Чем меньше ставите, тем меньше проблем будет с cross-talk, но взамен увеличивается мощность, площадь и т.д. Строгих рекомендаций, какой ставить max_tran нет. Для начала возьмите половинку от max tran из индекса.

Какой ставить max_fanout
- посмотрите в библиотеке, прописаны ли там fanout_load для входных пинов (или только capacitance) - если нет, то надо использовать max_capacitance. Если есть, то используйте max_fanout из либы. Если и его нет - тогда вопрос (я использую 30 для внутренних цепей)

Какой ставить max_cap
- можно оставить, тот какой есть в либе (если его нет, то тул сам поставит его равным max cap из LUT индекса).

Подводя итог:
- max_cap и max_tran не могут быть большо чем max индексы для LUT
- никаких методик по определению этих констрэйнтов я не встречал - ставьте их исходя из своего дизайна - он у вас high-speed либо low power либо ещё чего.

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

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