ISE beim erstellen der .bit Zeit sparen?

[sWeeR (Gast)]

Hallo,

Ich arbeite mit ISE 12.3 an einem RocketIO GTP_DUAL tile.

Leider dauert das synthetisieren, mappen, routen einfach ewigkeiten (> 5 
min)
Wenn ich nur ein bisschnen was im Source-Code geändert habe, muss ich 
diesen ganzen Prozess wiederholen. So dauert das Programmieren einfach 
zu lange.

Kann ich das irgendwie beschleunigen? Vielleicht, die Module alle 
einzeln erstellen zu lassen, und auch so die einzelnen Cores zu 
integrieren? Hab gesucht, aber nichts gefunden zu dem Thema..

Vielen dank,
sWeeR

[D. I. (Gast)]

sWeeR schrieb:

> Leider dauert das synthetisieren, mappen, routen einfach ewigkeiten (> 5
> min)

Da habe ich jetzt mal 3 Mal herzlich gelacht :D 5 Minuten = Ewigkeit mag 
vllt in der Softwarewelt gelten, hier ist das so ziemlich die untere 
Grenze

Nein man muss immer wieder alles durchführen.

[sWeeR (Gast)]

schade, das is ja übel... danke für die schnelle antwort!

[Falk (Gast)]

ISE ist einfach total langsam. Unter ISE 9.2 hab ich mal den versuch 
gemacht und ein einfaches UND glied Synthetisiert. Selbst das hat bis 
zum bit File 30 sekunden gedauert. Grosse Teile von ISE sind leider in 
Java gekodet.

>hier ist das so ziemlich die untere Grenze
Zumindest bei Xilinx, andere Tools sind schneller, wenn auch nicht viel

[Duke Scarring (Gast)]

sWeeR schrieb:
> Leider dauert das synthetisieren, mappen, routen einfach ewigkeiten (> 5
> min)

Ich hatte auch schon mit Designs zu tun, die liefen nicht unter 5h 
durch.
Du solltest Deinen Workflow ändern.

Nicht auf der Hardware wird rumprobiert, sondern im Simulator. Und zwar 
solange bis es dort läuft. Dann kann man auf die Hardware gehen...

Duke

[lalala (Gast)]

man sollte sich auch mal vor Augen halten was hier alles passiert. Es 
ist kein Compiler, der Befehle in Maschinensprache übersetzt. Die 
komplette beschriebene Logik wird analysiert, vereinfacht, optimiert. 
Die Gatter werden dann im FPGA richtig platziert und müssen dann auch 
noch verbunden werden, und das alles so, dass das Timing passt. Ich 
vergleiche sowas immer gerne, wenn man eine Platine designed ... alleine 
das Routen kann ewig dauern, bis es passt ...

Bei diesen 5min musste ich auch herzhaft lachen - das reicht ja nicht 
mal um sich einen Kaffee zu holen :-P

[Anguel S. (anguel)]

Was ich bei der Diskussion sehr interessant finde ist, dass niemand 
sagt, was für einen Rechner er verwendet ;)

[lalala (Gast)]

tut meiner Meinung nach nicht wirklich soviel zur Sache - wenn man ein 
Design hat, dass 5min braucht, ist ein schneller halt in 4min und ein 
langsamer in 6min fertig. Bei einem Design, dass 5h braucht, ist der 
schnelle in 3h, der langsame in 8h fertig - aber die Größenordnung 
bleibt doch letztendlich diesselbe. Beim kleinen Design, kann man mal 
schnell nochmal Routen, beim großen Design, kann man das Ergebnis eh nur 
1-2 mal pro Tag ausprobieren, wenn man den Rechner auch über Nacht 
laufen läßt.

Mehrkernrechner werden eh nicht unterstützt, also kommt es nur auf die 
Taktfrequenz und Speicheranbindung an. Bei den Taktfrequenzen tut sich 
ja nicht mehr soviel.

[René D. (Firma: www.dossmatik.de) (dose)]

Mittlerweile sind in einem PC-Processor mehrer CPUs.

Ich habe auf meine CPU-Auslastung bei einem längeren Fitvorgang 
geschaut. Bei mir sind 4 CPUs vorhanden.
Eine CPU hat 100% Auslastung und die anderen drei CPUs haben 
2%Auslastung. Die 100% sind immer mal an einer anderen CPU, das hängt 
sicher auch von dem Betriebssystem wie die Prozesse verteilt werden.

In der Console sind die Meldungen an was gerade gewerkelt wird.

Optimierung A
Optimierung B
Optimierung C

Das läasst sich auch parallel auf verschiedenen CPUs organisieren. 
Leider hat ISE kein Multithreading.

Ich habe das Webpack. Es wäre interessant, wenn jemand die 
Prozessorauslastung von einer vollen Lizenz mal postet, ob dann 
Multithreading existiert.

[Christian R. (supachris)]

Nö, auch bei der System Edition gibts nix paralleles. Stelle ich mir 
auch schwer vor, da ja das Design schlecht vom Mapper partitioniert 
werden kann. Wichtig ist, dass man viel schnellen RAM hat, denn gerade 
bei den größeren FPGAs frisst map und ngdbuild massiv Speicher: 
http://www.xilinx.com/ise/products/memory.htm

[D. I. (Gast)]

Ich sah bisher noch nicht wirklich ein Problem, warum man das nicht 
multithreaden könnte, denn im Prinzip ist das ja nichts anderes wie 
heuristisches Backtracking und ein paar andere Sachen, da könnte man 
durchaus mehrere Möglichkeiten auf mehreren CPU's gleichzeitig testen.