GMII/RGMII TX_ER-Signal: garantierte Funktionalität?

Ich habe eine Frage, die GENAU klären soll, was während eines GMII-Austauschs zwischen MAC und PHY passiert. Insbesondere bezüglich des TX_ER-Signals.

IEEE 802.3 Abschnitt 3:

TX_ER wird von der Reconciliation Sublayer getrieben und soll synchron in Bezug auf GTX_CLK übergehen. Wenn TX_ER für eine oder mehrere TX_CLK-Perioden geltend gemacht wird, während TX_EN ebenfalls geltend gemacht wird, soll die PHY eine oder mehrere Codegruppen emittieren, die nicht Teil der gültigen Daten oder des Begrenzers sind, die irgendwo in dem übertragenen Rahmen gesetzt sind. Die relative Position des Fehlers innerhalb des Rahmens muss nicht bewahrt werden. Abbildung 35–4 zeigt das Verhalten von TX_ER während der Übertragung eines Frames, der einen Fehler propagiert.

Geben Sie hier die Bildbeschreibung ein

Meine Frage: Wenn TX_ER vom MAC aktiviert wird (während TX_EN hoch bleibt), verlässt der Frame immer noch den PHY mit allen anderen Frame-Bytes, die noch intakt sind, und NUR die Bytes, die übertragen werden, während TX_ER hoch ist, werden durcheinander gebracht? Oder stoppt der PHY die Übertragung des Frames vollständig, sobald ein Fehlersignal erkannt wird?

Ich arbeite an einem FPGA-Design, das in der Lage sein sollte, einen Frame basierend auf seinem Inhalt zu löschen oder weiterzugeben, und ich frage mich, ob die Behauptung des GMII TX_ER-Signals an den PHY als "Drop the Frame" angesehen würde oder nicht.

In dem Fall, dass die Bytes immer noch den PHY verlassen, würde es scheinen, dass das Paket nur „verworfen“ würde, weil das Ethernet-FCS nicht mit dem Inhalt des Pakets übereinstimmen würde. Der Frame-Inhalt würde jedoch weiterhin vom PHY am anderen Ende empfangen, und wenn die Empfängerseite Zugriff auf die physikalische Schicht hätte, könnten die Daten möglicherweise wiederhergestellt werden (was in meinem Fall nicht akzeptabel ist).

Ich habe dies mit dem Netzwerkdienstprogramm iperf getestet, und es scheint, dass die Anwendungsdaten nicht durchgehen, wenn TX_ER aktiviert ist. Wireshark scheint mir jedoch zu sagen, dass noch gültige TCP-Pakete empfangen werden, und ich verstehe nicht, wie das möglich ist, wenn der CRC der physikalischen Schicht nicht mit dem Frame-Inhalt übereinstimmt.

Jeder Einblick sehr geschätzt.

Danke!

Antworten (1)

Aus dem von Ihnen geposteten Auszug aus IEEE 802.3:

Wenn TX_ER für eine oder mehrere TX_CLK-Perioden geltend gemacht wird, während TX_EN ebenfalls geltend gemacht wird, soll die PHY eine oder mehrere Codegruppen emittieren, die nicht Teil der gültigen Daten oder des Begrenzers sind, die irgendwo in dem übertragenen Rahmen gesetzt sind.

Das Paket wird weiterhin vom PHY über die Leitung gesendet. Der PHY enthält keinen FIFO, der groß genug für ein ganzes Paket ist, daher gibt es für den PHY keine Möglichkeit, den Rahmen bei einer Bestätigung von TX_ER fallen zu lassen. Was der PHY tut, ist einen Außerband-Fehlerzustand einzufügen, normalerweise in Form von ungültigen oder Fehleranzeige-Codewörtern, die der PHY auf der Empfangsseite interpretieren und RX_ER bestätigen wird. Ich glaube, dass nur die Datenbytes geändert werden, die den Fehlercodewörtern entsprechen, alles andere wird korrekt empfangen. Es scheint nicht so, als ob der PHY die genauen Bytes, die der TX_ER-Zusicherung entsprechen, fehlerhaft machen muss, solange irgendwo im Rahmen ein Fehler eingefügt wird. Der Empfangs-MAC sollte den Frame verwerfen, wenn RX_ER während des Empfangs aktiviert wird (genauso wie wenn der FCS schlecht ist), aber es könnte durchaus möglich sein, einen Teil des Frames wiederherzustellen.

Wenn Sie wirklich sicherstellen möchten, dass das Paket niemals gesendet wird, würde ich empfehlen, das Paket in einem FIFO zu speichern und es erst aus dem FIFO freizugeben, wenn Sie den Frame überprüft und festgestellt haben, dass Sie es tatsächlich senden möchten. Dies fügt jedoch eine von der Paketlänge abhängige Latenz hinzu, die akzeptabel sein kann oder nicht.

Hier ist eine Implementierung eines FIFO, die genau das tut; Löschen von Frames, die mit einem aktivierten Tuser-Signal als ungültig markiert sind: https://github.com/alexforencich/verilog-ethernet/blob/master/lib/axis/rtl/axis_frame_fifo.v .

Vielen Dank, das war mein Verdacht. Ich könnte das Fehlersignal für die Dauer des Frames hoch halten, da mein Design bereits genügend FIFOs (für andere Zwecke) enthält, um der gesamten russischen Armee zu ermöglichen, Taktdomänen ordnungsgemäß zu überqueren. Und +1 Punkte für den Code, der mit einer AXIS-Schnittstelle und allem heiß herkommt!
Nun, es gibt auch eine asynchrone Version des gleichen FIFO-Moduls. Sowie ein abgespecktes MAC-Modul. Wenn Sie die Daten im AXI-Format haben, warum spielen Sie dann im GMII-Format damit herum?
GMII/RGMII TX_ER-Signal: garantierte Funktionalität?
AntwortenHierDatenschutz-Bestimmungen1y, 0v