Hallo,
beim Lesen von Appnotes bin ich bisher nicht drauf gekommen: Kann ich
einen Xilinx Virtex (4/5/6, steht noch nicht fest) als Slave an einen
DDR1 oder DDR2 (*) Speicherbus hängen? D.h. nicht der FPGA steuert einen
SDRAM, sondern ein ARM9 sieht an seinem Speicherbus einen SDRAM und den
FPGA der sich wie ein RAM verhält. Auf diese Weise will ich einen
schnellen Datenaustausch zwischen FPGA und ARM9-CPU. In den Appnotes
bisher hab ich bisher aber nur IPs gefunden in denen der FPGA als
Meister den Speicherbus steuert.
Ist das überhaupt eine gute Idee oder gibt das im FPGA Design nur
Probleme? Der FPGA hätte die Daten die der ARM9 will vermutlich im
Blockram oder in einem schnellen QDR-SRAM gespeichert.
Ich vermute mal dass der DDR-Speicherbus es ganz und gar nicht hergibt
dass der FPGA den ARM9 für kurze Zeiträume vom DDR-Speicherbus
trennt/schlafenlegt um selber aufs RAM zuzuzgreifen. Ohne riesige
Verrenkungen, meine ich...
Gibt es fertige IP Blöcke die den FPGA als RAM-Bautein erscheinen
lassen, so dass der ARM9 per Speicherzugriff das lesen kann was er haben
will? SPI ist im zweifelsfall zu langsam...
Viele Grüße,
(*) können die FPGAs das? Oder besser LP-DDR? Soll auf jeden Fall 1,8V
Busspannung haben...
Der Sinn erschliesst sich mir nicht. FPGAs haben kaum BRAM und wenn,
dann teuer. Daher muss der FPGa einen DDR Controller nutzen und ein RAM
selber fahren. Damit bekommst Du mehr Latenz. Sinn macht sowas, wenn Du
eine alte Plattform hast, wo viel CPU Power sitzt, die jetzt mehr RAM
braucht. Dann steckst Du mir einer Zusatzhardware einen DDR Chip mit
drauf.
Sowas habe ich mal gemacht.
Soll denn der FPGA nur als RAM-bridge agieren?
Wenn nein, dann könnte man ihm adress mapped functions verpassen, ihn
also mitlauschen lassen und als COPRO agieren lassen. Das muss dann aber
schon was sehr spezielles sein.
> Der Sinn erschliesst sich mir nicht. FPGAs haben kaum BRAM und wenn,> dann teuer.
Der FPGA macht sein eigenes Ding (mit einem schnellen QDR-SRAM). Die CPU
ist eher schwachbrüstig, soll aber ab und zu recht schnell Daten
austauschen (10MByte/s, per DMA). Deswegen dachte ich daran den FPGA an
den Speicherbus zu hängen, der FPGA verhält sich wie ein SDRAM und die
CPU kann per DMA Daten aus dem FPGA schaufeln. Dafür gibts aber
scheinbar keine fertige IP, so dass unser VHDL Mensch von Null anfangen
müsste und es gibt auch keine Erfahrungberichte über die Sache... das
gibt mit zu denken...
> Hat denn der ARM9 kein normales Speicher-Interface für SRAM-style> Slaves?
Das wär natürlich viel einfacher. Hat er auch. Muß jetzt im Datenblatt
nachlesen was von den verschiedenen Interfaces ich auch gleichzeitig
benutzen kann... ist alles ziemlich umfangreich...
SPI und UART gibts auf dem ARM9 nur bis ca. 7MBit/s... sonst wär das
natürlich das einfachste...
Vielen Dank für die Tipps...
Hallo asd,
ich hab mal einen FPGA an das SRAM-Style-Interface eines PXA270
angebunden, das war gar nicht mal so schwierig. Grundsätzlich sind da 2
Varianten möglich: einmal mit festem Timing von Seiten der CPU (geht vor
allem für schnelle Sachen ganz gut und oft wird da auch Bursting
unterstützt aber der FPGA muss zwingenst in der vorgegebenen Zeit auch
die passenden Daten liefern können) oder mit einem Ready-Signal
(manchmal auch als Busy ausgeführt) wo die CPU immer wartet bis auch
wirklich die gewünschten Daten anstehen (ist bei Dingen wo das sofortige
Liefern von Daten nicht 100%-tig garantiert werden kann die einzigste
Option aber oft auch langsamer weil die CPU ja immer erst noch ein
externes Signal verarbeiten muss und oft eben auch kein Bursting).
Beides ist nicht so schwer im FPGA umzusetzen (man muss sich vor allem
möglichst exakt an die Timing-Diagramme im CPU-Datenblatt halten), Euer
"VHDL Mensch" wird sich da aber so oder so was eigenes ausdenken müssen
da die konkrete Implementierung ja auch davon abhängt wo die Daten her
kommen (also was an Logik dahinter steckt). Es sind sogar beide
Varianten parallel denkbar (mit den selben Bus-Signalen aber
unterschiedlichen Chip-Select-Signalen).
Einen Stolperstein gibt es noch bei der zweiten Variante: wenn der FPGA
leer ist wartet die CPU u.U. ewig weil kein Ready kommt und das kann in
bestimmten Situationen zum Problem werden falls der FPGA bereits beim
Anlaufen der SW benutzt werden soll (dann hängt sich die CPU immer beim
Starten fest und man kann eventuell noch nicht einmal mehr die SW
updaten), dagegen hilft es in einem Bereich mit der ersten Variante eine
Art Kennung zu liefern damit die SW zuverlässig aber ohne Deadlock
erkennen kann ob der FPGA auch wirklich programmiert ist.
Das ein FPGA als DRAM an einer CPU angeschlossen wird hab ich mal
irgendwo gelesen, war eine Art Coprozessor mit dem die CPU möglichst
schnell Daten austauschen können sollte aber diese Vorgehensweise ergibt
sehr viele Probleme. Ein eher harmloseres Problem ist das die CPU nicht
erwartet das sich die Daten im DRAM selbstständig ändern und diese
deswegen gecached werden womit Pollen auf eine bestimmte Speicherstelle
schwierig wird, das kann man natürlich abstellen indem dieser "DRAM" vom
Cache ausgeschlossen wird und indem der FPGA mehrfach eingeblendet wird
(es werden ein paar Adressleitungen ignoriert) und immer ein anderer
Alias-Bereich benutzt wird.
Ich persönlich würde von einer DRAM-Emulation per FPGA grundsätzlich
abraten, es gibt IMHO zu viele Probleme mit dem Timing und den Annahmen
die der CPU-Designer bezüglich DRAM gemacht hat aber auf einen FPGA eben
nicht zutreffen.
Grüße
Erik
Moin,
habe mir auch sowas ähnliches (SDRAM-Emulator) angeschaut, aber würde
von sowas eher abraten, es wird einfach heillos komplex und riskant, vom
Debugging mal abgesehen. Bei DDR dürfte es vom Timing her beim PAR echt
knifflig werden.
Eine mögliche simplere Alternative sind am ehesten die Kamera-Ports
diverser Chips (Blackfin, OMAP, etc). die teils auch bidirektional
funktionieren, allerdings meist nur die halbe Bandbreite der üblichen
RAM-Busse bereitstellen, und wahlfreier Zugriff ist damit auch nicht zu
machen.
Dann gäb's noch PCIe, was auch elektrisch einigermassen vernünftig zu
implementieren ist. Von Kollegen weiss ich, dass man damit etwa 190
MByte/s bei 1x auf nem Spartan 6 im Burst durchkriegt. Da fertiger Core,
ist das wohl am "billigsten"...
Grüsse,
- Strubi
du solltest gfs Deine Schaltung nochmal darstellen, denn so wie ich es
lese, sollen Daten vom FPGA ins RAM (-> DMA) und das sollte der FPGA ja
selber können, wenn Du ihn zwischen CPU und CPU-RAM hängst.
> ich hab mal einen FPGA an das SRAM-Style-Interface eines PXA270> angebunden, das war gar nicht mal so schwierig.
Ich sehe das ist der beste Weg. Ich hatte irgendwoher die Info dass es
Standard wäre den FPGA am SDRAM-Interface zu haben, und dass es
etablierten Code dafür gäbe. Das hab ich aber wohl insofern falsch
verstanden dass der FPGA dann natürlich der Master am Bus sein will, und
alles andere ist "Spezial".
Ich muß jetzt noch darauf achten wie man SDRAM, NAND-Flash, und den als
SRAM getarnten FPGA gleichzeitig an die CPU kriegt.
> du solltest gfs Deine Schaltung nochmal darstellen, denn so wie ich es> lese, sollen Daten vom FPGA ins RAM (-> DMA) und das sollte der FPGA ja> selber können, wenn Du ihn zwischen CPU und CPU-RAM hängst.
Das macht es komplizierter weil die CPU den SDRAM nicht sieht wenn nicht
der Code im FPGA schon funktioniert. Das macht das Booten und Debuggen
sehr viel schwieriger weil die beiden Systeme nicht meht unabhängig
voneinander sind.
> allerdings meist nur die halbe Bandbreite der üblichen> RAM-Busse bereitstellen,
Das wär völlig ausreichend. Nur die typischen seriellen Verbindungen
(SPI/RS232) wären ein wenig zu langsam.
> Dann gäb's noch PCIe, was auch elektrisch einigermassen vernünftig zu> implementieren ist.
Oh, das dürfte völlig oversized sein, v.a. weil ich das noch bei keinem
ARM9 Prozi in der Peripherie-Liste gesehen hab...
> Um welchen ARM9 Controller geht es denn überhaupt?
Ist noch nicht raus.. SPEAR 320von ST, ein NXP (LPC3xxx) oder auch ein
AT91SAM-irgendwas von Atmel...
Ganz andere Frage: Wie ihr merkt bin ich beim Einlesen zu dem Thema noch
am Anfang. Welche Entwicklungsumgebung ist denn empfehlenswert? Bisher
dachte ich dass der Chiphersteller sowas liefert (so wie bei AVR-Mega
oder PIC), merke aber heute dass das bei ARM9 ganz und gar nicht der
Fall ist. Was wäre denn da vom
Einarbeitungsaufwand/Dokumentation/Support/Kostenrahmen zu empfehlen?
(=Firma, muß also nicht low-budget sein, soll aber nicht horrend teuer
werden, das ist für die erfahrungsgemäß meist mäßige Supportqualität
selten gerechtfertigt)
-> Vielen Dank für eure Tipps
asd schrieb:> Ich sehe das ist der beste Weg. Ich hatte irgendwoher die Info dass es> Standard wäre den FPGA am SDRAM-Interface zu haben, und dass es> etablierten Code dafür gäbe. Das hab ich aber wohl insofern falsch> verstanden dass der FPGA dann natürlich der Master am Bus sein will, und> alles andere ist "Spezial".
Richtig, in dieser Richtungist es immer noch eine Sache, die für
Anfänger ganz und gar ungeeignet ist, aber das ist wenigstens machbar.
> Ich muß jetzt noch darauf achten wie man SDRAM, NAND-Flash, und den als> SRAM getarnten FPGA gleichzeitig an die CPU kriegt.
Das sollte nicht allzu schwer sein. Im Datenblatt oder User Guide des
ARM sollte eine Skizze sein, wie man SRAM anschließt. Und wenn der NAND
Flash klappt, klappt auch ein SRAM Interface am FPGA. Schau aber, dass
du möglichst ein synchrones Interface mit Takt-Leitung verwendest, das
machts einfacher für das FPGA Design. Wir machen sowas aktuell an einem
OMAP, da hängt der FPGA am synchronen EMIF.
asd schrieb:> Ist noch nicht raus.. SPEAR 320von ST, ein NXP (LPC3xxx) oder auch ein> AT91SAM-irgendwas von Atmel...
Beim AT91SAM.. geht es relativ einfach am EBI1 Port. (werde ich
demnächst in einem Projekt machen). Aber auf Grund der asynchronen Natur
des Interfaces wird ein höherer Datendurchsatz schwierig, 10 MB/s sollte
aber noch im Rahmen sein.
Auch ist zu beachten dass der EBI1 mit anderer Peripherie geteilt wird,
insbesondere dem NAND Flash. (Sind getrennte Chipselects, bis zu 6
stehen zur Verfügung)
Am SPEAR solltest du dir dein eigenes Interface mit dem Onchip FPGA
basteln können.
> Am SPEAR solltest du dir dein eigenes Interface mit dem Onchip FPGA> basteln können.
Oha. Das Onboard-FPGA hab ich bisher gar nicht so wirklich zur Kenntnis
genommen, bzw. war mit beim Lesen des Datenblatts nicht sicher ob das
was die mit "Reconfigurable Area" tatsächlich was selbstprogrammierbares
ist oder nur für eine Auswahl vorgegebener Konfigurationen gedacht
ist... Scheint mir aber nicht sehr verbreitet zu sein, der Spear. Hab
zumindest keine Einplatinencomputer damit gefunden, zum AT91SAM-xx
findet man viel mehr, zu den LPC-xx von NXP zumindest ein wenig was...
Viele Grüße,
