[starley 0]

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

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

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

[SM 0]

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

[sleep 0]

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

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

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

[SM 0]

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

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

[oratie 0]

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

 

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

[grigorik 0]

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

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

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

[grigorik 0]

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 0]

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

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

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

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

Изменено 28 февраля, 2009 пользователем starley

[grigorik 0]

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 0]

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:

[starley 0]

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

 

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.

[SM 0]

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

[starley 0]

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

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

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

[grigorik 0]

Похоже, вы правы. А 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.