Hallo,
vielleicht hat jemand schon etwas ähnliches umgesetzt und kann uns bei
unserem Projekt helfen.
Unser Projekt:
Realisierung einer Datenanbindung auf Basis von 100 MBit/s Ethernet
Topologie: Point-to-point, full duplex (zwischen zwei PHYs)
Länge: Bis 100 Meter
Standard Ethernet frame:
P | SFD| Ziel-MAC | Quell-MAC | Länge | Daten |Check
Inter-Frame-Space
P | SFD| Ziel-MAC | Quell-MAC | Länge | Daten |Check
...
Präambel: 7 Byte
Start Frame Delimiter: 1 Byte
Ziel-Adresse: 6 Byte
Quell-Adresse: 6 Byte
Länge/Typ: 2 Byte
Daten: 46 – 1500 Byte
Frame Check: 4 Byte
-----------------------------------------
min. Länge: 72 Byte
Zuzüglich Abstand zwischen den Paketen:
-> Ungefähres Zeitverhalten: 1 Paket / 10 Microsekunden
Was wir wollen:
Wir wollen pro Sekunde ein Paket senden. Dafür wollen wir über eine
Ethernet-PHY (angesteuert über RMII) unsere eigenen Datagramme
versenden.
Dies sollte in etwa so aussehen.
P | Daten |Check
min. Inter-Frame-Space
P | Daten |Check
Präambel/ Start Frame Delimiter: 1 Byte (braucht PHY um J/K zu
bilden)
Data: 4 – 6 Byte
Frame Check (wenn von PHY benötigt): 4 Byte
-----------------------------------------------------
max length: 11 Byte
Zuzüglich kleinstmöglichem Abstand zwischen den Paketen:
-> Ungefähres Zeitverhalten: 1 Paket / 1 Microsekunde
Laut Datenblatt verschiedener PHYs, werden 8 Bit der Präambel gebraucht
um J/K (Paketstart) zu bilden. Das Paketende-Signal wird automatisch
angehängt.
In den Datenblättern wird allerdings immer angenommen, das die Daten in
einem Ethernet-Frame stecken. Die PHY bildet aber ja nur die
physikalische Schicht. Deshalb sollte es doch möglich sein, die
darüberliegenden Schichten auszutauschen und auch andere Datagramme zu
versenden.
Fragen:
1. Welche Ethernet-Frame Daten sind unbedingt nötig um eine PHY zu
betreiben?
2. Wie groß ist der minimale Inter-Frame-Space? Wie schnell können
Pakete nacheinander versendet werden?
3. Gibt es eine minimale Paketlänge, die die PHY erwartet?
Es sollte gehen, aber (zu deinen Fragen): 1. Präambel würde ich verwenden 2. 12 Byte (siehe IEEE 802.3 Spezifikation) 3. Lt. 802.3 sind es 64 Bytes. wenn man das einhält wird es ziemlich sicher funktioneren. Ansonsten ausprobieren! Wobei aber imemr zu berücksichten ist, dass es mit einem Phy funktionieren kann, mit einem von einem anderen Hersteller jedoch nicht.
Wichtig für uns, ist das Zeitverhalten also: Idealerweise 1 Paket/ 1 Mikrosekunde Deshalb sind uns die Pakete der IEEE Spezifikation zu groß. Unsere Lösung: eigenes Datagramm Jetzt stellt sich aber die Frage, wie "intelligent" die üblichen PHYs sind, also ob sie einfach senden, was man ihnen übergibt, oder ob sie das Paket auf irgendwelche Merkmale hin überprüfen (z.B. Präambel, CRC-Feld oder Paketlänge). Die Datenblätter geben dazu leider nicht viel her.
Wahre es denn so schlimmm einfach denn Ethernetframe mitzusenden, da würden doch auch irgendwelche Dummydaten gehen. Wenn man die Daten sogar auswertet könnte man das ganze sogar über normale Ethernet Switche mitversenden. Es gibt da durchaus andere Ethernetprotokolle auser der TCP/IP Protokoll. Z.B. das alte ISO Protokoll vom Sinec H1 Bus, das läuft noch heute durchs normale Netzwerk, nur nicht durch die Router. Da werden einfach die MAC Adessen zum adessieren der Teilnehmer verwendet, die sind da auch einfach frei vergebbar. EDIT: hat sich mit der neuen Antwort überschnitten, Frame dauert zu lange :(
1. Welche Ethernet-Frame Daten sind unbedingt nötig um eine PHY zu betreiben? Nur der JK Delimiter, also das letzte Byte (01010101) der Präambel. Die anderen Bytes der Präambel könnten auch im normalen Betrieb wegfallen (z. B. in HUBs). Alles dahinter ist dem Phy egal. 2. Wie groß ist der minimale Inter-Frame-Space? Wie schnell können Pakete nacheinander versendet werden? Fast 0. Dem Phy ist das egal, dem MAC evtl. nicht. 3. Gibt es eine minimale Paketlänge, die die PHY erwartet? Nein. >Jetzt stellt sich aber die Frage, wie "intelligent" die üblichen PHYs >sind, also ob sie einfach senden, was man ihnen übergibt, oder ob sie >das Paket auf irgendwelche Merkmale hin überprüfen (z.B. Präambel, >CRC-Feld oder Paketlänge). Die Präambel (ein Byte Minimum) wird benötigt, um zu erkennen, dass ein Frame kommt. Alles andere ist dem Phy egal. Der schiebt dann nur die Daten durch. Allerdings braucht der Phy zunächst eine gewisse Menge IDLE, um den Descrambler zu synchronisieren. Bei 10 MBit kann das aber anders sein, ich glaube aber nicht. Gruss Axel
Von der Systematik der Trennung MAC/PHY her sollte sich der PHY eigentlich nicht für den Frame in seiner Gesamtheit interessieren, sondern nur für einige Teile davon. Insoweit stimmt ich dir zu, dass die Länge der Daten dem PHY egal sein müsste, solange du explizit full duplex fährst. Dass du allerdings dazu kein Material finden wirst kann nicht verwundern, denn ausserhalb von Ethernet wird ein PHY praktisch nirgends verwendet. Ich denke du kommst nicht drum herum, dass schlicht auszuprobieren. Oder mal bei den Herstellern entsprechender PHYs anzufragen.
Bei 10/100 MBit wird die Präambel dazu gebraucht um den Epfänger zu synchronisieren. Das Interframegap muss auch eingehalten werden. Wenn man also 1 Packet pro µs senden möchte wird man zu GBit Ethernet greifen müssen.
>Bei 10/100 MBit wird die Präambel dazu gebraucht um den Epfänger zu >synchronisieren. Das Interframegap muss auch eingehalten werden. Das gilt nur für 10 MBit. Bei 100 MBit gibt es einen kontinuierlichen Datenfluss, so dass eine Neusynchronisierung nicht nötig ist. Und selbst bei 10 MBit ist das nicht mehr wirklich gültig. Die Präambel war mal gedacht für analoge Phys, deren analogen Empfangsstufen so lange brauchten. Den heutigen digitalen Phys ist das ziemlich wumpe. Mal davon abgesehen, dass in den Hubs teilweise Teile der Präambel weggefressen werden, so dass ein Phy auch mit einer Präambel von einem Byte klarkommen muss. Gruss Axel
Also würde das Konzept, das wir uns überlegt haben, höchstwahrscheinlich funktionieren, oder? Den Frame Check am Ende könnte man dann ja auch weglassen. Wichtig sind die ersten 8 Bit der Präambel um J/K zu bilden. Auf der Empfangsseite funktioniert das dann gleich? Also die PHY stellt die Daten an der RMII Schnittstelle bereit.
Axel Laufenberg schrieb: > Das gilt nur für 10 MBit. Bei 100 MBit gibt es einen kontinuierlichen > Datenfluss, so dass eine Neusynchronisierung nicht nötig ist. Ok, hab mal mit dem Osci nachgeschaut, du hast recht. Trotzdem wird es knapp, das Interframegap ist auch Pflicht da es dazu gebraucht wird Clockdifferenzen auszugleichen. Kann zwar bei sehr kurzen Packeten kleiner sein, aber ob 1 Byte reicht? (Hängt davon ab was da beim Idle über die Leitung geht) Ich würde GB Ethernet verwenden.
An GBit Ethernet haben wir auch schon gedacht, ist aber keine Option für uns. Deshalb dieser Post, da wir es (wenn möglich!) so machen wollen wie oben beschrieben.
Ich hatte mal den Interpacket Gap von 12 auf 10 verringert. Damit hatte ich schon Probleme, dass es zu Verlusten kam. Der Empfänger hatte wohl nicht so schnell mit neuen Daten gerechnet.
Axel Laufenberg schrieb: > > Und selbst bei 10 MBit ist das nicht mehr wirklich gültig. Die Präambel > war mal gedacht für analoge Phys, deren analogen Empfangsstufen so lange > brauchten. Den heutigen digitalen Phys ist das ziemlich wumpe. Mal davon > abgesehen, dass in den Hubs teilweise Teile der Präambel weggefressen > werden, so dass ein Phy auch mit einer Präambel von einem Byte > klarkommen muss. Da wäre ich skeptisch. Auch digitale Phys kochen nur mit Wasser und Clockrecovery ist nicht so einfach. Hubs ( = Repeater im Sinne der IEEE 802.3) müssen die Preamble regenerieren (Siehe Anhang B.1 in IEEE 802.3-2008) Aber seisdrum, um 10 MBit gehts hier nicht.
Daniel G. schrieb: > An GBit Ethernet haben wir auch schon gedacht, ist aber keine Option für > uns. > Warum? Braucht zwar 125 MHz Systemtakt aber RGMII ist meiner Meinung nach einfacher zu implementieren als RMII. (falls der FPGA DDR I/O kann)
PittyJ schrieb: > Ich hatte mal den Interpacket Gap von 12 auf 10 verringert. > Damit hatte ich schon Probleme, dass es zu Verlusten kam. > Der Empfänger hatte wohl nicht so schnell mit neuen Daten gerechnet. Bei welcher Packetlänge?
Weshalb genau kommt Gbit eigentlich nicht in Frage? Zu schnell fürs FPGA? Kabel zu mies? Zu wenig Adern? Denn wenn die Leitung sowieso kein Ethernet trägt, muss man sich eigentlich auch nicht an die offiziellen Takte halten und kann ein Gbit-PHY vielleicht entsprechend untertakten. Nur so als Idee.
Man muss hier unterscheiden zwischen den Problemen des Phy und des angeschlossenen MAC (und nicht zuletzt des RMII). Ich gehe jetzt mal von 100 MBit aus. Dem Phy ist das mit dem Interframe Gap ziemlich egal, da das Idle Signal permanent kommt, ist der auch permanent synchronisiert und muss auf dem Takt laufen. Da die 25 MHz am MII auch daraus generiert werden, ist das für den Phy kein Problem. Bei RMII ist das schon etwas anders. Das RMII bekommt seinen Takt nicht aus dem Empfangssignal sondern von extern. Hier kann es durchaus sein, dass es zu Synchronisationsproblemen kommt, weil die empfanngenen Daten vom Leistungstakt auf den externen RMII Takt synchronisiert werden müssen. Im extremfall kommen dei Daten schneller rein als sie über den RMII weitergeleitet werden können. Dann muss natürlich das Interframe Gap lang genug sein, um die restdaten am RMII zu übertragen. Da hängt es davon ab, wie das der Phy intern realisiert hat, bei sehr kurzen Telegrammen kann auch der Interframe Gap sehr kurz sein. Und ich habe schon MACs gesehen, die kamen ohne Interframe Gap nicht klar, weil die die Zeit zum Verarbeiten des empfangenen Frames brauchen. Gruss Axel
>> Ich hatte mal den Interpacket Gap von 12 auf 10 verringert. >> Damit hatte ich schon Probleme, dass es zu Verlusten kam. >> Der Empfänger hatte wohl nicht so schnell mit neuen Daten gerechnet. >Bei welcher Packetlänge? Normaler IP-Traffic. Das Teil wurde als Switch eingesetzt. Gesteuert von einem FPGA, wo man alles einstellen konnte.
A. K. schrieb: > Weshalb genau kommt Gbit eigentlich nicht in Frage? Zu schnell fürs > FPGA? Kabel zu mies? Zu wenig Adern? Uns stehen nur vier Adern zur Verfügung.
Axel Laufenberg schrieb: > Man muss hier unterscheiden zwischen den Problemen des Phy und des > angeschlossenen MAC (und nicht zuletzt des RMII). > > Ich gehe jetzt mal von 100 MBit aus. > Dem Phy ist das mit dem Interframe Gap ziemlich egal, da das Idle Signal > permanent kommt, ist der auch permanent synchronisiert und muss auf dem > Takt laufen. Da die 25 MHz am MII auch daraus generiert werden, ist das > für den Phy kein Problem. Da wäre ich nicht so sicher, ist im Ermessen des PHY Designers wie er die 25 MHz am MII erzeugt. > > Da hängt es davon ab, wie das der Phy intern realisiert hat, bei sehr > kurzen Telegrammen kann auch der Interframe Gap sehr kurz sein. Das ist sicher richtig, deswegen auch meine Frage an PittyJ > > Und ich habe schon MACs gesehen, die kamen ohne Interframe Gap nicht > klar, weil die die Zeit zum Verarbeiten des empfangenen Frames brauchen. > Für einen selbstimplmentierten MAC im FPGA sollte das kein Problem sein.
Lattice User schrieb: > Für einen selbstimplmentierten MAC im FPGA sollte das kein Problem sein. So sieht auch unsere Lösung aus. FPGA der uns unsere Pakete baut und an die PHY gibt und in anderer Richtung die Daten von der PHY nimmt und uns die Daten bereit stellt.
FCS muss nicht sein. Probier es mit folgendem:
1 | 2 Byte Preamble |
2 | 1 Byte Start |
3 | 6 Byte Daten |
4 | 1 Byte CRC über die Daten |
5 | 2-3 Byte GAP |
6 | ---------- |
7 | 12-13 Bytes |
1 µs = 12.5 Bytes Kann allerdings sein, dass du mehrere PHYs durchtesten musst. Was spricht dagegen meherere Datensätze in ein Packet zu verpacken?
wenn es eh kein Ethernet mehr ist, kann man nicht einfach die Frequenz etwas erhöhen?
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.