Hallo Leute, ich habe ein theoretisches Verständnisproblem. Ich würde gerne mittels einer 1:1 Punktverbindung zwischen zwei FPGAs sehr schnell Daten austauschen im Bereich mit ca 40 MBit/s. Mir ist die Idee gekommen das mit einer Ethernet Punkt-zu-Punkt Verbindung zu machen. Leider habe ich bisher nur ein Ethernet-Projekt mit einem uC gemacht und da habe ich mich auf Referenzschaltpläne und Beispielcode gestürzt und hatte das relativ schnell am Laufen ohne wirklich zu wissen was da passiert. Grundsätzlich hat man ja eine MAC-Hardware, die über das MII Interface dann den MAC-Frame in den PHY pusht. Bei normalen MII dann mit 25 MHz und 4 parallel Datenleitungen. Sobald das TX_EN auf high geht, kommen abwechselnd dann immer erst die 4 LSB vom byte und dann die 4 MSB vom byte. Muss ich zwingend über MII MAC-Frames pushen oder kann ich das MII Interface auch mit Random-Daten aus einem FIFO füttern um es am anderen Ende 1:1 so wieder am RX des MII rausbekomme. Ist mein verständnis so korrekt? Leider findet man dazu wirklich sehr sehr wenig was wirklich auf dem MII abgeht schlussendlich.
Markus schrieb: > Muss ich zwingend über MII MAC-Frames pushen oder kann ich das MII > Interface auch mit Random-Daten aus einem FIFO füttern um es am anderen > Ende 1:1 so wieder am RX des MII rausbekomme. > > Ist mein verständnis so korrekt? Du kannst mit deiner PHY bzw. MII machen, was du willst. Frames/etc. setzen ja erst Ebenen höher im Protokolstack auf. (nur: beim P2P achte bitte auf Crossover-Kabel..!). Probier also einfach mal eine beliebige Bytefolge auf einem PHY aus und beobachte, was auf der anderen Seite rauskommt. Sollte keine Überraschung sein.
Naja, das stimmt so halb... du musst schon sowas wie Pakete mit Pause dazwischen schicken. Du hast generell das Problem, deine Daten einzusynchronisieren, sowie Integrität zu garantieren. Da kannst du gleich einen MAC-Controller nehmen. Bei nur Peer-to-Peer kannst du dann rohe Ethernet-Pakete schicken, das klappt prima. Aber auch mit einer Standard-UDP/RTP-Lösung (da gibt es einige) schaffst du deine 40 Mbit/s locker an Bandbreite. Ich nutze hier RTP für Messdaten bei einem Durchsatz um die 8 MByte/s an komprimierten Daten.
Du musst keine Ethernet-Frames verschicken. Was du aber machen solltest: Die Preambel und den Start-Frame-Delimiter senden. Weiterhin solltest du auch die Inter-Frame-Gap einhalten. Weg lassen kannst du: Destination und Source Address Ethertype FCS
Sigi schrieb: > nur: beim P2P achte bitte > auf Crossover-Kabel..! Falls dein PHY Auto-MDI/MDIX kann, dann brauchst kein Crossover Kabel
2 FPGAs? 40 Mbit/sec? Wie waer's mit einer SPI-Verbindung mit wenns denn sein muss mehr als einem MOSI/MISO? Zur Not auch noch LVDS zwischen den beiden FPGAs. Das ist eigentlich Kinderkram...
berndl schrieb: > 2 FPGAs? > 40 Mbit/sec? > > Wie waer's mit einer SPI-Verbindung mit wenns denn sein muss mehr als > einem MOSI/MISO? > Zur Not auch noch LVDS zwischen den beiden FPGAs. Das ist eigentlich > Kinderkram... War auch mein erster Gedanke. Wenn die Ethernet Schnittstelle schon verfuegbar ist, z.B. weil man Evalboards verwendet, dann macht es doch Sinn. Besser als an irgendwelche Pinheader mit selbst konfektionierten Kabeln rumhantieren.
Danke erstmal für euer Feedback. Die zwei FPGAs werden später eine Distanz von ca. 30/40 Meter voneinander haben. Daher die Idee standard RJ45 Kabel zu nehmen. SPI über LVDS hatte ich auch schon als Gedanke, aber will etwas neues dazu lernen und da denke ich ist Ethernet der professionellere Weg. Danke euch!
Bei der Distanz bist du mit Ethernet definitiv gut beraten. Und es ist jetzt auch kein Hexenwerk, den PHY korrekt zu füttern. Beachte aber, dass beim Sender der Takt ebenfalls vom PHY kommt. Du musst also Takt einlesen und dann Daten ausgeben. Und das unter Einhaltung der Setup-Zeit des PHY. Hier musst du ein wenig drauf achten, dass du das Timing nicht verletzt.
Moin, Markus schrieb: > Danke erstmal für euer Feedback. Die zwei FPGAs werden später eine > Distanz von ca. 30/40 Meter voneinander haben. > Daher die Idee standard RJ45 Kabel zu nehmen. Gute Idee. Was genormtes, was schon mio.fach funktioniert, hat schon was. Wenn du da auch noch das bisschen Aufwand treibst und deine Daten in RTP verpackst, hast du automatisch sehr gute Debugmoeglichkeiten (Wireshark, etc.) und Timestamps. Und das alles, ohne sich irgendein krampfiges Protokoll selbst ausdenken zu muessen, wo eh' die Haelfte nicht funktioniert oder nicht beruecksicht wurde. > SPI über LVDS hatte ich auch schon als Gedanke, aber will etwas neues Bloss nicht so einen teuren, proprietaeren Shice anfangen. Was kostet denn ein Fast EthernetPHY? So gut wie nix. Und da sind adaptive Kabelentzerrer etc. bla drinnen. Vollduplex sowieso. Also ein dicker DSP mit fehlerfreier Firmware fuer fast umme. Galvanische Trennung gibts bei Ethernet auch voellig selbstverstaendlich. Ist bei den Distanzen auch immer ne gute Idee. > dazu lernen und da denke ich ist Ethernet der professionellere Weg. So ist's. Und wiejesaaacht: Ich taet' auch tatsaechliche Ethernet, wenn nicht sogar IP/UDP/RTP Frames schicken, um eigens ausgedachte Protokolle moeglichst zu vermeiden. Gruss WK
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.