При попытке запуска Астро пишет segmentation violation. ОС Linux RedHat Enterprise, дома на Дебиане - тоже самое. Некоторые другие тузлы, например, Astro IU работают. Может кто сталкивался и подскажет, что в Линухе подкрутить надо?

А virsim от VCS падает? Если да, то вам туда, пункт 2 => http://electronix.ru/forum/index.php?showtopic=59293

Было тоже самое с Milkyway. Нашел следующее решение:
1. Запустил Дебагер:

gdb Milkyway
GNU gdb 6.1.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...(no debugging symbols found)...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run
Starting program: /disk/opt/synopsys/2008/star-rcxt_vB-2008.06-SP1/linux_star-rcxt/bin/Milkyway
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 1191)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 1191)]
0xf7f816bc in __pthread_alt_lock () from /lib/i686/libpthread.so.0
(gdb) q
The program is running. Exit anyway? (y or n) y

В результате заботы которого видно что проблема с /lib/i686/libpthread.so.0


2. Ищим libpthread.so.0
locate libpthread.so
/lib/i686/libpthread.so.0
/lib/tls/libpthread.so.0
/lib/libpthread.so.0
/usr/lib/valgrind/libpthread.so
/usr/lib/valgrind/libpthread.so.0
/usr/lib/libpthread.so
/usr/lib64/nptl/libpthread.so
/usr/lib64/libpthread.so
/lib64/tls/libpthread.so.0
/lib64/libpthread.so.0


3. Смотрим
ll /lib/i686/libpthread.so.0
lrwxrwxrwx 1 root root 18 Nov 21 2006 libpthread.so.0 -> libpthread-0.10.so

ll /lib/tls/libpthread.so.0
lrwxrwxrwx 1 root root 18 Nov 21 2006 libpthread.so.0 -> libpthread-2.3.6.so

4. Скопировать
cp /lib/tls/libpthread-2.3.6.so /lib/i686

5. Поправить Ссылку

ln -s libpthread-2.3.6.so libpthread.so.0

Все заработало
Работаю в FedoraCore 3
Успехов в починке.

Спасибо за ответы
Ошибка возникала при вызове strcmp из libc, все линки на эту либу правильные.. Проблема решилась запуском с флагом -g a l a x y.

Новый трабл образовался
Делаю милкивей библиотеку для макроблоков (памяти). При попытке определить имена для шин питания при помощи команды:
dbSetCellPortTypes "dp_memory32x2048" '(
("VDD" "Power" )
("VSS" "Ground" )
) #f
Получаю в ответ Syntax...
Самое обидное, что не могу найти описание этой команды, man dbSetCellPortTypes ничего не выдает, поиском по пдф - тоже ничего... Может не там ищу?

1. vo Astro schem poprobuite help "dbSetCellPortTypes"

2 Vot syntax
dbSetCellPortTypes "libName" "cellName" ’({("portName"
{"type"} ...} ...)) append?

3. vot example
dbSetCellPortTypes "demo" "AND4" ’(
("VDD" "Power")
("VSS" "Ground")
) #f


PS. Po moemu vi propustili libName

Udachi!

Спасибо за ответ. Похоже, проблема была в том, что я пытался вводить эту команду в ткл режиме.

Все верно. Синтаксис описан для SCHEME.
В TCL тоже будет работать, если заменить
'( ... ) на { ... }
и
#f/#t на 0/1

Пытался сделать в Астро расстановку ячеек. Стандартные ячейки он расставил, а вот макроблоки проигнорировал. В чем проблема? Их надо вручную расставлять?

Место под макроблоки выбирается пользователем, т.е. ставите их сами на этапе floorplan
Также требуется создать placement blockage поверх макросов чтобы Астро не пытался пихать туда стд. ячейки. После расстановки макроблоков можно раскидывать стандартные ячейки. Также не помешает оценить place congestion и route congestion и подкорректировать floorplan если потребуется
Как-то так

Понятно. Спасибо.


А это что за звери такие?

локальный недостаток места в некоторых местах floorplan-а, в которых прогнозируется нехватка ресурсов для размещения или трассировки.
соответственно, необходимо проанализировать эти места и изменить floorplan для устранения таких узких мест.

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

Назрел тут еще вопрос относительно выбора способа физической реализации между flatten иерархическим. То что с иерархическим способом гемороя на порядок больше - это уже понятно, плюсы в виде относительной простоты внесения небольших исправлений и большей предсказуемости на последующих итерациях тоже. Может еще какие моменты есть? Где та грань после которой стоит переходить к иерархическому подходу?

Объясните еще неразумному, плиз, как делается ИО ринг. По докам на Астро никак пока не врублюсь. В библиотеке у меня есть отдельно ио ячейки и отдельно пады (причем есть длинные и короткие для шахматного порядка). Пады надо добавлять непосредственно в HDL код? Каким образом пады и ио ячейки потом расставить на кристалле? Может это где описано?

Из SolvNet

Нажмите для просмотра прикрепленного файла

Download the file "createNplace_bondpads.pl" and change the permissions to
executable.

Edit the createNplace_bondpads.pl file HEADER section per your design
specifications.

#Header
#-------------------------------------------------------------#
$stagger_bond = 1;
$bond1_master = "PADIZ40.FRAM";
$bond2_master = "PADOZ40.FRAM";
$bond1_instance = "sbond";
$bond2_instance = "lbond";
$bond1_pad_height = 89.8;
$bond2_pad_height = 204.8;
$bond_pad_width = 40;
$signal_pad_width = 40;
$x_origin_shift = 0;
$y_origin_shift = 0;
#-------------------------------------------------------------#

Hints for setting values:

If the design is an in-line structure, you need to only supply bond1_*
variables. Bond2_* variables are not used by the script if you set stagger to 0.

x_origin_shift/y_origin_shift = if the bond pad boundary left-bottom corner is
not zero, you need to set this variables, if it coincides with (0,0) then set
to 0 and 0

You can also supply variables as command line options.


Dump the I/O placement file with using following command and options from
Apollo and Astro:
-------------------------------------------------------------------
axgDumpPlacement
setToggleField "Dump Placement" "Type" "io" 1
setFormField "Dump Placement" "Output Filename" "io_placement.dump"
formOK "Dump Placement"
-------------------------------------------------------------------

Remove the lines corresponding to the corner pads from the io_place.dmp file
and the createNplace_bondpads.pl script produces a -pfile argument. This script
creates a file called addbumppadsNplace.cmd or the file name given for the
command line option -out. You can load this file directly from the Apollo and
Astro command line. Make sure you have saved the cell before loading the
command file.

If you find misalignment in bond placement, fine tune the variables in the head
section or command line options. Re-run the script to generate the command
file. Open the previously saved CEL file and re-load the newly generated
command file.

Пады в RTL-коде не нужны, их просто расставить скриптом, по координатам. Как и сами ио ячейки собственно.

Спасибо за скрипт. Завтра опробую.
Планирую делать так:
1. В RTL добавляю ио ячейки. Общее количество выводов порядка 240, для ввода/вывода используется 180. Остальные задействую для питания коре и ио ячеек, подключив их к VDD, VCC, PVDD, PVCC etc.
2. В floorplanner создаю коре и скриптом расставляю ио ячейки с минимальным шагом каждую в соответствии с требуемой цоколевкой. Более производительного способа случайно нет? Как их, кстати, расставлять, чтобы они потом с падами совпали (как определить начальные координаты)? Core-to-border задавать равным размеру требуемым под пады?
3. Добавляю пины в коре. Пинами станут выводы ио ячеек?
4. Выгружаю пины командой axgDumpPlacement - результирующий файл подсовываю createNplace_bondpads.pl. В результате получаю скрипт создающий кольцо падов?
5. Запускаю скрипт в Астро. В результате добавятся пады и автоматически присоединятся к выходам соответствующих ио ячеек?
Так правильно?
В чем тогда смысл tdf файла?