mikrocontroller.net

Forum: FPGA, VHDL & Co. Bauchgefühlfrage zu maximalem Durchsatz FPGA


Autor: Flint (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian Leber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Lattice User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lattice User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hallbergmoser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Flint (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lattice User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Fridolin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>156.25 Mhz
Diese Frequenz kommt mir verdächtig bekannt vor. Du arbeitest nicht 
zufällig im UMTS-Umfeld?

Autor: SuperWilly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Flint (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.