Hallo zusammen,
ich möchte gerne mit einem FPGA eine 10G Ethernetverbindung
(voraussichtlich 10GBaseT) aufbauen.
Gibt es einen Ethernet Phy den ihr mir hierfür empfehlen könnt?
Welche Anbindung ans FPGA würdet Ihr nutzen?
Als FPGA habe ich die Artix Familie im Blick.
FPGA-ING schrieb im Beitrag #6678042:
> Welche Anbindung ans FPGA würdet Ihr nutzen?
Das hängt doch vom gewählten PHY ab?
Je schneller die Datenrate auf den Pins ist, desto weniger braucht man
davon.
Die Artix haben alle GTP Transceiver dabei, aber maximal mit 6,6 GBps.
Da braucht man für 10G schon mehr als nur einen.
Intern kann bzw. muß man bei 10G 64 Bit parallel mit 156.25 MHz
verarbeiten.
> Gibt es einen Ethernet Phy den ihr mir hierfür empfehlen könnt?
Momentan würde ich nach Verfügbarkeit und Preis gehen.
Dann wäre für mich ein weiteres Kriterium, wie hoch der Aufwand ist um,
an ein Datenblatt (keine Marketingbroschüre) zu kommen.
Die PHYs die ich auf die Schnelle bei Mouser gefunden habe, sind alle im
BGA-Gehäuse. Das ist ja auch mal nicht soeben in der Bastelwerkstatt
gelötet...
Duke
FPGA-ING schrieb im Beitrag #6678042:
> (voraussichtlich 10GBaseT) aufbauen.
Kann man nicht einfach die beiden Paare Rx+-/Tx+- von einem SFP+ Slot
an einen FPGA löten?
FPGA noob schrieb im Beitrag #6678134:
> FPGA-ING schrieb im Beitrag #6678042:>> (voraussichtlich 10GBaseT) aufbauen.>> Kann man nicht einfach die beiden Paare Rx+-/Tx+- von einem SFP+ Slot> an einen FPGA löten?
Nein.
Gustl B. schrieb:> IQ130+ schrieb:>> Nein>> Dann bist entweder du ein Troll oder Trenz hat den SFP+ falsch> angeschlossen.
Das Tippen des Unwortes "Troll" hat Dich wohl so sehr verausgabt, das es
nicht mehr zum Setzen eines Links zu besagten Trenz Board reichte!?
IQ130+ schrieb:> Gustl B. schrieb:>> IQ130+ schrieb:>>> Nein>>>> Dann bist entweder du ein Troll oder Trenz hat den SFP+ falsch>> angeschlossen.
So hab mir jetzt mal ein Trenz-SFP+-10G angeschaut.
https://wiki.trenz-electronic.de/display/PD/TEF0008+TRM
Wenn ich das Blockbild (Anhang) recht verstehe, sind da lediglich
Steuerleitungen an den MAX10 geknüppert und die eigentlich interessante
differentielen Hi-Speed Datenleitungen werden zum FMC durchgeroutet.
Takte werden auch nicht einfach so aus dem FPGA geballert, sondern vón
einem dedizierten Low-Jitter IC synthetisiert.
Das ist nach meinen Verständnis kein "einfach an den FPGA löten",
nachdem es dem TO seinen Worten nach verlangt.
FPGA noob schrieb im Beitrag #6678134:
> Kann man nicht einfach die beiden Paare Rx+-/Tx+- von einem SFP+ Slot> an einen FPGA löten?
So hab mal bei Xilinx geschaut, für 10G brauchts GTH (13.1 Gps), die vom
TO angepeilten Artixe haben aber nur GTP (6.6 Gps). Siehe Anhang.
Und zum GTH hat es 500+ seiten Manual sicher nicht 'noob-friendly' aka
anfänger-freundlich.
Natürlich brauch man einen FPGA der 10.x Gbps auf den SFP+ Stecker geben
kann oder man hat einen PHY mit XGMII auf dem Board (letzteres ist eher
selten).
Gustl B. schrieb:> Da sollte selbst der kleinste Artix dieser Familie passen.
Ja, aber 'Artix' und 'Artix Ultrascale+' sind zwei verschiedene Paar
Schuhe.
Abgesehen davon, das es man die Artix Ultrascale+ auch nirgendwo kaufen
kann.
Das 'Ultrascale+' scheint sich übrigens auch auf den Preis zu beziehen:
Die günstigsten 'Zynq Ultrascale+', die ich gefunden habe, kosteten
etwas über $200.
Für einen Chip.
Duke
Duke Scarring schrieb:> Die günstigsten 'Zynq Ultrascale+', die ich gefunden habe, kosteten> etwas über $200.> Für einen Chip.
In dem ja mindestens vier ARM-Cores sitzen, plus FPGA-Fabric und
Peripherie-Geschiss.
https://www.xilinx.com/products/silicon-devices/soc/zynq-ultrascale-mpsoc.html
Das sollte man nicht vergessen wenn man Artix mit Zynq vergleicht. Egal
ob Ultrascale oder Vorgänger.
Den XC7Z007S-1CLG225C (Single-ARM) gibt es inklusive MwSt f. 45€
(allerdings ist die Lieferzeit derzeit alptraumhaft)
Fpgakuechle K. schrieb:> In dem ja mindestens vier ARM-Cores sitzen, plus FPGA-Fabric und> Peripherie-Geschiss.
Ein Zynq wäre gfs aber schon anzuraten, vor allem, weil man den PHY ja
auch mit etwas besaften muss und ein MAC im ARM ist allemal noch besser
handhabbar, als der TriCore E.MAC.
FPGA-ING schrieb im Beitrag #6678042:
> (voraussichtlich 10GBaseT)
davon rate ich ab. 10GBase-T hat sich nicht durchgesetzt und ist nur
eine Notlösung wenn es gar nicht anders geht.
Nachteile:
- die PHYs verbrauchen sehr viel Strom, im Bereich von 5 bis 10 Watt pro
aktivem Port
- auch wenn bis 100 m Kabellänge spezifiziert, treten in der Praxis
schon lange vorher Probleme mit der Zuverlässigkeit auf. Auch wenn die
Verkabelung ordentlich ist, durchgemessen mit Messprotokoll und allem.
- höhere Latenz durch Puffer im PHY
Pack lieber einen SFP+-Slot auf Dein Board. Zum einen machst Du Dir
damit das Leben viel einfacher, zum anderen kannst Du da gängige und
billige Direct-Attach-Kabel oder Glasfaser-Module einstecken.
Was sich dagegen gerade in der Praxis durchsetzt, ist 2.5GBase-T. Das
hat die genannten Probleme nicht. Manchmal reicht das von der
Geschwindigkeit her natürlich nicht.
Neben dem hohen Stromverbrauch spielt natürlich der Preis bei 10G vs.
2.5G eine entscheidende Rolle. Das ist wie mit billigen Sofas: Die
setzen sich mehr und mehr durch...
Duke Scarring schrieb:> Neben dem hohen Stromverbrauch spielt natürlich der Preis bei 10G vs.> 2.5G eine entscheidende Rolle. Das ist wie mit billigen Sofas: Die> setzen sich mehr und mehr durch...
Nunja, wo wird 10G tatsächlich benötigt?
Also braucht man ein Sofa, das einen Ausgewachsenen Silberrücken Gorilla
jahrelang erträgt, wenn man es nur mit Liszt-Äffchen zu tun hat...
DSL läuft mit 100 Mbit, WLAN mit 600 Mbit/s, tippen tue ich mi 40 bps
;-)
wo braucht man 10 GBit als beim Hoster7provider?
Wenn es maximal schnell sein muß am FPGA würde ich eher nach PCIe
schauen.
Hallo in die Runde,
danke für Eure Rückmeldungen. Wir werden noch mal in uns gehen und die
verschiedenen Varianten beleuchten. Ein SFP+-Slot klingt erst mal gut,
wobei wir sehen müssen, wie weit der Platz dafür reicht. Die PCB Größe
ist ebenfalls ein relevanter Faktor.
Ich werde mich weiter schlau machen und ggf. mich hier ggf. noch mal
melden.
Man sollte sich allenfalls noch mal überlegen, ob Einführung von
Kompression nicht eine Option ist. Das ist allerdings bei der Datenrate
etwas knifflig, da man wohl parallelisieren müsste (DPCM/Huffman
encoder). Ansonsten ist die Aussage von robberknight zu unterschreiben.