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.
@Frank:
> Hab schon ISE neu installiert,
Auch mit allen verfügbaren ServicePacks?
Duke
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 && |
5 | $XPATH/bitgen -d -g StartupClk:CClk -w -b ${PROJECT}r ${PROJECT} ${PROJECT}.pcf && |
6 | 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...
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.