grigorik
Feb 27 2009, 16:52
Цитата(oratie @ Feb 20 2009, 11:55)
Получится, правда не знаю, где будет хранится эта информация (в самом FRAM или в lib), но такая инфа должна присутствовать в Milkyway db. Другой путь запихивания её в Milkyway это через clf файл (команды dbDefineAntennaRule, dbAddAntennaLayerRule, defineGateSize, defineDiodeProtection.
Если вы загрузите antenna LEF, а потом выгрузите clf, то должны увидеть какие-то из этих команд.
Если вы загрузите antenna LEF, antenna info будет хранится в самом FRAM.
Tochno, Если вы потом выгрузите antenna clf то должны увидеть какие-то из этих команд.
Eto zavisit eshyo iz versii Milkyway. Est takie kommandi v LEF chto starie versii Milkyway ne poderjivayut.
starley
Feb 27 2009, 22:06
Есть несколько проблем при синтезе в топографическом режиме. DC в логе выдает несколько сообщений о том, что не может выполнить констрэйны на макроблоке. При этом в тайминг репорте никаких проблем не обнаруживается. Кроме этого, есть сообщение о таймауте выполнения размещения элементов. Хотя несколько других проходов завершены нормально. Что это с ним? И вообще интересно как он размещает автоматически макроблоки?
Еще сложилось впечатление, что без плана кристалла (floorplan), синтез в топографическом режиме вещь несколько отвлеченная. В чем лучше его делать в Юпитере или в Астро?
grigorik
Feb 28 2009, 09:43
Kogda vi govorite макроблок vi imeite vvidu hard macro ? vi dali .db v link_libarary ? U vas est FRAM dlya makro block?
Dlya makroblokov vi mojete dat koordinati sami po komande set_cell_location.
Chtobi ponyat problemu davaite log syuda posmotrim (esli eto vi xotite konechno).
Floorplan mojno i sdelat v DC topographical. Budet xorosho esli vi dadite DC topo tot floorplan kotori budete ispolzovat vo vremya okonchatelnogo P&R.
JupiterXT eto dlya hierarchich designs.
Astro dlya flat designs.
Tak chto zavisit iz vashego designa.
Udachi
starley
Feb 28 2009, 20:28
Под макроблоком имею в виду хард-макро памяти. db и FRAM сделал и синтезатору передаю.
Насчет координат, то что могу сам дать - это понятно, только, по-моему, синтезатору виднее, где их располагать (если он, конечно, это умеет).
Под иерархическим дизайном понимается дизайн, отдельные части которого физически реализуются по отдельности, а потом объединяются как макроблоки?
Лог синтезатора выложу после выходных.
grigorik
Mar 1 2009, 10:00
DC topo umeyet i mojet raspolagt makro bloki. No kak vi znayte vi ne smojete uznat kuda DC topo postavil macro block, i drugie celli.
Pro ierarxhicheki design vi pravi, dobavlyu v Jupitere mojete sozdat floorplan top designa i potom Jupiter iz floorplana topa poluchit floorplani vsex child design ov. Eshyo Jupiter is constraintov top -a poluchit constrainti child blokov kotorie vi budete ispolzovat dlya otdelnix blockov.
Tak chto esli u vas malenki block i ne nujno sdelat vishe skazannoe to vi smojete sdelat floorplan v Astro.
starley
Mar 3 2009, 10:35
Цитата(grigorik @ Mar 1 2009, 13:00)
DC topo umeyet i mojet raspolagt makro bloki. No kak vi znayte vi ne smojete uznat kuda DC topo postavil macro block, i drugie celli.
Похоже, вы правы. А Physical Compiler умел PDEF писать. Тогда получается, что от умения ДЦ расставлять макроблоки толку почти никакого. А из каких же тогда соображений расставлять макроблоки вручную - почти от балды что-ли?
И вообще, мне тогда не понятен смысл топографического синтеза. Получается, что задержки вычисляются и дизайн оптимизируется для одного расположения ячеек, а после бэк-энд расположение будет совсем другим. Понятно, что это лучше чем wireload, но почему нельзя было сделать возможность выгрузки хотя бы координат макроблоков?
Цитата(grigorik @ Mar 1 2009, 13:00)
Pro ierarxhicheki design vi pravi, dobavlyu v Jupitere mojete sozdat floorplan top designa i potom Jupiter iz floorplana topa poluchit floorplani vsex child design ov. Eshyo Jupiter is constraintov top -a poluchit constrainti child blokov kotorie vi budete ispolzovat dlya otdelnix blockov.
Стало быть придется еще и с Юпитером разбираться
starley
Mar 3 2009, 13:27
Вот фрагмент лога, который меня смущает. Ослабление временных констрейнов не помогает. Констрейны на размещение пока никакие не задавал.
CODE
Information: Running stand-alone coarse placer in a separate process (PSYN-605)
Information: Executable name is '/usr/synopsys/Z-2007.03-SP1/linux/syn/bin/rpsa_exec'. (PSYN-877)
...25%...
Warning: Placer unable to satisfy constraints on macro cell fc_apb_unit_i/EmptyBuffers_FIFO_I/dp_memory32x1024_i1. (PSYN-362)
Warning: Placer unable to satisfy constraints on macro cell RxData_FIFO_I/dp_memory32x2048_i1. (PSYN-362)
Warning: Placer unable to satisfy constraints on macro cell axi_slave_write_channel_i/TX_Messages_FIFO_I/dp_memory64x512_i. (PSYN-362)
Warning: Placer unable to satisfy constraints on macro cell FC_Sequences_Controller_i/transmitting_sequences_i/abts_performer_i/abts_context_memory_i/Context_Memory_i/U2. (PSYN-362)
Warning: Placer unable to satisfy constraints on macro cell TxData_FIFO_I1/dp_memory32x1024_i1. (PSYN-362)
Warning: Placer unable to satisfy constraints on macro cell TxData_FIFO_I/dp_memory32x1024_i1. (PSYN-362)
50%...75%...100% done.
Information: Running stand-alone coarse placer in a separate process (PSYN-605)
Information: Executable name is '/usr/synopsys/Z-2007.03-SP1/linux/syn/bin/rpsa_exec'. (PSYN-877)
...13%...25%...
Warning: Placer unable to satisfy constraints on macro cell fc_apb_unit_i/ReadyBuffers_FIFO_1_I/dp_memory32x1024_i1. (PSYN-362)
Warning: Placer unable to satisfy constraints on macro cell fc_apb_unit_i/Ports_Table_LSW_I/mem. (PSYN-362)
Warning: Placer unable to satisfy constraints on macro cell axi_slave_write_channel_i/TX_Messages_FIFO_I1/dp_memory64x512_i. (PSYN-362)
Warning: Placer unable to satisfy constraints on macro cell axi_slave_write_channel_i/TX_Messages_FIFO_I/dp_memory64x512_i. (PSYN-362)
Warning: Placer unable to satisfy constraints on macro cell LS_TxData_FIFO_I/dp_memory32x512_i1. (PSYN-362)
Warning: Placer unable to satisfy constraints on macro cell TxData_FIFO_I/dp_memory32x1024_i1. (PSYN-362)
38%...50%...63%...75%...88%...100% done.
Возможно, слишком большая утилизация (set_utilization) стоит, и оно не может все правильно разместить с таким требованием к утилизации.
starley
Mar 4 2009, 05:45
Цитата(SM @ Mar 3 2009, 17:49)
Возможно, слишком большая утилизация (set_utilization) стоит, и оно не может все правильно разместить с таким требованием к утилизации.
Вы правы. Уменьшение утилизации помогло. Спасибо.
Судя по всему, это из-за того, что суммарная площадь макросов в блоке ощутимо больше площади ячеек и расставить все с большой утилизацией действительно невозможно.
grigorik
Mar 4 2009, 22:23
Цитата(starley @ Mar 3 2009, 14:35)
Похоже, вы правы. А Physical Compiler умел PDEF писать. Тогда получается, что от умения ДЦ расставлять макроблоки толку почти никакого. А из каких же тогда соображений расставлять макроблоки вручную - почти от балды что-ли?
И вообще, мне тогда не понятен смысл топографического синтеза. Получается, что задержки вычисляются и дизайн оптимизируется для одного расположения ячеек, а после бэк-энд расположение будет совсем другим. Понятно, что это лучше чем wireload, но почему нельзя было сделать возможность выгрузки хотя бы координат макроблоков?
Стало быть придется еще и с Юпитером разбираться
Voobshe-to zavisit ot kolichestvo makro blokov. Esli ix u vas slishkom mnogo i vi ne smojete naiti optimalnie mesta dlay makro blokov vruchnuyu to ya bi posovetoval takoe
Iteration: #1 synthesis v DC topo bez constrantov na macro blocki i avtomaticheski sdelat macro placement v back end tool(Astro ili ICC). Posle chego vi smojete uznat priblizitelnie coordinati macro blockov. Iteration: #2 Vospolzuites etimi coordinatami v DC topo i sdelaite eshyo odin synthesis. Vospolzuites tem je coordinatami macro blockov v back end i sdelaite place and route.
смысл топографического синтеза sostoit v tom chto resultati ICC placement i DC topo placemnt korrelirovani (mojed i daje odno i samoe ya ne uveren na 100%). Vot i eto privodit k tomu chto back end raspolojenie ne budet dast drugie resultati.
Pro etot vopros: но почему нельзя было сделать возможность выгрузки хотя бы координат макроблоков? Sprosite synopsys -a.
U synopsysa daje est novinka DC dlya congestion optimization vo vreamya RTL synthesis. Eto kakoi to enhancement v DC topo daje est greficheski vozmojnosti v DC vi mojete uvidet congested mesta.
Udachi.
starley
Mar 5 2009, 16:31
Цитата(grigorik @ Mar 5 2009, 01:23)
Iteration: #1 synthesis v DC topo bez constrantov na macro blocki i avtomaticheski sdelat macro placement v back end tool(Astro ili ICC). Posle chego vi smojete uznat priblizitelnie coordinati macro blockov. Iteration: #2 Vospolzuites etimi coordinatami v DC topo i sdelaite eshyo odin synthesis. Vospolzuites tem je coordinatami macro blockov v back end i sdelaite place and route.
Разве бэк-энд делает расстановку макроблоков с оптимизацией по временным параметрам? У меня сложилось впечатление, что он их от балды расставляет. Это ведь делается на этапе планирования, когда еще ничего о задержках неизвестно. Я думаю пока ручками расставлять, вроде не сильно сложно.
Цитата(starley @ Mar 5 2009, 19:31)
Разве бэк-энд делает расстановку макроблоков с оптимизацией по временным параметрам? У меня сложилось впечатление, что он их от балды расставляет. Это ведь делается на этапе планирования, когда еще ничего о задержках неизвестно.
О задержках уже известно очень многое. Как минимум, что с чем соединено, у кого какая мощность выхода и емкость входа. А также все констрейны. Исходя из этого уже вполне можно прикидывать оптимальное размещение по приблизительным длинам трасс и минимизации суммы этих длин, но с ограничением макс. длины для вписывания в констрейны.
Правда, не каждый бэк-энд тул умеет вращать/переворачивать макроблоки. А для блоков с большим количеством выводов или большой площади это бывает очень критично. Поэтому (как и предлагает starley) лучше один раз прогнать бэк-енд в авто режиме, посмотреть куда он поставил макросы, а дальше уже самому ставить их (с поворотом или без...).
А вот интересно, DC Graphical это отдельная приблуда, или просто фича обычного DC Topo?
starley
Mar 5 2009, 20:32
Цитата(SM @ Mar 5 2009, 19:48)
О задержках уже известно очень многое. Как минимум, что с чем соединено, у кого какая мощность выхода и емкость входа. А также все констрейны. Исходя из этого уже вполне можно прикидывать оптимальное размещение по приблизительным длинам трасс и минимизации суммы этих длин, но с ограничением макс. длины для вписывания в констрейны.
Вот если бы он вместе с ячейками макроблоки расставлял, - тогда да, а поскольку он их сами по себе расставляет, то вряд ли. Во всяком случае то размещение, которое он мне сделал совсем не было похоже на оптимальное.
grigorik
Mar 5 2009, 22:23
Цитата(SM @ Mar 5 2009, 22:39)
А вот интересно, DC Graphical это отдельная приблуда, или просто фича обычного DC Topo?
Eto kakoi add on na sushestvuyushii DC topo. Kak ya ponyal licenzia nujna.
Цитата(starley @ Mar 6 2009, 00:32)
Вот если бы он вместе с ячейками макроблоки расставлял, - тогда да, а поскольку он их сами по себе расставляет, то вряд ли. Во всяком случае то размещение, которое он мне сделал совсем не было похоже на оптимальное.
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.
Цитата(grigorik @ Mar 6 2009, 01:23)
Eto kakoi add on na sushestvuyushii DC topo. Kak ya ponyal licenzia nujna.
Лицензия не вопрос. Главное - это отдельно устанавливаемый пакет, или оно уже включено в пакет syn ?
grigorik
Mar 6 2009, 17:52
Цитата(SM @ Mar 6 2009, 13:54)
Лицензия не вопрос. Главное - это отдельно устанавливаемый пакет, или оно уже включено в пакет syn ?
оно уже включено в пакет syn, topographical shell (dc_shell-topo).
Цитата(grigorik @ Mar 6 2009, 20:52)
оно уже включено в пакет syn, topographical shell (dc_shell-topo).
Хм. А доки на этот режим есть? Хотелось бы узнать, как им пользоваться, но sold у меня всего лишь 2007.09, и там ни слова.
grigorik
Mar 6 2009, 22:08
Цитата(SM @ Mar 6 2009, 22:30)
Хм. А доки на этот режим есть? Хотелось бы узнать, как им пользоваться, но 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
Цитата(SM @ Mar 6 2009, 22:30)
Хм. А доки на этот режим есть? Хотелось бы узнать, как им пользоваться, но sold у меня всего лишь 2007.09, и там ни слова.
DC-topo Synthesis Training
Цитата(Losik @ Mar 7 2009, 21:02)
DC-topo Synthesis Training
Пожалуйста, будьте внимательнее. Я не просил документации и тренинга по topographical, я в нем работаю уже года полтора.
starley
Mar 20 2009, 07:22
Назрел тут еще один вопрос.
А как правильно определять DRC констрейны, в смысле, исходя из каких соображений? Например, в доках рекомендуется задавать либо max_fanout и max_transition, либо max_fanout и max_capacitance. Какой вариант лучше и как выбрать значения? Или можно положиться на заданные в библиотеке значения?
Что делает DC при обнаружении нарушения DRC?
Еще непонятно в чем смысл приоритетов этих констрейнов. Например, max_transition имеет приоритет над max_fanout. По смыслу ведь все констрейны должны быть выполнены, какие тут могут быть приоритеты?
oratie
Mar 20 2009, 10:07
Если 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 например.
starley
Mar 22 2009, 21:21
Спасибо за ответы.
То есть действуем тут методом подбора до тех пор пока не удастся развестись на нужную частоту и нулевую сумму DRC. Что означает, если эта сумма после процесса оптимизации ненулевая - задачка решения не имеет? Можно ли как-нибудь определить какой именно DRC констрейн нарушен и где?
По опыту с xilinx знаю, что максимальная рабочая частота после размещения и разводки влегкую оказывается раза в полтора больше той, что была предсказана по результатам синтеза. А насколько обычно далеки результаты синтеза в топографическом режиме DC от того, что будет получено после разводки?
oratie
Mar 23 2009, 07:37
> Можно ли как-нибудь определить какой именно DRC констрейн нарушен и где?
report_constraint -all_violators
> А насколько обычно далеки результаты синтеза в топографическом режиме DC
Обычно, результаты после размещения/разводки немного хуже, чем после синтеза. Могу порекомендовать, задать для синтеза немного более высокую частоту, чем планируете для финального дизайна.
Цитата(starley @ Mar 23 2009, 00:21)
То есть действуем тут методом подбора до тех пор пока не удастся развестись на нужную частоту и нулевую сумму DRC.
В общем - да. Экспериментируем с разными там set_flatten, set_structure, set hdlin_xxxxx = ???, set compile_xxxxx = ?, ну и т.д. Так же правим исходники по результатам отчетов по критическим путям...
Цитата(starley @ Mar 23 2009, 00:21)
Что означает, если эта сумма после процесса оптимизации ненулевая - задачка решения не имеет? Можно ли как-нибудь определить какой именно DRC констрейн нарушен и где?
Это все в общем прикидки. Решение рассматривается исключительно после разводки - там в графике все будет видно как на ладони, где и что нарушилось, и там же in-place чаще всего можно их и пофиксить. А на небольшие нарушения рулезов при синтезе можно просто забить.
Какой где нарушен - report_cons -all_v
Цитата(starley @ Mar 23 2009, 00:21)
По опыту с xilinx знаю, что максимальная рабочая частота после размещения и разводки влегкую оказывается раза в полтора больше той, что была предсказана по результатам синтеза.
А по опыту с lattice - то после synplify тайминги +-10%, А после прецижена - хуже раза в три, чем он предсказал. Этот опыт совершенно не о чем.
Цитата(starley @ Mar 23 2009, 00:21)
А насколько обычно далеки результаты синтеза в топографическом режиме DC от того, что будет получено после разводки?
плюс минус процентов 10. Причем вот три разные итерации, в двух улучшение от предсказанного, в одной ухудшение.
starley
Mar 23 2009, 15:22
Временные констрейны начинают выполняться только при установке max_trans и max_cap в районе их минимально допустимых значений. Это чревато еще чем-нибудь, кроме увеличения площади, потребляемой мощности и возможных проблем с наводками?
Небольшие нарушения рулезов это порядка нескольких процентов или как?
И еще вопрос (извиняйте если глупый) может ли transition_time для клока внутри микросхемы быть меньше фронта синхроимпульса подаваемого на ее вход?
Цитата(starley @ Mar 23 2009, 18:22)
Временные констрейны начинают выполняться только при установке max_trans и max_cap в районе их минимально допустимых значений. Это чревато еще чем-нибудь, кроме увеличения площади, потребляемой мощности и возможных проблем с наводками?
совершенно не понял вопроса. И вообще - все эти рулезы описаны в либе, обычно их крутить не надо. С какой целью Вы туда сунулись?
Цитата(starley @ Mar 23 2009, 18:22)
Небольшие нарушения рулезов это порядка нескольких процентов или как?
Ну как-то так... Замкнутый круг... Такие, которые можно при PAR пофиксить
Цитата(starley @ Mar 23 2009, 18:22)
И еще вопрос (извиняйте если глупый) может ли transition_time для клока внутри микросхемы быть меньше фронта синхроимпульса подаваемого на ее вход?
Легко. Особенно если IO-пад с триггером шмитта воткнуть. Так тогда вообще на вход ей можно будет синус полать.
starley
Mar 23 2009, 16:19
Цитата(SM @ Mar 23 2009, 18:30)
совершенно не понял вопроса. И вообще - все эти рулезы описаны в либе, обычно их крутить не надо. С какой целью Вы туда сунулись?
Приехали... Я ж про эти констрейны и спрашивал, надо ли их менять и из каких соображений. Из док и объяснений oratie я понял, что эти констрейны можно менять в сторону ужесточения. В моем случае это положительно влияет на тайминги. На самом деле так не надо делать?
У меня DC topo делает последние 3 шага оптимизации (Timing, DRC, Area) 2 раза с запуском расстановщика перед каждым шагом. Второй шаг начинается с площадью, полученной по результатам первого шага, но с другими задержками и DRC стоимостью. Это он влияние межсоединений посчитал или что-то другое?
В доках пока не нашел описания процесса оптимизации для топографического режима
Цитата(starley @ Mar 23 2009, 19:19)
Приехали... Я ж про эти констрейны и спрашивал, надо ли их менять и из каких соображений. Из док и объяснений oratie я понял, что эти констрейны можно менять в сторону ужесточения. В моем случае это положительно влияет на тайминги. На самом деле так не надо делать?
Да, можно, конечно, но я еще не встречал, чтобы это было реально нужно. Он же сам умеет за счет area улучшить timing в процессе оптимизации, что автоматом может уменьшить емкостную нагрузку в критическом пути. А влияния этого параметра на потребляемую мощность я особо не вижу, так как увеличивая емкость растягиваем переходной процесс, но при этом и уменьшаем количество драйверов (на один драйвер даем больше нагрузки), а в сумме-то те же яйца.
Цитата(starley @ Mar 23 2009, 19:19)
Это он влияние межсоединений посчитал или что-то другое?
Да.
starley
Mar 23 2009, 17:10
Цитата(SM @ Mar 23 2009, 19:32)
А влияния этого параметра на потребляемую мощность я особо не вижу, так как увеличивая емкость растягиваем переходной процесс, но при этом и уменьшаем количество драйверов (на один драйвер даем больше нагрузки), а в сумме-то те же яйца.
Ну, например, за счет тока кз - оба транзистора дольше открыты при более длинном переходном процессе. Но это так - домыслы...
Цитата(starley @ Mar 23 2009, 20:10)
Ну, например, за счет тока кз - оба транзистора дольше открыты при более длинном переходном процессе. Но это так - домыслы...
да, но против открытых двух пар транзисторов в течение в два раза более короткого времени это тоже самое
А чудес не бывает. Для удвоения скорости фронта надо либо удвоить ток (а значит W или M транзисторов), либо разделить емкости на две разных ветки с двумя разными буферами.
starley
Mar 24 2009, 22:24
Убедили
starley
Mar 27 2009, 09:40
Кстати о птичках. А из каких соображений выставляется transition_time для клока? В смысле какое значение задавать в команде set_clock_transition.
Цитата(starley @ Mar 27 2009, 12:40)
Кстати о птичках. А из каких соображений выставляется transition_time для клока? В смысле какое значение задавать в команде set_clock_transition.
Исходя из гарантии работоспособности всех целлов и блоков, этот клок юзающий. На длинных транзишенах у них могут начинаться всякие глюки от невыдерживания сетапов/холдов и вплоть до полного "сноса крыши". А какое задавать... Так в библиотеке все уже должно быть.
starley
Mar 27 2009, 19:41
Цитата(SM @ Mar 27 2009, 17:22)
Исходя из гарантии работоспособности всех целлов и блоков, этот клок юзающий. На длинных транзишенах у них могут начинаться всякие глюки от невыдерживания сетапов/холдов и вплоть до полного "сноса крыши". А какое задавать... Так в библиотеке все уже должно быть.
Это ведь верхний предел. Вряд ли именно его стоит задавать на этапе синтеза. По итогам генерации клокового дерева, по идее, должен быть лучший результат получен.
grigorik
Mar 28 2009, 15:42
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.
starley
Apr 9 2009, 20:27
grigorik, спасибо за обстоятельный ответ.
Назрело еще несколько вопросов.
- Как работать правильно с ИО буферами? С одной стороны их удобно добавить в ХДЛ код, но для клока и ресета это не прокатит. Когда же тогда добавлять последние? Ручками в отсинтезированный нетлист?
- Как правильно синтезировать ресет? На клок ставится dont_touch и на этапе реализации генерируется дерево буферов. А для ресета?
- Какие особенности синтеза дизайна с двумя независимыми доменами синхронизации? Вроде как по логике достаточно определить клоки, задержки входных и выходных сигналов для соответствующего клока, ну и констрейны на асинхронные пути между доменами. Но, судя по документации, как-то все не так просто.
Цитата(starley @ Apr 10 2009, 00:27)
- Какие особенности синтеза дизайна с двумя независимыми доменами синхронизации? Вроде как по логике достаточно определить клоки, задержки входных и выходных сигналов для соответствующего клока, ну и констрейны на асинхронные пути между доменами. Но, судя по документации, как-то все не так просто.
думаю гуру согласятся с тем, что это лучшее что есть по теме CDC
Нажмите для просмотра прикрепленного файла
starley
Apr 13 2009, 12:51
2Doka спасибо за доку.
И все-таки, как правильно работать с ИО буферами? Куда и когда их добавлять? В ХДЛ код или в отсинтезированный нетлист?
Цитата(starley @ Apr 13 2009, 16:51)
И все-таки, как правильно работать с ИО буферами? Куда и когда их добавлять? В ХДЛ код или в отсинтезированный нетлист?
Ясно дело в хдл-код. Ведь это чуть ли не главная составляющая задержек входных и выходных сигналов, которые должны констрейниться с учетом буферов и емкостей их внешних нагрузок.
starley
Apr 13 2009, 18:56
Цитата(SM @ Apr 13 2009, 20:30)
Ясно дело в хдл-код. Ведь это чуть ли не главная составляющая задержек входных и выходных сигналов, которые должны констрейниться с учетом буферов и емкостей их внешних нагрузок.
Вот и я так думал. Но тогда загвоздка с синхросигналами и ресетом получается. DC при выполнении STA берет drive ио буфера и рассчитывает исходя из него, например, transition time для клока, Значение, разумеется, получается охрененно большим. Какой тут обходной путь предполагается?
grigorik
Apr 13 2009, 20:01
Цитата(starley @ Apr 13 2009, 22:56)
Вот и я так думал. Но тогда загвоздка с синхросигналами и ресетом получается. DC при выполнении STA берет drive ио буфера и рассчитывает исходя из него, например, transition time для клока, Значение, разумеется, получается охрененно большим. Какой тут обходной путь предполагается?
starley mojet set_ideal_network na vixode IO bufera pomojet?
Цитата(starley @ Apr 13 2009, 22:56)
Вот и я так думал. Но тогда загвоздка с синхросигналами и ресетом получается. DC при выполнении STA берет drive ио буфера и рассчитывает исходя из него, например, transition time для клока, Значение, разумеется, получается охрененно большим. Какой тут обходной путь предполагается?
Ну во первых - возможно вы всунули клоковый буфер. Который вовсе не I/O, а специальный клокодрайвер сверхмощный. Так как драйв у обычных буферов как правило соответствует драйву обычного элемента логики.
starley
Apr 14 2009, 06:40
Цитата(SM @ Apr 14 2009, 10:34)
Ну во первых - возможно вы всунули клоковый буфер. Который вовсе не I/O, а специальный клокодрайвер сверхмощный. Так как драйв у обычных буферов как правило соответствует драйву обычного элемента логики.
Нет, совершенно точно обычный ио буфер.
grigorik
Apr 14 2009, 06:52
Цитата(starley @ Apr 14 2009, 09:40)
Нет, совершенно точно обычный ио буфер.
ubedites chto u vas v constraintax net set_propagated_clock komandi.
Цитата(starley @ Apr 14 2009, 10:40)
Нет, совершенно точно обычный ио буфер.
Тогда остается лишь подозрение, что Вы его туда вставили не той стороной
PAD-ом к ядру...
starley
Apr 14 2009, 15:00
Цитата(SM @ Apr 14 2009, 13:46)
Тогда остается лишь подозрение, что Вы его туда вставили не той стороной
PAD-ом к ядру...
Ну раз пошли такие варианты... Сreate_clock надо делать для входа или для выхода ИО буфера клока?
Если я вас правильно понимаю, - то для входа, а у DC достаточно сообразительности, что бы проигнорировать в расчетах ИО буфер клока и при расчетах использовать то значение transition_time, которое я установил в set_clock_transition?
А как тогда быть с ресетом? Дерево буферов для него обычно генерится на этапе реализации или в DC?
Цитата(grigorik @ Apr 14 2009, 10:52)
ubedites chto u vas v constraintax net set_propagated_clock komandi.
Точно нет, вместо него set_clock_latency и set_clock_uncertainty.
Для просмотра полной версии этой страницы, пожалуйста,
пройдите по ссылке.