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
