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.
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.
