Jump to content
    

Прошу немного помощи по Synopsys DC

Для конвертации LEF в FRAM в милкивее требуется указывать помимо самого конвертируемого файла еще и файлы, которых технологическая информация извлекается (Tech LEF) и файл для соответствий номеров слоев и их названий. Сразу два вопроса по этому поводу.

Нафига ему номера слоев, если при создании библиотеки он уже запрашивал tech файл, в котором эти номера уже и так есть?

Мой генератор памяти помимо самого LEF для блока генерит еще и LEF для проверки "antenna rules". Его тоже подсовывать милкивею? Зачем вообще FRAM описании эта информация нужна? Чтобы случайно не добавить лишнего металла в первом слое, вызвав нарушение оного правила?

Share this post


Link to post
Share on other sites

Про соответствие слоев - это соответствие слоев в LEF (и с геометрией, и с технологией) тому, что будет во FRAM, там же не обязательно те же номера должны остаться.... Про то, что это за антенный LEF, я к сожалению не знаю.

Share this post


Link to post
Share on other sites

Под "LEF для проверки "antenna rules" ", наверное имеется ввиду .lef, в котором находится информация только по ANTENNADIFFAREA и ANTENNAGATEAREA (вроде так эти параметры в .lef называются) для пинов блоков. Эти данные нужны для проверки и исправления антенного эффекта.

А в отдельном .lef вся основная информация для блоков(OBS, все полигоны и др).

Соответственно, ответ на 2 вопрос - если Вы собираетесь исправлять антенный эффект в туле, которому скармливаете FRAM, - то знание об антенных свойствах пинов блоков ему нужны и конвертировать данный .lef в FRAM необходимо.

Share this post


Link to post
Share on other sites

то знание об антенных свойствах пинов блоков ему нужны и конвертировать данный .lef в FRAM необходимо.

FRAM же это чистая графика. Так что вряд-ли это получится

Share this post


Link to post
Share on other sites

Получится, правда не знаю, где будет хранится эта информация (в самом FRAM или в lib), но такая инфа должна присутствовать в Milkyway db. Другой путь запихивания её в Milkyway это через clf файл (команды dbDefineAntennaRule, dbAddAntennaLayerRule, defineGateSize, defineDiodeProtection.

 

Если вы загрузите antenna LEF, а потом выгрузите clf, то должны увидеть какие-то из этих команд.

Share this post


Link to post
Share on other sites

Получится, правда не знаю, где будет хранится эта информация (в самом 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.

Share this post


Link to post
Share on other sites

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

Еще сложилось впечатление, что без плана кристалла (floorplan), синтез в топографическом режиме вещь несколько отвлеченная. В чем лучше его делать в Юпитере или в Астро?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Под макроблоком имею в виду хард-макро памяти. db и FRAM сделал и синтезатору передаю.

Насчет координат, то что могу сам дать - это понятно, только, по-моему, синтезатору виднее, где их располагать (если он, конечно, это умеет).

Под иерархическим дизайном понимается дизайн, отдельные части которого физически реализуются по отдельности, а потом объединяются как макроблоки?

Лог синтезатора выложу после выходных.

Edited by starley

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

 

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.

Стало быть придется еще и с Юпитером разбираться :smile3046:

Share this post


Link to post
Share on other sites

Вот фрагмент лога, который меня смущает. Ослабление временных констрейнов не помогает. Констрейны на размещение пока никакие не задавал.

 

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.

Share this post


Link to post
Share on other sites

Возможно, слишком большая утилизация (set_utilization) стоит, и оно не может все правильно разместить с таким требованием к утилизации.

Share this post


Link to post
Share on other sites

Возможно, слишком большая утилизация (set_utilization) стоит, и оно не может все правильно разместить с таким требованием к утилизации.

Вы правы. Уменьшение утилизации помогло. Спасибо.

Судя по всему, это из-за того, что суммарная площадь макросов в блоке ощутимо больше площади ячеек и расставить все с большой утилизацией действительно невозможно.

Share this post


Link to post
Share on other sites

Похоже, вы правы. А Physical Compiler умел PDEF писать. Тогда получается, что от умения ДЦ расставлять макроблоки толку почти никакого. А из каких же тогда соображений расставлять макроблоки вручную - почти от балды что-ли?

И вообще, мне тогда не понятен смысл топографического синтеза. Получается, что задержки вычисляются и дизайн оптимизируется для одного расположения ячеек, а после бэк-энд расположение будет совсем другим. Понятно, что это лучше чем wireload, но почему нельзя было сделать возможность выгрузки хотя бы координат макроблоков?

 

 

Стало быть придется еще и с Юпитером разбираться :smile3046:

 

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...