Ich versuche zurzeit, den Umgang mit FPGAs zu erlernen. Ich benutze einen Chip der Lattice-MachXO2-Familie. Nun habe ich etwas Logik und einen CPU-Kern implementiert. Um auf diesem Kern ein Programm laufen zu lassen, führe ich folgende Schritte aus: - (Cross-)Assemblieren des Programms auf dem PC - Umwandlung der Binärdatei in eine .mem-Datei (addressed hex) - Aufruf von IPexpress in Lattice Diamond um das ROM mit dem neuen .mem-File erneut zu generieren. - Den gesamten Prozess bis zur Generierung des .jed Files wiederholen, was 5 bis 45 Minuten dauern kann. In IPexpress habe ich die Option "allow update of inititialization file stored in UFM" gewählt. Nun möchte ich aus neuen Initialisierungsdaten in einem neuen .mem-file ein neues .jed-file erzeugen, in dem entweder die existierende Logik-Konfiguration mit neuen Initialisierungsdaten kombiniert wird oder das nur die Initialisierungsdaten enthält und mit dem dann nur der UFM-Bereich programmiert würde. Ich kann einzelne UFM-Seiten schreiben.. Aber ich kann nicht ein .mem File in ein .jed File umkodieren. Ich konnte uach noch nicht heraus finden welche einsen uund Nullen im .jed File welchem Byte im mem File entsprechen. Ich kann auch kein Tool dazu finden. Jeder Hinweis ist willkommen!
Moin, ich weiss nur, dass Xilinx sowas elegant über die BMM-Files löst. Das Problem ist nämlich, dass du a priori nicht weisst, wo die RAM-Bereiche hingemappt werden, das sucht sich die Synthese selber aus. Der Aufwand, den Bitstream zu hacken, ist erheblich, der IMHO praktikabelste Ansatz ist der, die relevanten Sektoren im Flash zur Laufzeit per JTAG über In Circuit Emulation zu programmieren. Das ist aber auch schon ne Ecke Arbeit, die sich allerdings amortisiert: Jedesmal die Synthese anschmeissen zu müssen, um das Programm neu zu generieren, macht keinen Spass. Würde mich aber freuen, wenn es inzwischen eine Lösung a la BMM gäbe. Grüsse, - Strubi
Erst einaml Danke für deine Antwort! > Problem ist nämlich, dass du a priori nicht weisst, wo die RAM-Bereiche > hingemappt werden, das sucht sich die Synthese selber aus. Ich glaube, dass sollte unter anderem "allow update of inititialization file stored in UFM" verhindern (und dass die Daten komprimiert werden). Im Jed-file gibt es zwei Sektionen: Die erste beginnt bei 0 L0000000 111111111.... Nach vielen Zeilen folgt dann irgendwann die zweite: NOTE EBR_INIT DATA* L714624 111111111111010... Bei einigen Designs reicht es, nur die erste Sektion in den Chip zu laden und die Logik ist komplett da, nur die ROM-Inhalte fehlen halt. Mein Problem ist halt, welche Einsen und Nullen welches Byte repräsentieren und nach erstem Anschein wird ein Byte durch neun Einsen und Nullen im jed-file wiedergegeben... Deshalb kann ich auch nicht: >die relevanten Sektoren im Flash zur Laufzeit per JTAG über In >Circuit Emulation zu programmieren. weil es wiederum zunächst dieselbe Umkodierung erfordern würde. Oder ich verstehe da etwas nicht richtig? Ich könnte nur: - ein Monitor-Program den Speicher von meinem Core aus beschreiben lassen (wenn ich als Speicher RAM statt ROM nähme) - den I2C- oder SPI-Slave aus dem EFB (embedded function block) dazu verwenden, den Spaicher zu beschreiben (wenn ich als Speicher Dal-Port-RAM statt ROM nähme). Aber das bläht das Design auf. >Der Aufwand, >den Bitstream zu hacken, ist erheblich Man könnte ROM-Inhalte erzeugen, die genau ein 1-Bit enthalten und gucken wo es bleibt, aber meine Hoffnung ist, dass es einfach ein Tool für die Umkodierung gibt.
:
Bearbeitet durch User
Thomas H. schrieb: >>die relevanten Sektoren im Flash zur Laufzeit per JTAG über In >>Circuit Emulation zu programmieren. > weil es wiederum zunächst dieselbe Umkodierung erfordern würde. > Oder ich verstehe da etwas nicht richtig? Doch, du hast recht, da hätte ich noch bisschen was zu erwähnen sollen: Das Boot-ROM ist fix, und das eigentliche Programm liegt in einem separaten SPI-Flash, u.a. auch weil es nicht komplett ins ROM passt. Mein on-chip-ROM ist aber eigentlich ein RAM, und lässt sich nach dem Booten per JTAG laden - das ist aber nur während der Entwicklung was. Das einzige an einer fixen Adresse im UFM-Flash sind platinenspezifische Daten, die sind aber nicht auf das MachXO2 SRAM gemappt. Wie gesagt, so ein Tool a la Xilinx' data2mem fehlt mir auch noch bei Lattice. Aber vielleicht habe ich einfach nicht gut genug gesucht. Auf jeden Fall wäre so eine In-System-Programmierungsmöglichkeit für das interne, auf die SRAM-Zellen gemappte Flash, sehr interessant, um auch den Bootloader updaten zu können. - Strubi
Thomas H. schrieb: > aber meine Hoffnung ist, dass es einfach ein Tool > für die Umkodierung gibt. Ist im Diamond enthalten: ECO Editor -> Memory Initialization.
Thomas H. schrieb: > Der ECO-Editor ist bei mir ausgegraut. Ist das Projekt im fertig gebauten Zustand? Ohne dass ein feriges NCD File vorliegt geht er nicht.
Nein. Nach meiner Ernnerung war es das, aber ich werde wohl beim herumklicken und probieren iregendwas verändert haben. Der Prozess läuft gerade... Kennt jemand das Deployment Tool? Es geht irgendwie in die Richtung, von dem was ich suche, es kann Dinge wie: Altes .jed file rein, neuer usercode dazu, Ergebnis in neues .jed file schreiben. Aber ob es die Iniatilisierungsdaten ändern kann, weiß ich noch nicht.
Das Deployment Tool kann es nicht. Die Information wie das Memfile konvertiert werden muss, und in welches EBR es gehört ist im .jed File nicht mehr vorhanden.
Ich habe es jetzt mit dem ECO-Editor probiert. Es funktioniert! Herzlichen Dank!
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.