Xilinx ISE - immer wieder cleanup nötig

[Frank (Gast)]

Manchmal klappt die Synthese nicht, manchmal auch die Simulation nicht. 
Nach dem start der Gewünschten Funktion bleibt ISE 9.2 einfach irgendwo 
stehen oder startet gar nicht erst das gewünschte. eine Fehlermeldung 
oder sonstwie Verdächtige ausgabe erfolgt nicht. Mach ich dann einmal 
cleanup Projekt, dann klappt wieder alles, oftmals jedoch nur ein oder 2 
mal, und dann muss ich wieder cleanup machen. Hab schon ISE neu 
installiert, und einen anderen Rechner probiert, aber es hat sich nix 
gebessert.
teilweise mach ich 20 mal cleanup am tag, und das ist ganz schön nervig, 
und es kostet auch viel zeit, da die synthese ja dann wieder ganz vorne 
anfängt. Ich möchte jedoch auch nicht updaten, auf die aktuelle ISE, 
weil ich dann befürchte mir andere Probleme einzuhandeln. weiss jemand 
rat ?

Frank

[Martin K. (mkohler)]

Frank schrieb:
> Manchmal klappt die Synthese nicht, manchmal auch die Simulation nicht.
...
> teilweise mach ich 20 mal cleanup am tag, und das ist ganz schön nervig,
Nötige Cleanups kann ich bestätigen, jedoch nicht bis zu 20mal am Tag.

[Duke Scarring (Gast)]

@Frank:
>  Hab schon ISE neu installiert,
Auch mit allen verfügbaren ServicePacks?

Duke

[Georg A. (Gast)]

Nur ein kleiner Hinweis für die ISE-GUI-Geschädigten: Mit ca. 1 Stunden 
Arbeit/Analyse der Kommandozeilenparameter kann man den gesamten Vorgang 
von Synthese über Routing bis Bitstream und auch Simulation in ein 
Makefile oder Batchscript packen. Dann ist Ruhe und das Zeug läuft 
einfach so durch.

Für einfachere Projekte ohne EDK und Cores etc. reicht auch wirklich 
schon ein lineares Batchscript ohne Abhängigkeiten. Bis auf Änderungen 
am UCF muss man die Kette sowieso immer ganz durchlaufen, da bringt ein 
Makefile nicht viel.

Es gibt noch einen weiteren Vorteil: Das Skript/Makefile kann man nahezu 
ewig recyclen. Die ISE-Projektfileversionen kommen und gehen, xst, map, 
par und bitgen haben seit Urzeiten dieselben Parameter. Für eine neue 
Architektur kann man auch mal die Parameterhilfe bemühen, aber ansonsten 
ändert sich da nichts.

Ich habe mein erstes, immer wieder nur leicht angepasstes Script meiner 
DA für die XC4000er von '95 erst vor 3 Jahren gegen ein Makefile 
getauscht :-) Während der Zeit gab es gefühlte 50 Versionen der 
GUI-Krankheit (XACT, M1, ISE)... Und der Wechsel war auch nur wegen dem 
EDK-Einsatz nötig, um eine überflüssige Neusynthese des Microblaze-Cores 
zu vermeiden.

[Michael Sauron (Gast)]

>Auch mit allen verfügbaren ServicePacks?

ja

@georg

wie sieht so etwas dann im detail aus ? hast du ein beispiel Script ?
wie rufe ich das script auf ? Kommandozeile ?

[simon (Gast)]

ich benutze dieses Python-skript um mir ein makefile generieren zu 
lassen:

http://www.dilloneng.com/documents/downloads/gen_ise_sh

wenn man mit der edk arbeitet, ist das nicht nötig, die edk erstellt 
automatisch ein makefile im projektordner mit allen targets bis hin zum 
download auf das board.

Für die Simulation mit Modelsim gibt es den Emacs vhdl-mode, der auch 
makefiles erstellen kann.

[Georg A. (Gast)]

> hast du ein beispiel Script ?

Ja, aber "nur" als bash-Script. Also entweder unter cygwin laufen lassen 
oder man muss den Variablen-Kram nach DOS portieren (war AFAIR was mit 
%).

Dazu muss man noch folgendes wissen: Die ISE-GUI ruft auch nur die 
Einzelprogramme auf. D.h. die meisten Infos existieren dazu schon als 
Datei, nur wenig muss als Optionen dazu. Also zB. für xst das 
Project-File (mit der Liste der vhdl-Files drin) und das .scr (mit den 
Laufzeit-Optionen) oder fürs Routing das .ucf. Die muss man nur finden 
;)

Die Synthese geht dann so

xst -ifn project.scr

So ein project.scr sieht zB. so aus:

run
-opt_mode speed
-opt_level 2
-p xc3s1600efg320-4
-top project_top                 <--- Toplevel Entity
-ifmt MIXED
-ifn project.prj                 <--- Alle HDL Files
-uc project.xcf
-ofn project.ngc
-hierarchy_separator /
-iobuf YES
-max_fanout 100

In der xst-Doku stehen noch die diversen anderen Optionen, die so 
möglich sind.

Ergebnis der Synthese ist ein .ngc-File.

Das Routing geht so (für ein Spartan2-Projekt):

PROJECT=project
ngdbuild -aul ${PROJECT}.ngc &&
map  -pr b  -xe n  -register_duplication -cm speed  -ol high -timing  ${PROJECT} &&
$XPATH/par  -ol high -xe n -w ${PROJECT}.ncd ${PROJECT}r.ncd ${PROJECT}.pcf &&
$XPATH/bitgen -d -g StartupClk:CClk -w -b  ${PROJECT}r ${PROJECT} ${PROJECT}.pcf &&
trce  -v 20 ${PROJECT}r.ncd  ${PROJECT}.pcf

Das && sorgt in der bash dafür, dass der ganze Kram gleich abbricht, 
wenn ein Schritt einen Fehler produziert hat.

Ein kleiner Trick ist, dass Ergebnis des Routings mit ...r.ncd zu 
bezeichnen (zB. projectr.ncd) , per Default würde par wieder ein 
identisches benamtes ncd ausspucken.

Bei map/par kann man auch mit weniger Optionen auskommen, dann gibts 
Default-Settings. Mit "-t <Nummer>" bei map und par kann man den 
Zufallsgenerator setzen. Wenn ein Routing "nur knapp" nicht geht, kann 
das helfen.

Je nach Bitstream-Upload-Methode muss man evtl. bei den bitgen-Optionen 
noch was anpassen.

Das trce am Ende produziert noch eine Liste der 20 langsamsten Pfade. 
Ist ganz praktisch für die schnelle Analyse, wie knapp das Timing so ist 
und was dafür verantwortlich ist. Man kann sich natürlich auch mühsam 
durch den Timinganalyzer klicken :)

Du kannst die Schritte ja mal einzeln von Hand ausprobieren...

[Frank (Gast)]

Wenn die ISE die einzelnel tools auch nur per kommandozeile aufruft, 
warum geht das dann so oft schief ? Sich den ganzen workflow per script 
erzeugen zu lassen, mag zwar gut funktionieren, ist aber in  meinen 
augen nur ein würg around. Die Frage ist doch eher, wieso klappt 
funktion x nach dem Cleanup plötzlich wieder ? Ich habe den Eindruck, 
das die ISE nicht mehr weiss, welche Dateien aktuell sind, und welche 
neu erzeugt werden müssen. Meines erachtens macht das Cleanup ja nix 
anderes, wie alle zwischenschritte wie Netzlisten usw. zu verwerfen.

[Georg A. (Gast)]

> warum geht das dann so oft schief ?

Pfuschprogrammierer? Bloatware? Verkorkst by Default? Meine Studis 
machen auch schon seit Jahren mit der GUI rum (so seit ISE 7.x), das 
einzig gemeinsame ist, dass die GUI seit jeher Müll ist. Die meisten tun 
sich das so ein paar Wochen an und machen sich dann ein kleines Skript.

> ist aber in  meinen augen nur ein würg around.

Wenn du auf Klickibunti stehst :) Ich brauchs nicht. Ich habe meine 
Quelltexte, dann gibts Synthese und Routing mit einem Skript (typ. 
Cursor-Up in der History + Enter) und ein .bit-File kommt raus. Dazu 
brauche ich keine grösseren Klickorgien und animierte "ich tu gerade 
hier was"-Logos im Fenster. Die GUI ist für den Anfang ganz nett, um den 
generellen Workflow zu erfahren,, aber dann wird sie IMO zum Ballast.

"wie alle zwischenschritte wie Netzlisten usw. zu verwerfen."

Was es an sich aber nicht braucht. Im Gegensatz zu C-Programm muss man 
nach Quellcodeänderungen ohnehin alles neu machen (inkrementelle 
Synthese  mal aussen vor, bringt wenig Speedup und oft Ärger). 
UCF-Änderungen sind der einzige Punkt, wo man sich die Synthese bei 
Pin-Änderungen immer und bei Timing-Constraints oft sparen kann. Für 
alles andere ist eine Abhängigkeitsprüfung überflüssig, deswegen reicht 
eben ein "dummes" Skript.