Hallo, Ich habe einen Lattice ECP2-50 mit integrierten Mikroprozessor Mico32. Das verwendete Demoboard ist das Hpe mini (ECP2-50) Da der C-Code sehr groß ist und dafür die EBR's in Zukunft nicht ausreichen werden (kleinerer ECP2), muss der Code von einem externen SPI Flash aus betrieben werden. (Einige ebrs für die read/write Variablen stehen zu Verfügung.) Ich verwende das SPI Flash welches auch die Bitstream Daten des FPGAs enthält. Es gibt zwar eine Anleitung für XIP (Execute in Place) jedoch funktioniert es nicht bzw ist es unzureichend erklärt. Falls jemand bereits Erfahrung auf dem Gebiet hat bitte ich um Hilfe. Besten Dank Flo
Ohne jetzt den Board oder die Baustein zu kennen, aber ohne externes RAM wird das nicht gehen. Du kannst zwar den Code möglicherweise im Flash unterbekommen, aber die Ausführung direkt vom SPI Flash erscheint mir unsinnig, dazu ist das SPI Interface nicht gedacht und viel langsam. Wenn Du RAM im System hast, dann kannst Du den Code beim Starten aus dem Flash in das RAM umkopieren, und der Microprozessor führt das Programm von dort aus.
Hallo Klaus, leider bringt mir die Variante nichts wo der C-code aus dem Flash ins system ram kopiere, da ich dann erst wieder die vielen EBR speicherblöcke des FPGA bräuchte. Laut Lattice gibt es eine Möglichkeit den C-Code "extern" abzulaufen und nur die Variablen in EBRs zu speichern. Leider schlugen meine Versuche bis lang fehl. Mfg
>Es gibt zwar eine Anleitung für XIP (Execute in Place) jedoch >funktioniert es nicht bzw ist es unzureichend erklärt. Lattice bezieht sich hier ganz offensichtlich auf einen nichtflüchtigen Speicher am FPGA. Aber es steht kein Wort über SPI-Flash geschrieben. ich bin mir 100%ig sicher, dass die Ausführung in einem parallelen Flash gemeint ist. Und sowas geht natürlich problemlos und ist nur ein bisschen langsamer, als über´s RAM.
Hallo, Es wird erwähnt, dass der Code in ein SPI PROM geladen werden kann (letzte seite im PDF). Das sich dieser nichtflüchtige Speicher im FPGA befinden muss steht meines Erachtens nach nicht im PDF. Das das C Programm dadurch langsamer rennt als von einem parallelen Flash ist mir klar. Mfg
Meiner Meinung wird es die Möglichkeit geben, das Programm entweder aus einem externen RAM oder aus einem externen, PARALLELEM Flash auszuführen. Führt man das Programm aus einem externen RAM aus, dann muß das Programm dort vorher natürlich reingeladen werden. Dies erledigt ein Bootloader, der das Programm vor der Ausführung aus einem Flash ins RAM kopiert. In diesem Fall kann das Flash auch ein SPI Flash sein, da die Ladezeit keine so große Rolle spielt, und das Flash sequentiell ausgelesen und ins RAM kopiert wird. Bei einer Ausführung aus externem Flash, muss das Flash meiner Meinung nach zwingend ein paralleles Flash sein. Bei der Programmausführung müssen zufällig verteilte Adressen aus dem Flash gelesen werden, nur mit einem parallelel angeschlossenem Flash erreicht man Zugriffzeiten um die 50-100ns. Eine serielle Adressierung des Flashs wäre dabei viel langsamer und die Ausführung des Programms viel zu stark gebremst. Der Zugriff auf das Flash über SPI ist einfach nicht dafür gedacht. Aber nochmals wiederholt, das sind allgemeine Überlegungen, ich kenne weder das Lattice Board, noch den Prozessor.
Ich glaube auch nicht, dass das funktioniert. Selbst, wenn es so in der APP-Note steht. In denen steht manchmal viel Mist drin. In der AppNote zu deinem Thema steht z.B.: "code run from the non-volatile memory is likely to be slower than code run from a non-volatile memory" Aha! Code aus einem nichtflüchtigen Speicher läuft also langsamer als Code aus einem nichtflüchtigen Speicher. Das hat jetzt nicht direkt was mit deinem Problem zu tun, sondern soll vielmehr zeigen, dass in solchen AppNotes auch viel Mist drin steht. Daher vermute ich mal, dass das "SPI" auch irgendwie in die AppNote gerutscht ist, ohne, dass es da hingehört. Aber ich lasse mich gern eines besseren belehren.
Die Appnote hat da schon recht. Das Micosystem ist ein Wishbonesystem. Jede der Wishbonekomponenten, die Speicher enthalten (und seien es SPI Flashes), werden über den Wishbone ausgelesen (sowohl Instructions wie auch Daten). Im Falle eines SPI Flashes kann es daher sehr lange dauern, bis das angeforderte Datum aus dem Flash am Bus anstehen, aber es funktioniert. Damit solche XIP Dinge funktionieren, muss das Linkerskript aber auch die richtigen Speicherbereiche adressieren. Es gibt bei den Projekteinstellungen die Möglichkeit die Speicherbereiche für den Code, für ROM-Daten und für die RAM-Daten anzugeben. Code und ROM-Daten müssten dann auf das Flash verweisen, die RAM-Daten auf die EBRs und schon funktioniert es (wichtig: immer in Eclipse öfter mal "clean" vor einem "build" benutzen). Es funktioniert auch die Variante mit dem Bootloader. Angeblich sogar erschreckend einfach, habe ich aber noch nicht ausprobiert. Viele Grüße Arndt
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.