Hallo liebe Spezialisten, Ich seh immer wieder das Problem wenn man eine Anwendung mit einem FPGA hat und mehr Speicher braucht (ab 1MB ) wird SRAM einfach zu teuer. Ich glaub heutzutage ist auch nicht mehr Stand der Technik. Jetzt ist aber das Problem ich brauch für einen 32 bit Soft-Core (50Mhz+) 4MB+ RAM und SRAM ist unbezahlbar (über 20 euronen). Leider sind mit normalen SDRAM ja nur so 20MHz herum zu schaffen ohne Cache. Daher meine Fragen an euch: -kennt ihr einen fertigen und freien Controller ? -Wie siehts bei soetwas mit der Geschwindigkeit/Reaktionszeit aus (Hit, miss)? -Das wichtigste und schwerste ist wie siehts mit den Ressourcen aus die benötigt werden. Wär ja wirklich blöd wenn dann das FPGA um einiges größer/teurer sein muss um das ganze zu implementieren. Ich Danke schon mal für ein paar Denkanstöße!
Erst mal gibt es reichlich FPGA mit integriertem DDR1 bis DDR4 je nach Preis. Ansonsten kann man den einen DDR1 Controller im FPGA mit wenig Platz implementieren: Google: Synthesizable High Performance SDRAM Controller
ist Dein Problem jetzt der RAM Controller als solcher oder die Implementierung eines Caches? Bei wahlfreiem Zugriff muss der ins BRAM oder eben doch wieder in ein SRAM. Wenn Du das DDR nämlich nicht entsprechend ansteuerst, geht die Bandbreite nämlich in den Keller und es ist auch nicht mehr so viel günstiger, pro effektiv nutzbarem RAM.
Hauptsächlich gehts mir um den Cache. DDR Controller sind in modernen FPGAs ala Spartan 6 und Cyclone 4/5 drin, wie es Lothar angesprochen hat. Jürgen Schuhmacher schrieb: > Wenn Du das DDR nämlich nicht > entsprechend ansteuerst, geht die Bandbreite nämlich in den Keller und > es ist auch nicht mehr so viel günstiger, pro effektiv nutzbarem RAM. Das mit der Performance ist mir klar (Burst zugriffe, refresh usw). Aber wie meinst jetzt, dassjetzt genau mit dem effektiv nutzbarem RAM ?
seennoob schrieb: > Hallo liebe Spezialisten, > > Ich seh immer wieder das Problem wenn man eine Anwendung mit einem FPGA > hat und mehr Speicher braucht (ab 1MB ) wird SRAM einfach zu teuer. Ich > glaub heutzutage ist auch nicht mehr Stand der Technik. > > Jetzt ist aber das Problem ich brauch für einen 32 bit Soft-Core > (50Mhz+) 4MB+ RAM und SRAM ist unbezahlbar (über 20 euronen). Leider > sind mit normalen SDRAM ja nur so 20MHz herum zu schaffen ohne Cache. > Ich Danke schon mal für ein paar Denkanstöße! Der 32bit microblaze von Xilinx bringt einen I-Cache mit, bspw. http://www.xilinx.com/support/documentation/sw_manuals/mb_ref_guide.pdf S.66 Da kannst du mal nachschauen was cache an FPGA-resourcen kostet. Dann könnte auch beim Coregenerator etc was unter Memory - CIM/CAM (Content indexed Memory/Content-addressable memory -> typische Cache Struktur). Wichtig ist die genaue Spezifikation deines caches: -cacheable area -assoziativität -writeback-strategie Mit ein paar kilobyte kann man schon etliche MByte effektiv cachen wenn man örtliche und zeitliche Lokalität optimal nutzt. MfG,
Der Microblaze ist von aussehen gesehen eine von Neumann Architektur (gemeinsamer Daten und Befehlsspeicher) legt aber intern die Daten in getrennten Regionen ab. Wie würde man dies dann für eine reine von Neumann Architektur machen ? Fpga Kuechle schrieb: > Wichtig ist die genaue Spezifikation deines caches: > -cacheable area 16 KByte lassen sich schon finden > -assoziativität Gute Frage 4 bis 8 fach sollte sich ja noch mit überschaubaren Ressourcen implementieren lassen. > -writeback-strategie Wird wohl das cut-through Verfahren am Besten sein, um auch noch mit DMAs am hintergrund arbeiten zu können (mit Konsistänzüberwachung für den DMA)
seennoob schrieb: > Der Microblaze ist von aussehen gesehen eine von Neumann Architektur > (gemeinsamer Daten und Befehlsspeicher) legt aber intern die Daten in > getrennten Regionen ab. > > Wie würde man dies dann für eine reine von Neumann Architektur machen ? Meines Erachtens unterscheidet sich ein Instruction-Cache und Daten-Cache nicht außer von den Adress- und datenbussen an denen sie angeschlossen sind. Es ist dir überlassen ob du einen gemischten oder 2 (1) getrennten cache anschliesst. FFT profitiert bspw vom I und D-cache gleichermassen, andere Anwendungen nur vom I-Cache. >> -writeback-strategie > > Wird wohl das cut-through Verfahren am Besten sein, um auch noch mit > DMAs am hintergrund arbeiten zu können (mit Konsistänzüberwachung für > den DMA) In zusammenhang mit cache ist mir cut-through nicht geläufig, ich dachte da eher a write back oder write through. Wobei die Frage ist, ob man das bei einem Instrucion_cache (I) wirklich benötigt (selbstmodifizierender code). Lesetipps bezüglich cache im FPGA: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.81.6371&rep=rep1&type=pdf http://ic.ese.upenn.edu/pdf/dmhc_fpga2013.pdf
Fpga Kuechle schrieb: > In zusammenhang mit cache ist mir cut-through nicht geläufig, ich dachte > da eher a write back oder write through. Wobei die Frage ist, ob man das > bei einem Instrucion_cache (I) wirklich benötigt (selbstmodifizierender > code). Meinte natürlich Write-through ich bin einfach schon so belastet durch so manche Feldbusse... Beim Instruction-Cache muss ich dir Recht geben. Danke für die Unterstützung!
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.