При попытке запуска Астро пишет 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 код? Каким образом пады и ио ячейки потом расставить на кристалле? Может это где описано?