синопсис dc -topo, есть вопросы Опции

[Shivers]

Хотелось бы узнать про основные отличия DC топо-режима от обычного синтеза. Есть ряд вопросов:

1. Как я понял, в этом режиме wire-load модель не используется, а создается что то вроде виртуального флорплана. Первый вопрос - как тогда этот вирт. флорплан сохранять после разводки? Обычные ddc и sdc форматы надо думать информацию о размещении не содержат, а больше ничего я отыскать не смог в доках. По идее, должно сохраняться во что то навроде def файла .. но как?

2. Никогда не занимался топологией, но в топо режиме явно приходится указывать технологические файлы, о которых я имею очень смутное представление. В моем дизайне используется несколько различных либов, и у каждой есть собственный техн. файл. Подключить их вместе не удалось, а когда подключаю один (от основной цифровой либы), то размер селлов из других либов каким то чудесным образом пересчитывается, причем не всегда правильно (не соотвествует area в либе). Как поступить? Должны всех техн. файлы подключаться? Опять же, синопсис понимает только милкивеевский формат, как я понял. Т.е. часть тех файлов вообще не подключается.

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

4. Ну и в целом, есть ли преимущества у -топо перед обычным режимом? Просто, интересно узнать ваше мнение. Может, не стоит и заморачиваться

модераторам: если ошибся форумом, перенесите, плиз.

[oratie]

Первый вопрос - как тогда этот вирт. флорплан сохранять после разводки?

На вход DC-topo можно подавать DEF, а можно синопсисовский floorplan. На выходе, если не использовать ключик -spg, вы не увидите и не сможете передать размещение в PnR тул. Если используете -spg, то размещение сохраняется в DDC и синопсис ICC может восстановит это размещение либо через place_opt -spg либо через restore_spg_placement.

Из тех. файлов DCT требует один Milkyway .tf и TLUPlus для RC экстракции. Для всех библиотек должны быть сделаны Milkyway libraries.

Основное преимущество -topo, это то, что после него ICC показывает такой же тайминг после реального размещения. Если же использовать WLM, то тайминг практически никак не коррелирует с тем, что получен в ICC. (ну за исключением каких-либо особых случаев). Поэтому, лучше использовать topo в связке с синопсис ICC. Если же вы делаете PnR в Cadence - то тут вопрос.

[Shivers]

Спасибо!
А милкивеевские библиотеки сложно делать? Ни разу с Милкивеем не работал. Он открывает .gds или .lef и сохраняет в .tf? Или процесс конверсии както сложно проходит? Буду признателен, если в доку ткнете носом)

p.s. если не сложно, выложите плиз фрагмент tcl, как .lib сконвертировать в .tf в милкивее

p.p.s все что я пока делаю - это в DC использую консольные read_lib, report_lib и write_db - для каждой либы. А потом .db использую при синтезе. Но потом в логе вижу ругань про отсутствие техн. файлов для этих либов.

[oratie]

Нужно использовать тул, который так и называется Milkyway (он подготовит библиотеки для дальнейшего использования в ICC).

Мануал "Library Data Preparation for IC Compiler User Guide" (icclib.pdf), параграф "Library Preparation Using LEF/DEF".

Команда read_lef - её на вход нужно подать технологический lef (из него он сделает и загрузит файл .tf - его потом можно будет выгрузить из библиотеки в ICC командой write_mw_lib_files -technology) и LEF файлы для ячеек (из них он сделает FRAM). Затем, нужно подгрузить GDS файла, чтобы сделать полноценный CEL view - команда read_gds). Это текущий рекомендованный маршрут.

Мы же делаем ещё по старому (к тому же, Milkyway .tf файл у нас уже есть, мы его не получаем из LEF):

cmCreateLib
setFormField "Create Library" "Library Name" "name"
setFormField "Create Library" "Technology File Name" "name.tf"
setFormField "Create Library" "Set Case Sensitive" "1"
formOK "Create Library"

read_lef
formDefault "Read LEF"
setFormField "Read LEF" "Library Name" "name"
setFormField "Read LEF" "Cell LEF Files" "name.lef"
formOK "Read LEF"

dbSetCellPortTypes "name" "name" '(
("VDD" "Power")
("VSS" "Ground")
)#f

auExtractBlockagePinVia
formDefault "Extract Blockage"
setFormField "Extract Blockage" "Library Name" "name"
setFormField "Extract Blockage" "Cell Name" "name"
formOK "Extract Blockage"

auStreamIn
setFormField "Stream In Data File" "Stream File Name" "name.gds"
setFormField "Stream In Data File" "Library Name" "name"
formOK "Stream In Data File"

[Shivers]

Спасибо, буду пробовать!

Возник вопрос. Логику из либов я достаю прямо в DC используя read_lib - write_db. Правильно ли я понимаю, что для правильного синтеза мне осталось вытащить только геометрию?
Т.е. в мануале описан маршрут, когда из LEF с помощью тех. файла делается DEF. А DEF я уже могу зарузить в DC топо

[oratie]

Логику из либов я достаю прямо в DC используя read_lib - write_db

Да, а потом подключаете эти db через переменные target_library и link_library.

Для топо синтеза осталось вытащить геометрию (достаточно только коробочки с пинами и блокеджем по металлу). Это делается путем зачитывания LEF файла на библиотечные ячейки и создания FRAM в Milkyway. Если я не ошибаюсь, сразу после read_lef вы должны увидеть FRAM для каждой ячейки. Затем, с помощью команды set_mw_lib_reference вы подключаете эти созданые Milkyway библиотеки к вашей рабочей либе. Не забудьте ещё прикрутить TLUPlus файлы через set_tlu_plus_files, для RC estimation.

[Shivers]

Спасибо! Все получилось ) LEF->mw_lib->DEF.
Хочу все это в консоль превести, для полуавтоматического режима, т.к. либы меняются изредка. Но пока непонятно, как милкивей в консоли запускать - гуи сразу стартует.

Есть только один косяк непонятный - некоторые селлы имеют не прямоугольную геометрию, а, скажем, буквой Г. При этом, в DEF они получаются как обычный ректангл. Возможно, LEF кривой, не могу проверить. Появился вопрос: Есть разница, откуда брать геометрию - из LEF, или может лучше GDS использовать?

p.s.
И еще вопрос:
В милкивей при создании новой либы нужно указывать техн. файл. Так вот, при подгрузке этого файла выводится ворнинг, что в техн. файле отсуствует RC информация, и нужно подгрузить TLU+ файл. Файл TLU+ у меня есть, но как его подгружать я толком не понял. Нашел только одну команду - replace_tlu_plus_file. Когда я ее (успешно) выполняю, и делаю репорт библиотеки, там по прежнему имеется ворнинг об отсуствии RC. Может, нужно как то по другому TLU+ подгружать?

[oratie]

Milkyway без GUI, но в пакетном режиме:

Код

Milkyway -nogui -load file.name

Есть разница, откуда брать геометрию - из LEF, или может лучше GDS использовать?

Для создания FRAM view лучше использовать LEF - типа там уже всё прописано, но если LEF кривой (что вряд ли, скорее причина в чем-то другом), то можно сначала загрузить GDS, из него автоматически сделается CEL. А затем уже из CEL командой auExtractBlockagePinVia сделать FRAM.

Так вот, при подгрузке этого файла выводится ворнинг, что в техн. файле отсуствует RC информация, и нужно подгрузить TLU+ файл.

Это нормально. Когда запустите dc-topo нужно будет:

Код

open_mw_lib     $mw_design_library
set_tlu_plus_files -max_tluplus $TLUPLUS_MAX_FILE \
                       -min_tluplus $TLUPLUS_MIN_FILE \
                       -tech2itf_map $MAP_FILE
check_tlu_plus_files

[Shivers]

Спасибо!
Сделал mw_lib, остается только подцепить координаты пинов и блоков на флорплане.

А такой вопрос: Если я сделаю расстановку в IC/Encounter и сделаю оттуда экстракцию LEF всех блоков, падов и координат - это не то же самое будет? Или, в FRAM еще какая то полезная информация содержится, кроме геометрии

[oratie]

Насколько мне известно, FRAM похож на LEF. И ничего, кроме геометрии и типа портов (вход, выход, power или signal ...) там нет, так же, как и в LEF.

Только не путайте LEF и DEF. LEF это для описания библиотчных ячеек. А если вам надо передать размещение этих ячеек(или сетку питания, или размещение падов ...) из Encounter в ICC, то нужно использовать def. В DCT для этого есть команда extract_physical_constraints, вы можете открыть layout window в GUI DCT и посмотреть, всё ли передалось через DEF.

[Shivers]

Привет!
Что то получилось, но есть вопрос. У меня никак не получается странслировать расстановку в IC. Просто, хочу посмотреть, что же сделал DC топо при синтезе.
Как делаю: открываю IC с гуями. Создаю mw либу с подцепом тех. файла. Подключаю все референсные mw либы, которые использовал в DC. Открываю созданную либу. Далее, пытаюсь выполнить команду
import_designs design.ddc -format ddc -top design_top -cel floorplan
После чего наблюдаю спам ошибок вида
Error: Cannot create instance master 'какойто селл' in FRAM view. - ругается на все селлы подрят, вывод длится оооочень долго (ждал минут 10 пока закончится, потом срубил через kill -9).

Что я делаю не так?

[oratie]

Проверьте, что список библиотек в link_library (*.db) и референсные либы (milkyway) совпадают. И что они те же самые, что были в DC.

...
Error: Can not create instance master 'oai22x1' in FRAM view. (MWDC-001)
...

How do I resolve this error?

Answer:

This error indicates that a problem occurred while linking your design, and it points to a mismatch between the values of the link_library and reference_library variables.

If you have previously successfully run the Milkyway design and are now facing this error for the first time, your existing Milkyway design library does not match your current link_library or reference_library settings, which means that you can delete the existing Milkyway design and recreate it with your new variables.

If you do not think that anything changed between your two runs, check for the following:

If you used a backslash (\) to create your ref_library and link_library variable values on multiple lines, make sure that there is a space before backslash (\).

set REF_LIBRARIES [ list $lib_path/stdcell \

Make sure you are using the concat Tcl command to combine multiple lists, instead of the list command.

set REF_LIBRARIES [ concat $REF_LIBRARIES $lib_path/other ]

Make sure that you are using the following sequence of commands:

create_mw_lib ... design
set_mw_lib_reference design -mw_reference_library $REF_LIBRARIES

instead of the following Physical Compiler sequence of commands:

set mw_design_library design
set mw_reference_library $REF_LIBRARIES
create_mw_lib ... design

[Shivers]

Спасибо! Помогло ) Все загрузилось и открылось окно с флорпланом. Все макроселлы оказались расположены у координаты 0.0 .
Объявил area, попытался сделать place_opt -spg, но получил ошибку об отсутствии spg информации в базе данных.
Во время синтеза я использовал топо и compile_ultra -spg, сохранял .ddc как обычно. Посмотрел хелп на команду сохранения в .ddc - никаких доп. ключей не нашел. Чего то не хватает

[oratie]

Не всё передается через spg:

DC
compile_ultra -spg
write -format ddc -output aaa.ddc
write_floorplan -all aaa.fp

ICC
import_designs aaa.ddc -format ddc -top aaa -cel aaa
read_floorplan aaa.fp
place_opt -spg

А ещё есть команда restore_spg_placement - это чтобы в ICC до place_opt увидеть размещение, которое сделал DC.

[Shivers]

Привет!
Сделал сохранение флорплана, получился маленький файлик, в котором есть только create_core_area с указанием размера.
А вот получить плейсмент не получилось. Команду restore_spg_placement ICC (11.09) вообще не знает, а place_opt -spg выдает надпись Design dnt have psg information.

[oratie]

DC никак не ругался на "compile_ultra -spg" ?

[Shivers]

Нет, команда прошла нормально, без ворнингов.
Попробовал блоки вручную расставить (указывал координаты в скрипте синтеза) - эти координаты потом попали в файл .fp и затем, как следствие, - в IC. Но те блоки, что не были прописаны вручную - их по прежнему нет, и команда place_opt -spg по прежнему завершается аварийно. Наверно я что то упустил, какую то мелочь.
Может, есть способ передать расстановку через базу mw? В DC есть команда write_mw_lib (или как то так - документации нет под рукой). ПО идее, эта команда должна писать разведенный дизайн во FRAM. Но это пока только идея, не проверял.

[oratie]

Попробуйте после compile_ultra (насколько я знаю, этот нижеприведенный кривой метод работал на версии 2011; а в 2012 уже появилась полноценная поддержка -spg и в DC и в ICC - я пользуюсь spg без проблем):

set_icc_dp_options -icc_executable .../icc_2011.09-SP5/bin/icc_shell
start_icc_dp -f icc_dp.tcl
exit

where the icc_dp.tcl file contains the following command:

write_def -output test.def

[Shivers]

Спасибо!
Кажется, это то что нужно. По команде place_opt -spg, долго думает и выдает много всякого, но в конце вылетает с надписью вида Abnormaly terminated. Думаю, теперь это проблема софта, а метод вполне рабочий. Буду думать, как победить )

[Shivers]

Привет!
Проблему пока не решил, но появился вопрос. Когда я в милкивей делаю конвертацию либов в фрам, в логе откопал такую строчку
Error: DATABASE unit (2000) specified in LEF/PLIB file is greater than length precision in library (1000). (MWLIBP-102)
При этом селл конвертируется успешно(т.е. он таки появляется в mw либе). У меня есть подозрения, что размеры селла с такой надписью будут в два раза меньше, т.к. в лефе цифры привязаны к сетке 2000.) Масштаб 1000 берется из техн. файла при создании mw либы. Ключей для read_lef с указанием units нет. Похоже на замкнутый круг ) Как лечить, и чем чреваты такие ошибки?