Softcore - Binary nicht als Blockram sondern in Flash

> gibt es bereits einen fertigen Softcore, dessen Binary nicht als
> Blockram eingebunden ist, sondern in einem Flash; welches auch als
> Bootrom für das FPGA dient?
> Idealerweise sollte der Softcore, obwohl er aus dem Flash läuft auch auf
> selbiges zugreifen können.

Das ist weniger eine Anforderung an den Softcore selbst als an die 
physikalische Verschaltung zwischen Flash und FPGA. Prinzipiell ist das 
aber möglich - ich benutze zur Zeit ein Entwicklungsboard wo Flash und 
FPGA "passend" verdrahtet sind und mache genau das, was du beschrieben 
hast. Das Board benutzt zwar einen externen CPLD für den 
Programmiervorgang, allerdings aus anderen Gründen - es sollte genauso 
funzen, wenn der FPGA sich selbst programmiert.

Der CPU-Softcore selbst kann normalerweise unverändert übernommen 
werden. "Normalerweise" soll hier heißen, der Softcore benutzt 
irgendeine Art von generischem Bussystem (z.B. OPB oder Wishbone), aber 
das machen praktisch alle Softcores. Du brauchst nur einen Controller, 
um den Flash anzusprechen, aber der ist 1. meist schon irgendwo zu haben 
und 2. notfalls auch einfach zu bauen (solange du nur lesen und nicht 
schreiben willst).

> Falls nein, welcher Softcore lässt sich denn dahingehend leicht
> abändern?

Wie gesagt benutzen praktisch alle Softcores ein generisches Bussystem 
um mit der Außenwelt zu kommunizieren. Du must also i.A. keinen Softcore 
ändern, sondern nur ein "Gerät" an den Bus anhängen. Ausnahme sind nur 
die "kleinsten" Softcores, die den Programmspeicher integriert haben 
(z.B. Picoblaze ohne besondere Tricksereien).

Das Problem ist nicht das Laden des FPGAs über das Flash; das 
funktioniert. Eher ein Verständnis-Problem meinerseits:
Der Adresscounter/Programcounter des Softcores wird ja die Adresse des 
Flash ständig inkrementieren, um step-by-step das binary auszulesen. 
Wenn nun das Programm im Softcore auf den Flash zugreift, verstellt 
dieser ja die Adresse, die durch den PC vorgegeben wurde, sodass das 
Binary nicht richtig ausgelesen wird, oder?

Da ich nun Hobby-mäßig FPGA programmiere, habe ich bisher nur den 
Picoblaze und den AX8 am Laufen gehabt. Welche gehören denn zu den 
"großen", die ich auch kostenlos / auf OpenSource-Basis bekomme?

> Wenn nun das Programm im Softcore auf den Flash zugreift, verstellt
> dieser ja die Adresse, die durch den PC vorgegeben wurde, sodass das
> Binary nicht richtig ausgelesen wird, oder?

Der FPGA konfiguriert sich beim hochfahren einmal vollständig. In dem 
Moment wo der Softcore überhaupt anfängt zu arbeiten, ist der FPGA 
fertig konfiguriert und braucht den Flash nicht mehr, d.h. ab da kann 
der Softcore so tun, als hätte der Flash überhaupt nix mit der 
Konfiguration zu tun. Einzig die reine elektrische Verschaltung ist 
etwas komplizierter, z.B. muss der FPGA alle Leitungen, die mit der 
Konfiguration zu tun haben, hochohmig schalten usw.

Ansonsten brauchst du wie gesagt einen Flash-lese-controller, der den 
on-chip Bus (an dem der Softcore hängt) mit dem Flash verbindet. Dieser 
Controller ist so geschrieben, als hätte der Flash nur mit dem Programm, 
nicht mit der Konfiguration zu tun (s.o.). Dieser Controller ist in 
meinem Beispiel 100 Zeilen Verilog, also mehr oder weniger "trivial", 
muss aber natürlich passend zum on-chip Bus und zum Flash-Chip 
geschrieben sein.

> Da ich nun Hobby-mäßig FPGA programmiere, habe ich bisher nur den
> Picoblaze und den AX8 am Laufen gehabt. Welche gehören denn zu den
> "großen", die ich auch kostenlos / auf OpenSource-Basis bekomme?

Das kann ich dir leider nicht sagen, da sich alle meine Experimente um 
einen "selbstgebauten" drehen. Den könntest du zwar auch gerne 
verwenden, aber das ist alles noch experimentell.

@Rupplyn:
> Da ich nun Hobby-mäßig FPGA programmiere, habe ich bisher nur den
> Picoblaze und den AX8 am Laufen gehabt. Welche gehören denn zu den
> "großen", die ich auch kostenlos / auf OpenSource-Basis bekomme?

siehe FPGA Soft Core

Duke

> Ich bezweifle dass das Ausfuehren direkt aus dem Boot-Flash Sinn macht;
> bei kleinen Programmen wird die Zugriffslogik mehr Ressourcen benoetigen
> als wenn man das Programm direkt in LUTs oder in einem Block-RAM
> speichern wuerde,

Das kann ich nicht bestätigen. Die Lese-Zugriffslogik ist ähnlich wie 
bei einem Block-RAM (Adresse rein, Daten raus); "kompliziert" ist einzig 
das lesen mehrerer Flash-Worte und Zusammensetzen zu einer Instruktion, 
falls eine Instruktion größer ist als ein Flash-Wort, da man beim Flash 
ja nicht die Datenportgröße so wie beim BRAM ändern kann. Da ist aber 
wirklich nicht viel Logik dahinter.

Schreiben ist natürlich ein anderes Thema, aber das ist beim 
Programmspeicher ja normalerweise nicht nötig.

> und wenn der Prozessor so viel machen soll dass der
> Platz ein Faktor ist wird das Flash die Ausfuerung zu sehr ausbremsen.

Das mit dem Ausbremsen stimmt, Flash-Chips sind nicht die schnellsten.

@Andreas:
>... und wenn der Prozessor so viel machen soll dass der
>Platz ein Faktor ist wird das Flash die Ausfuerung zu sehr ausbremsen.

Dafür gibt es Cache (z.B. beim lm32).

Duke