Спасибо за ответы.
То есть действуем тут методом подбора до тех пор пока не удастся развестись на нужную частоту и нулевую сумму DRC. Что означает, если эта сумма после процесса оптимизации ненулевая - задачка решения не имеет? Можно ли как-нибудь определить какой именно DRC констрейн нарушен и где?
По опыту с xilinx знаю, что максимальная рабочая частота после размещения и разводки влегкую оказывается раза в полтора больше той, что была предсказана по результатам синтеза. А насколько обычно далеки результаты синтеза в топографическом режиме DC от того, что будет получено после разводки?

> Можно ли как-нибудь определить какой именно DRC констрейн нарушен и где?

report_constraint -all_violators

> А насколько обычно далеки результаты синтеза в топографическом режиме DC

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

В общем - да. Экспериментируем с разными там set_flatten, set_structure, set hdlin_xxxxx = ???, set compile_xxxxx = ?, ну и т.д. Так же правим исходники по результатам отчетов по критическим путям...

Это все в общем прикидки. Решение рассматривается исключительно после разводки - там в графике все будет видно как на ладони, где и что нарушилось, и там же in-place чаще всего можно их и пофиксить. А на небольшие нарушения рулезов при синтезе можно просто забить.
Какой где нарушен - report_cons -all_v

А по опыту с lattice - то после synplify тайминги +-10%, А после прецижена - хуже раза в три, чем он предсказал. Этот опыт совершенно не о чем.

плюс минус процентов 10. Причем вот три разные итерации, в двух улучшение от предсказанного, в одной ухудшение.

Временные констрейны начинают выполняться только при установке max_trans и max_cap в районе их минимально допустимых значений. Это чревато еще чем-нибудь, кроме увеличения площади, потребляемой мощности и возможных проблем с наводками?
Небольшие нарушения рулезов это порядка нескольких процентов или как?
И еще вопрос (извиняйте если глупый) может ли transition_time для клока внутри микросхемы быть меньше фронта синхроимпульса подаваемого на ее вход?

совершенно не понял вопроса. И вообще - все эти рулезы описаны в либе, обычно их крутить не надо. С какой целью Вы туда сунулись?

Ну как-то так... Замкнутый круг... Такие, которые можно при PAR пофиксить

Легко. Особенно если IO-пад с триггером шмитта воткнуть. Так тогда вообще на вход ей можно будет синус полать.

Приехали... Я ж про эти констрейны и спрашивал, надо ли их менять и из каких соображений. Из док и объяснений oratie я понял, что эти констрейны можно менять в сторону ужесточения. В моем случае это положительно влияет на тайминги. На самом деле так не надо делать?

У меня DC topo делает последние 3 шага оптимизации (Timing, DRC, Area) 2 раза с запуском расстановщика перед каждым шагом. Второй шаг начинается с площадью, полученной по результатам первого шага, но с другими задержками и DRC стоимостью. Это он влияние межсоединений посчитал или что-то другое?
В доках пока не нашел описания процесса оптимизации для топографического режима

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

Да, можно, конечно, но я еще не встречал, чтобы это было реально нужно. Он же сам умеет за счет area улучшить timing в процессе оптимизации, что автоматом может уменьшить емкостную нагрузку в критическом пути. А влияния этого параметра на потребляемую мощность я особо не вижу, так как увеличивая емкость растягиваем переходной процесс, но при этом и уменьшаем количество драйверов (на один драйвер даем больше нагрузки), а в сумме-то те же яйца.

Да.

Ну, например, за счет тока кз - оба транзистора дольше открыты при более длинном переходном процессе. Но это так - домыслы...

да, но против открытых двух пар транзисторов в течение в два раза более короткого времени это тоже самое А чудес не бывает. Для удвоения скорости фронта надо либо удвоить ток (а значит W или M транзисторов), либо разделить емкости на две разных ветки с двумя разными буферами.

Убедили

Кстати о птичках. А из каких соображений выставляется transition_time для клока? В смысле какое значение задавать в команде set_clock_transition.

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

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

Vo vremya syntesa set_clock_transition zadayut chtobi modelirovat tranzition time kotoroe budet posle clock tree syntesis (CTS).
Transition time vo vremya CTS vi sami mojete upravlayt zadavaya constrainti.

Kak vibirat tranzition time ? Transition time eto takoe chto zavisit ot texnologi. Transition time Clocka ne doljen bit blizok k verxnemu predelu potomu chto bolshie transitioni na klocke privedut k tomu chto
1. Clock budet slab k Xtalk u. A eto potom mojet privesti funkcionalnim problememam, naprimer DFF mogut izmenyat sostoyani iz-za glicthov kotorie induciruyutsya na clock.
2. Zadavat malenki transition time constraint na clock privedyot k tomu chto CTS engin dobavit mnogo bufferov(invertrov) eto privedyot k bolshim delay-am na clock tree, i bolshemu upotrebleniyu moshnoti Poskolku clock eto signal v sxeme kotori menayert sostoyanie bolshe chem drugie.

Iz-za vishe skazannago mojno naprimer brat constraint ot 60-80% verxnego predela library.
Nu voobshe postoroites vsegda bit v predelax transiton i cpapcitance kotorie naxoditysa v library, potomuschto kogda budete vne etogo diapazona resultati timing analysa budut ne vernimi.
Eshyo nado uchtit chto est 5% nevernost v raschyotax (v toolax) i postoraites v konce proekta imet design gde transiton i max cap bili mali chem 95% predelov.

Luchse vsegdo ostavit max cap/transition fiksirovat vo vremya P&R.


Vsyo vishe skazannoe eto prosto misli iz moego opita yesli kto-to ne soglasen ya budu rad obsudid so vsemi.

Udachi.

grigorik, спасибо за обстоятельный ответ.

Назрело еще несколько вопросов.
- Как работать правильно с ИО буферами? С одной стороны их удобно добавить в ХДЛ код, но для клока и ресета это не прокатит. Когда же тогда добавлять последние? Ручками в отсинтезированный нетлист?
- Как правильно синтезировать ресет? На клок ставится dont_touch и на этапе реализации генерируется дерево буферов. А для ресета?
- Какие особенности синтеза дизайна с двумя независимыми доменами синхронизации? Вроде как по логике достаточно определить клоки, задержки входных и выходных сигналов для соответствующего клока, ну и констрейны на асинхронные пути между доменами. Но, судя по документации, как-то все не так просто.