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.
Hat denn der ARM9 kein normales Speicher-Interface für SRAM-style Slaves? Das wäre viel einfacher.
Beitrag "[Suche] Interessierte(n) an Projekt (ARM/FPGA)" Ähnliche Geschichte für das normale Speicherinterface des ARMs.
> 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
Um welchen ARM9 Controller geht es denn überhaupt? Ohne das zu wissen sind alternativ Vorschläge witzlos.
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.
Es gibt FPGA Module die als standart DIMM Modul gebaut sind und in den PC gesteckt werden können. Als Coprozessor sozusagen. http://homepages.uni-paderborn.de/plessl/publications/plessl03_fpt.pdf
> 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,
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.