Hallo, Ich verwende Xilinx ISE Webpack 13.3 auf Windows. In meinem Projekt habe ich mit dem IP Core Gen ein Block Memory inkl. einem Init File (.coe) erstellt. Das funktioniert auch einwandfrei. Ich hätte gern eine Bat-Datei wo ich einen Release automatisch erstellen kann d.h. der Block Memory soll mit dem neuen Inhalt der Coe-Datei erstellt werden. Das tut es aber nicht. Ich bekomme immer den Inhalt aus dem letzten IP Core Gen -> Regenerate (Under Current Project Settings) Zurzeit mache ich folgendes in der Bat-Datei: ---------------- cd <projekt ordner> call C:\Xilinx\13.3\ISE_DS\settings64.bat /. coe datei erstellen ./ cd <block memory name>\implement call implement.bat ---------------- Das implement.bat läuft durch aber der Inhalt ist nicht aktuell. Anscheinend reicht ein Aufrufen von implement.bat nicht. Hat jemand eine Idee was ich noch tun muss? Viele Grüße egon
Habs gefunden. Wenn jemand das mal versucht. Das direkte Aufrufen von implement.bat ist nicht der richtige Weg. Der Core Gen kann im Batch Mode aufgerufen werden: <xilinx pfad>\ISE_DS\settings64.bat <xilinx pfad>\ISE_DS\ISE\bin\nt64\coregen.exe -b coregen.cmd -p <coregenproject>.cgc coregen.cmd Inhalt ----------- EXECUTE <corename>.xco END ------- Das klappte bei mir ;) Viele Grüße egon
Wenn ich sowas brauche, habe ich ein C/Python-Programm, was mir eine synthesefähige VHDL-Beschreibung eines RAMs erzeugt. Da muß man dann auch im Simulator keine Umstände machen, oder beim Wechsel des FPGA-Herstellers. Selbst srec_cat kann VHDL generieren (ungetestet): http://srecord.sourceforge.net/man/man1/srec_cat.html Duke
Duke Scarring schrieb: > Wenn ich sowas brauche, habe ich ein C/Python-Programm, was mir eine > synthesefähige VHDL-Beschreibung eines RAMs erzeugt. Was wäre denn diesbezüglich der Vorteil eines solchen generischen RAMs? Was ich sehe, kann man mit den Tools doch sehr einfach ein block-Ram bauen lassen und das Init-File beifügen. So machen es die designer hier jedenfalls. Man baut eins für den Xilnx, eins für den Lattice und eines für den Altera und checkt sie ein. Wie werden eigentlich die Init-Werte bei anderen Herstellern verarbeitet, wenn der FPGA-Typ das nicht unterstützt? Und wo stecken die eigentlich und wie kommen die ins RAM? Das Block-Ram hat meines Wissens keine Option vorgeladen zu werden. Passiert das beim Beladen des FPGAs? Es muss ja irgendeine Routine geben, die aus dem Flash die Daten zieht und die internen Strukturen setzt und danach dann sich aus einem Flash die RAM-Inits holt und in die BRAMs schiebt. ???
> Wenn ich sowas brauche, habe ich ein C/Python-Programm, was mir eine synthesefähige VHDL-Beschreibung eines RAMs erzeugt. Noch bequemer finde ich es, wenn das Programm/Skript eine Datei nur mit dem Speicherinhalt erzeugt, die dann vom eigentlichen Speicher quasi "inkludiert" wird. Unter VHDL kann man das mit einem extra Package machen, in dem der Speicherinalt als Konstante definiert ist. Beim Definieren des eigentlichen Signals des Speichers (in einer andren Datei) kann man dieses dann mit einer kleinen Funktionen mit dem Inhalt aus dem Package initialisieren. Hier ein Beispiel dazu: Der eigentliche Speicher: [https://github.com/stnolting/neorv32/blob/master/rtl/core/neorv32_imem.vhd] Der dazugehöroge Speicherinhalt: [https://github.com/stnolting/neorv32/blob/master/rtl/core/neorv32_application_image.vhd] Funktioniert sowohl für RAMs als auch für ROMs und ist unabhängig von der Plattform.
> Wie werden eigentlich die Init-Werte bei anderen Herstellern verarbeitet, wenn der FPGA-Typ das nicht unterstützt? Ich würde mal vermuten, dass die Tools dann versuchen das RAM aus LUTs und FFs, welche initilisiert - und ich meine nicht über den Reset - werden können, zu bauen. > Und wo stecken die eigentlich und wie kommen die ins RAM? Das Block-Ram hat meines Wissens keine Option vorgeladen zu werden. Passiert das beim Beladen des FPGAs? Es muss ja irgendeine Routine geben, die aus dem Flash die Daten zieht und die internen Strukturen setzt und danach dann sich aus einem Flash die RAM-Inits holt und in die BRAMs schiebt. ??? Hängt halt vom FPGA ab. Block-RAM kann meistens mit dem Bitstream initialisiert werden. Bei den Lattice iCE40 Ultra Plus gibt es aber z.B. auch (sehr große) "Block RAMs" die damit eben nicht initialisiert werden können. Dann muss man sich den Speicherinhalt irgendwie von außen aus einem EEPROM oder so holen.
Mal abgesehen von der ganzen komplexen Inference-Thematik betr. BRAMS (damit laesst sich ein Buch fuellen): Xilinx hat auch ein praktisches Tool 'data2mem', mittels eines BMM-Files (Mapping-Beschrieb auf die Primitiven) tauscht sich damit ein Binary-Blob (generiert aus Hex, oder einem ELF-Executable) direkt im Bitfile aus. Damit baut man mal binnen weniger Sekunden eine neue Firmware, ohne die ganzen VHDL-Sourcen neu generieren/synthetisieren zu muessen.
Ingenieur schrieb: > Was wäre denn diesbezüglich der Vorteil eines solchen generischen RAMs? > Was ich sehe, kann man mit den Tools doch sehr einfach ein block-Ram > bauen lassen und das Init-File beifügen. Meist ist dafür rumgeklicke nötig. Wer das mag, ok. Ich mag es, wenn ich alle Tools, die ich irgendwie häufig brauche, verskripten kann. > So machen es die designer hier > jedenfalls. Man baut eins für den Xilnx, eins für den Lattice und eines > für den Altera und checkt sie ein. Ich erzeuge ein generisches VHDL-File und verwende das in Modelsim, GHDL, Xilinx/ISE, Altera/Qaurtus und Lattice/LSE. Eingecheckt wird der C-Quelltext, nicht das generierte File. Jeder wie er mag. > Wie werden eigentlich die Init-Werte bei anderen Herstellern > verarbeitet, wenn der FPGA-Typ das nicht unterstützt? Welche FPGA-Typen sind das? Ich kenne nur die Ultra-RAM bei Xilinx. Lattice ice40 wurde noch erwähnt, aber bei den MachXO2 mit EBRs funktioniert es. Stephan N. schrieb: > Noch bequemer finde ich es, wenn das Programm/Skript eine Datei nur > mit dem Speicherinhalt erzeugt, die dann vom eigentlichen Speicher quasi > "inkludiert" wird. Irgendwo auf meiner Platte geistert eine VHDL-Funktion rum, die Intel-Hex-Dateien direkt einlesen kann. Das funktioniert(e) leider nicht mit allen Synthesetools, aber bei Xilinx/ISE ging es. Martin S. schrieb: > Damit baut man mal binnen weniger Sekunden eine neue Firmware, ohne die > ganzen VHDL-Sourcen neu generieren/synthetisieren zu muessen. Yupp, das hätte ich für Altera und Lattice auch gern. (Wobei bei Lattice die Synthesezeiten noch erträglich sind, weil ich da eher kleinere FPGAs nehme.) Duke
Duke Scarring schrieb: > Yupp, das hätte ich für Altera und Lattice auch gern. Fuer ECP5 geht das auch, aber momentan noch experimentell/nichttrivial und nur via nextpnr-Toolchain. In der ISPlever-Toolchain gab's, wenn ich mich recht entsinne, ein entsprechendes Tool auch fuer andere Architekturen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.