Lattice Mico32 : C-Code von Flash abspielen

Flo P. Gast #1641370
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Klaus F. #1641518
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Flo P. Gast #1648866
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Schrotty Gast #1650010
Lesenswert?
• ▲
▼ 
>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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Flo P. Gast #1650100
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Klaus F. #1650123
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Schrotty Gast #1650283
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Arndt B. (Firma: Helion GmbH) #1663094
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren