Hallo, ich möchte euch um eure Einschätzung in einer Frage bitten, wir haben eine Applikation mit hohem Datendurchsatz und verwenden FPGAs um die Umsetzung zwischen verschiedenen Links zu machen. Dabei ist auch Pufferung notwendig. Ich habe jetzt aus berufenem Munde die Einschätzung gehört, dass man kaum mehr als 20 Gigabit durch einen FPGA durchbringt, danach wird es kritisch mit dem internen Routing. Das kommt mir zu pessimistisch vor, darum komm ich mit der Frage hierher. Die Frage ist, wieviel Durchsatz schafft man aus eurer Einschätzung mit einem richtig dicken Stein ohne dass man den normalen Workflow mit den Tools verlassen muss? Also schon bei der Systemarchitektur ein brauchbares Konzept entwicklen, aber nicht später manuell Blockrams setzen müssen oä. Thx und lg, Flint
Nun das hängt erstmal von der Frequenz und der Wortbreite ab mit der man arbeitet. 125MHz @ 64 bit Wortbreite z. B. ergeben 1GB/s = 8Gbit/s Hat man nun eine massiv parallele Anwendung, hat man z.b. 2 oder 4 solche Arbeitseinheiten und kommt dann auf 16 oder 32 Gbit/s. Die Frage ist auch bekommst du Daten auch so schnell ins FPGA rein.
@Flint Auf einem aktuellen FPGA (Virtex6 und vermutlich Stratix IV) sind 300 MHz machbar, dann haengt es nur noch von der Wortbreite ab bzw. ob eventuell notwendige Konvertierungen in der entsprechenden Wortbreite bei der Frequenz gemacht werden koennen. Also nur zum Durchleiten seh ich keinen Grund warum man das intern nicht mit 256bit oder mehr machen koennen sollte. Das Problem ist eher dass FPGAs nur begrenzt IO haben.
>dass man kaum mehr als 20 Gigabit durch einen FPGA durchbringt
Ich denke mal das du Gigabit pro Sekunde meinst.
Das ist natürlich ohne die konkrete Anwendung zu kennen nicht genau zu
sagen.
Christian Leber schrieb: > Das Problem ist eher dass FPGAs nur begrenzt IO haben. Dafür gibts spezielle serielle highspeed IO's. Virtex 6 HXT bis zu 24 GTHTransceiver a 11 GBit/s. Jenseits von Xilinx gibt es noch einen Nischenhersteller der kann noch mehr. Hab leider auf die schnelle den Namen nicht parat.
Die Transceiver nutzen aber nichts, wenn man nicht intern entsprechend weiterverarbeitet. Der maximalte Datendurchsatz durch ein FPGA lässt sich mithin leicht berechenen: Zahl der IOs / 2 * Frequenz. Interne limits infolge mangelnder Verarbeitung ignoriert, folgt daraus für die high speed serial IOs: 4GB/s * n/2 -> weit jenseit 1TB/s.
Hans schrieb: > Die Transceiver nutzen aber nichts, wenn man nicht intern entsprechend > weiterverarbeitet. Intern ist kein Problem. (Ausser für das Haupthaar beim Timingclosure :-) ) > > Der maximalte Datendurchsatz durch ein FPGA lässt sich mithin leicht > berechenen: > > Zahl der IOs / 2 * Frequenz. Interne limits infolge mangelnder > Verarbeitung ignoriert, folgt daraus für die high speed serial IOs: > > 4GB/s * n/2 -> weit jenseit 1TB/s. Generische IO's können noch keine 4 GB/s, und die Zahl der high speed serial IO's ist begrenzt. Diese lassen sich auch nicht für andere Aufgaben nutzen, man wird also immer einen Kompromiss eingehen müssen. Der genannte Virtex 6 HXT kann somit >250 GBit/s plus was der Rest der IO's hergibt. (Bei 10/8 codierung sinds noch 200 GBit/s) Aber wie gesagt, es gibt Spezialisten die sind weiter.
Ich halte die gesamte Fragestelung für wenig sinnig. Man sollte mal bei der APP anfangen und sich fragen, WAS man denn eigentlich tun will und dann eine genügende Anzahl FPGAs aufs board knallen. Dann hat man den benötigten Durchsatz und gut is! Meistens sind es ja nicht die limits des Durchsatzes sondern die Echtzeitanforderungen, die dafür sorgen, daß man 3-4 halbvolle parallel arbneitende FPGAs auf dem Board hat, die rasch Wandler auslesen und impulsartig Daten wegschreiben und ansonsten alles andere tun, als maximalen Durchsatz abzuarbeiten.
Hallo, danke für die Antworten. Um ein wenig Licht in das ganze zu bringen, es geht darum, große Datenmengen in einem ASIC zu versenken, dabei gibt es mehrere parallele Kanäle, die zeitlich synchonisiert ihre Datenframes von einigen Kilobyte Größe abliefern müssen. Es gibt ein bestehendes System bei dem 10GbE verwendet wird, das Interface zum PHY ist 32 bit breit bei 156.25 Mhz und DDR, dazu kommen für jede Richtung 4 Steuersignale also ca 80 I/O Pins pro Seite, d.h. 160 I/O Pins pro 10 Gbit/s (in der Praxis kann unser Zulieferer zwar die 10 Gbit/s im FPGA noch nicht aber in diese Richtung zielt ja meine Frage). D.h. von der I/O her würde ich annehmen, dass man 4 bis 5 solche Strecken mit einem großen Teil hinbringt, d.h. 40-50 Gbit/s. Aber die Aussage war eben, dass es ab 20 Gbit/s intern schwierig wird. lg Flint
Flint schrieb: > Es gibt ein bestehendes > System bei dem 10GbE verwendet wird, das Interface zum PHY ist 32 bit > breit bei 156.25 Mhz und DDR, dazu kommen für jede Richtung 4 > Steuersignale also ca 80 I/O Pins pro Seite, d.h. 160 I/O Pins pro 10 > Gbit/s 10 GbE können aktuelle FPGA's direkt am XAUI Interface, kein externer PHY nötig. Hardwarelayout dafür ist zwar nicht trivial, aber 32bit DDR ist auch nicht ohne, IMO sogar schwieriger. Der von mir oben erwähnte Virtex 6 HXT hat in seiner grössten Ausführung 48 GTX Tranceiver (a 6 GBit/s), das sind 12 XAUI Interfaces. Wenns pro FPGA etwas kleiner sein darf, kommen dafür auch Spartan 6 in Frage. (10 GbE hat "nur" 3.125 GBit/s pro Lane)
>156.25 Mhz
Diese Frequenz kommt mir verdächtig bekannt vor. Du arbeitest nicht
zufällig im UMTS-Umfeld?
>Diese Frequenz kommt mir verdächtig bekannt vor. Du arbeitest nicht >zufällig im UMTS-Umfeld? 156,25MHz * 64 = 10Gbit (Single Data Rate) oder 156,25MHz * 32 *2 = 10Gbit (Double Data Rate) VG, SuperWilly
Hallo, die 156.25 Mhz kommen vom XGMII Protokoll. Was ich auch noch erwähnen sollte, dass die Seite zum ASIC hin eine optische Übertragungsstrecke verwenden soll zwecks Potentialtrennung, d.h. ein derartiger Transceiver außerhalb des FPGA ist unbedingt notwendig. Und wie gesagt, die Kernfrage ist, ob es intern dann ein Problem geben könnte. Ein Virtex 6 wie ihn Lattice User angesprochen hat sollte also 60 Gbit/s durchleiten können, das könnte unsere Anforderungen mal abdecken. lg Flint
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.