Für ein Spezialprojekt i.Z. mit der Uni Freiburg, in dem Biodaten erfasst und berechnet werden müssen, soll eine kleine Plattform entwickelt werden, die in Echtzeit frames buffern und umlagern kann. Dazu braucht es etwa 10 TerraBit birektionale Bandbreite zum RAM. Grösse etwa 200 MB. Vorgeschlagen wurde ein kleines, trabares (das ist Pflicht) board Spartan 6 FPGA(s) im 676 Gehäue, das 4MCBs enthält und theoretisch DDR-RAMs anbinden kann. Aufgrund des wahlfreien Zugriffs auf die Blöcke mache ich mir Sorgen um die Bandbreite. Hat jemand eine Hausnummer was man mit dem S6 sicher bidirektional erreichen kann?
10 TerraBit/s etwa? Sicher dass das als Anforderung an ein tragbares System hinkommt? Also der Spartan 6 schafft gerade mal 800MBit/s pro MCB also 400MHZ DDR. Und da geht noch bissl was für den Overhead drauf, denn an so einem DDR RAM geht ja immer höchstens 32 Word Burst oder sowas. Außerdem kann so ein RAM nur entweder beschrieben oder gelesen werden zu einem Zeitpunkt. Mit 4 MCBs hast du theoretisch höchstens 4 * 12,8GBit/s (Bei 16 Bit Speicher) unidirektionale Bandbreite am Spartan 6. Siehe http://www.xilinx.com/support/documentation/user_guides/ug388.pdf Seite 12.
Spartan 6 - 600Mbps sollten sicher drin sein. Nur so eine Hausnummer. Xilinx erzählt einem was von 12,x Gbps peak bandwith - naja halt bis der FIFO voll ist. E. M. schrieb: > etwa 10 TerraBit birektionale Bandbreite zum RAM Hast du dich da nicht um 10^3 verschrieben? Du willst 1,3 TB pro Sekunde schreiben? Bist du wahnsinnig? E. M. schrieb: > Spartan 6 FPGA(s) im 676 Gehäue Meister das ist die Low-Cost Line! Wenn du ernsthaft solche Datenraten übertragen willst, dann darfst du dich darauf einstellen dass das Decoupling von deinem FPGA >500€ kosten wird. Deine Platine wird min. 18 lagig. 10Tbit dagegen ist Motherboarddesign ein Witz. Dein FPGA dürfte soviel wie ein Porsche kosten ..
Der FPGA wurde nicht von mir vorgeschlagen :-) > 800MBit/s pro MCB Pro Leitung, oder? Es sind 10 GBit Bandbreite, ich hatte mich im präfix vergriffen. Das FPGA ( es gehen auch 2 oder 3 wenn nötig) muss die Daten im RAM puffern, die Daten aus verschiedenen Quellen = RAM-Bereichen wieder abholen und zu Mustern ordnen. Diese werden bewertet und dann ein Ergebnis gefunkt. Das geht dann mit 433MHz im slow format.
Jo, 800MBit/s pro Pin, daher 12.8Gb/s bei 16 Bit Speicher. Pro MCB passt in dem Zusammenhang dann nicht, sorry. 10Gb/s ist ja noch machbar mit mehreren MCB.
Laut Datenblatt hat der S6 insgesamt 4 MCBs, die man zu zweimal 32 Bit zusammenschalten könnte. Rechnerisch wären es ungefähr 50GBit/s mit allen MCBs- allerdinges peak Bandbreite und ich brauche 10GB bidirektional im Mittel. Das wird eng denke ich, weil ich nicht unbedingt en block lesen kann. (Schreiben schon). Wenn ich wahlfrei lese, komme ich auf 1/4 der Bandbreite. Wegen 50:50 Schreiben zu Lesen laste ich also optimalerweise zu 50%+50%/2 = 60% aus. Sind 30 Gbps und 20 brauche ich. Gerade 1/3 Reserve für peek gegen average. Mit optimalen Fifos und timing müsste es gehen, brauche aber die 800 MHz. Bei unserem letzten Design waren nur 666 MHz erreichbar ...
> Das FPGA ( es gehen auch 2 oder 3 wenn nötig) muss die Daten im RAM > puffern, die Daten aus verschiedenen Quellen = RAM-Bereichen wieder > abholen und zu Mustern ordnen. > Wenn ich wahlfrei lese, komme ich auf 1/4 der Bandbreite. Hier lohnt es sich, wenn Du Dir etwas Gedanken über Dein Memory Mapping machst, damit Deine Zugriffe nicht mehr ganz so "random" sind. Ganz konkret musst Du Dein Mapping so hinkriegen, dass sowohl das Schreiben als auch das Lesen (in einem anderen Muster) die Row Adress möglichst wenig bewegt.
http://www.achronix.com/products/speedster22ihd.html http://www.xilinx.com/products/silicon-devices/fpga/virtex-7.html http://www.altera.com/devices/fpga/stratix-fpgas/stratix-v/stxv-index.jsp
Aber son FPGA wird wohl ca. 30000€ kosten. Ist halt für Radar, Mobilfunk Baseband Stationen und 100GBit Ethernet usw.
Ich stehe auch vor der Frage, wie ich mein DDR besser ausnutzen kann. Beim DDR2 war der burst ja 4 Worte lang, beim DDR3 sind es 8. Habe gerade bei EETimes etwas gelesen, dass bei der Benutzung von 4 es zu burst gaps kommt. Ich gehe daher davon aus, dass ich am Besten mindestens 8 Worte zusammenfassen sollte, zum Schreiben und Lesen, oder? Peter K. schrieb: > Ganz konkret musst Du Dein Mapping so hinkriegen, dass sowohl das > Schreiben als auch das Lesen (in einem anderen Muster) die Row Adress > möglichst wenig bewegt. Welche "Regeln" gäbe es darüber hinaus noch?
Von einem anderen Projekt das ich mitverfolgt habe, kenne ich irgendwie ähnliche Fragen. Möglichst billiger FPGA und günstiges DRAM (Statt schnelles SRAM). Das ganze wird sogar als noch als Hobby vorangetrieben, bin daher immer beeindruckt was die (er) zustande bringt. Dem Thema Speicherzugriff, -latenz und optimierung der Burst Zugriffe zusammen mit einem Cache hat Sébastien Bourdeauducq mal einen ganzen Vortrag gewidmet. Die Anwendung unterscheidet sich natürlich von deiner, aber das vorgehen wird ähnlich sein. - Verstehen was du genau machst - Simulieren wie die Performance ist wenn du naiv vorgehst - Wege zur Optimierung suchen und diese simulieren Seinen Vortrag kannst du z. B. hier ansehen: http://www.yourepeat.com/watch/?v=aN83emyPwLo Die Folien zu seinem Vortrag: http://lekernel.net/presentations/Milkymist_26C3/
Danke, das werde ich mir ansehen.
>Verstehen, was du machst
Da ist auch mir noch nicht ganz klar, was ich machen soll. Hängt von den
Datenstrukturen ab und die liegen noch nicht fest.
Ich meine eher den grossen Zusammenhang. Den musst du gut verstehen. Wie die Datenstrukturen aussehen, wirst du stark mitbestimmen müssen (Mach das denen jetzt schon klar). Das wollte dir Peter K. schon sagen.
Peter K. schrieb: >> Wenn ich wahlfrei lese, komme ich auf 1/4 der Bandbreite. > > Hier lohnt es sich, wenn Du Dir etwas Gedanken über Dein Memory Mapping > machst, damit Deine Zugriffe nicht mehr ganz so "random" sind. ok, das habe ich nun inzwischen getan und bin zu dem gigantisch genialen Ergebnis gekommen, einen vorsortierenden FIFO einzusetzen, damit die Daten in verschiedene pipelines eingeladen werden und dann ruckweise geschrieben werden können. Damit laste ich die Schreibseite sicher bestens aus und das Lesen wird ein wenig homogener. Der geniale Trick: Ich kann anhand der rekonstruierten Daten in etwa abschätzen, was NOCH gelesen werden kann und verpasse einfach jedem Datum noch einen Partner direkt hintendran. Der kommt dann immer mit raus. Beim Lesen habe ich dann zu 50% ein Doppelergebnis. Brauche halt mehr Platz und Schreibebandbreite. Zwischenzeitlich habe ich mir die Angelegenheit für SRAMs durchgerechnet: Viel zu viele IOs :-( Was ich noch gebrauche könnte, wäre ein intelligentes Caching für Daten, die kurz vor nach dem Schreiben gelesen werden müssen.
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.