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
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.
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.
>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 ?
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.
> 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:
1
run
2
-opt_mode speed
3
-opt_level 2
4
-p xc3s1600efg320-4
5
-top project_top <--- Toplevel Entity
6
-ifmt MIXED
7
-ifn project.prj <--- Alle HDL Files
8
-uc project.xcf
9
-ofn project.ngc
10
-hierarchy_separator /
11
-iobuf YES
12
-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):
1
PROJECT=project
2
ngdbuild -aul ${PROJECT}.ngc &&
3
map -pr b -xe n -register_duplication -cm speed -ol high -timing ${PROJECT} &&
4
$XPATH/par -ol high -xe n -w ${PROJECT}.ncd ${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...
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.
> 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.
