Hi, ich bin dabei ein neues Projekt in der ISE 10.1 zu erstellen und habe bereits eine eigene Library erstellt und hinzugefügt. Soweit kein Problem. Jetzt möchte ich IP-Cores von der EDK im ISE Projekt benutzen, wie z.B. der "mii_to_rmii_v1_00_b". Da ich diesen für meine Anwendung verändern möchte, habe ich die Quelldateien nun erstmal händisch in die von mir erzeugte gleichbenannte Library "mii_to_rmii_v1_00_b" kopiert. (von "10.1\EDK\hw\XilinxProcessorIPLib\pcores\mii_to_rmii_v1_00_b\hdl\vhdl" nach "ISEProjekt\mii_to_rmii_v1_00_b") Die darin enthaltenen Dateien benötigen nun die Library "proc_common_v1_00_b". Natürlich könnte ich in meinem ISE-Projekt nun wieder eine neue gleichbenannte Library "proc_common_v1_00_b" erzeugen und die benötigte(n) Datei(en) hineinkopieren/sourcen. Dies finde ich jedoch sehr mühselig, da sonst der Fehler "Library proc_common_v1_00_b cannot be found" erscheint. Gibt es eine möglichkeit der ISE beizubringen, dass diese im EDK-Verzeichnis selbst nach den vhdl-files sucht und als Library einbindet? Vielen Dank im voraus, Matthias
In dem zum xst gehörenden .prj-File stehen alle Dateien drin, die er für die Synthese braucht. Da können natürlich auch vollständige Pfade auftauchen. Was aber die GUI dann damit anstellt, entzieht sich meiner Kenntnis, habe sie schon ca. 10 Jahre nicht mehr gestartet.
Ok, kurze Nachfrage an den Gast: Ich weiß schon, dass die Xilinx Tools sehr kommandozeilenfähig sind. Aber wie arbeiten Sie denn mit der ISE ohne die GUI? Ich würde z.B. gerne mit XEMACs arbeiten, aber da CRTL-C und CRTL-V nicht wie normal funktionieren, ist das eher ein K.O. Kriterium für mich. (Zumindest vorerst). Grüße Matthias
> Aber wie arbeiten Sie denn mit der ISE ohne die GUI? Angenehmer ;) Sicher nutze ich ab und zu grafische Bestandteile (fpga_editor, timing_analyzer oder impact zum CPLD-Flashen), aber für den Hauptjob (Projekt "erstellen", Synthese, Routing, Bitstream) gibts im Endeffekt nur ein Skript. Das muss noch nicht mal ein Makefile sein, sowas lohnt IMO sich nur, wenn man auch noch was mit EDK macht und/oder grössere Cores nicht immer neu synthetisiert werden sollen. Ansonsten ist ohnehin immer der ganze Durchlauf notwendig, evtl. mal von Änderungen an den Pins abgesehen. Die Kommandozeilenoptionen haben sich netterweise in den letzten ~15 Jahren kaum geändert, von den ISE-GUI-Projektfiles kann man das ja nicht gerade behaupten... Das einzige, was Anpassungen erfordert, sind die Optionen für die FPGA-Familien, die vorhanden Möglichkeiten können aber von map&par ausgegeben werden. Effektiv braucht es bis zum Bitstream neben dem Skript vier weitere Files: project.prj (Liste der VHDL/Verilog-Files für xst) project.scr (Synthese-Skript/Optionen für xst, im wesentlichen "run" mit top-Level-Angabe und Chiptyp) project.xcf (Constraints für xst) project.ucf (Pins/Timing-Constraints fürs Mappen/Routing) Dann reichen folgende Kommandos für Synthese bis zum Bitstream (zB. als Shellscript), hier beispielhaft für Spartan3E: xst -ifn project.scr ngdbuild -aul project.ngc map -pr b -xe n -cm speed -ol high project par -ol high -xe n -w project.ncd projectr.ncd project.pcf bitgen -d -g StartupClk:CClk -w -b projectr project project.pcf Im (bash)Shellscript hängt man die Befehler sinnvollerweise alle mit && hintereinander, dann bricht ein Fehler wie im makefile gleich alles ab. Ich lasse mir meist auch gleich noch die Top20 des Timings in ein File schreiben, kann man dann durchstöbern und schauen, welche kritischen Pfade wohl einen als nächstes plagen werden: trce -v 20 projectr.ncd project.pcf (produziert project.twr) Diese Skripteritis nehme ich nahezu unverändert seit ca. 1995 her, damals gabs statt xst die fpga_shell von Synopsys. Die Ausnahme ist das erwähnte EDK-Projekt, wo die vielen Zwischenergebnisse auch noch in Unterordnern landen, damit es etwas übersichtlicher bleibt. Bei CPLDs läufts leicht anders, da gibts nach dem ngdbuild nur noch cpldfit und hprep6. > Ich würde z.B. gerne mit XEMACs arbeiten, aber > da CRTL-C und CRTL-V nicht wie normal funktionieren, > ist das eher ein K.O. Kriterium für mich. (Zumindest vorerst). Für mich ist Ctrl-C und Ctrl-V nicht normal ;) Daher bin ich sehr froh, dass der cygwin-xemacs da keine Windows-Anbiederung macht...
Danke für die ausführliche Beschreibung :-) Werde mir doch pö a pö XEMACs angewöhnen, sofern ich in Zukunft mehr mit VHDL zu tun haben sollte. Viele Grüße Matthias
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.