- XAUI2 gibt XGMII Daten aus, die mit Fehlercodes behaftet sind.
- Diese befinden sich im Raum der Präambel.
- Die Präambel ist wichtig, damit MAC2 Daten übersetzt.
Wenn ich einen internen PHY-Loopback mache, werden die Daten auch wieder
zurückübersetzt bei axi1(Rx)
( lane-order & polarities musste ich anpassen)
1
axi1(Tx)->MAC->XAUI->PHYLoopback
2
axi1(Rx)<-
Komisch finde ich, dass meine Präambel, die am MAC2-Eingang sehe, mit
Fehlern 0xfe behaftet ist. Undzwar nur in diesem Bereich.
Die Präambel sollte 0x D5 55 55 55 55 55 55 FB im XGMII-Frame annehmen.
Der reconciliation Layer legt Wert auf die Reihenfolge.
Habe das auch extra mal getestet, wenn ich z.B. eine 5 weglasse oder die
Reihenfolge tausche in einem simplen MAC <-- XGMII Beispiel.
Der Übersetzt dann wirklich nichts.
Norm:
Was ich seltsam finde ist:
Das restliche XGMII-Paket scheint mehr oder weniger in Ordnung zu sein
(lane-order & polarities habe ich angepasst).
Wenn ich mir den MAC1-XGMII-Ausgang anschaue, sehe ich keine Fehler.
D.h. der XAUI1 oder gar einer der PHYs fügt diese Fehlercodes 0xfe ein?
Aber warum eigentlich?
Vielleicht hat jemand dazu eine Idee...
Vielen Dank :D
Rezy schrieb:> Schnellschuss: Möglicherweise werden die Fehlercodes eingefügt, weil das> benötigte inter frame gap nicht eingehalten wird?
Darüber denke ich auch schon die ganze nach. Habe diesen aber mehr oder
weniger berücksichtigt. Mein axi1(Tx) sendet Frames immer mit kleiner
Pause
Hier nur nochmal meine aktuellen Beobachtungen
Aktuell
* near end MAC1 loopback -MAC1 übersetzt "normal" nach axi
* near end XAUI1 loopback - MAC1 übersetzt "normal" nach axi
* PHY1 internal loopback - MAC1 übersetzt "normal" nach axi
=> Nur wenn ich das ganze auf den nächsten PHY2 ausweite werden 0xfe
eingefügt in dem Bereich der Präambel.
Zwar habe ich noch nicht genau geschaut, was ich für einen ifg
eingestellt habe (in axi1(Tx) ), aber die genannten loopbacks zeigten
mir eigentlich, dass er ausreichen müsste.
Schau dir bitte die Spezifikation des XGMII Interfaces an. Das sendet in
der Regel IDLE (0x07), gefolgt von Start KCODE (0xFB), dann sollte es
mit der Preambel losgehen, und nach dem Ethernet CRC kommt das Terminate
KCODE (0xFD) gefolgt von IDLE.
Das was du machst, vor dem FB schon die Preambel zu schicken ist falsch.
Kleiner Tipp: Hänge mal deine Hardware an einer Netzwerkkarte an und
schau einfach mal, was du da bekommst. Dann hast es aus erster Hand wie
es aussehen muss
tja schrieb:> Schau dir bitte die Spezifikation des XGMII Interfaces an. Das sendet in> der Regel IDLE (0x07), gefolgt von Start KCODE (0xFB), dann sollte es> mit der Preambel losgehen, und nach dem Ethernet CRC kommt das Terminate> KCODE (0xFD) gefolgt von IDLE.>> Das was du machst, vor dem FB schon die Preambel zu schicken ist falsch.
Denke ich mache das wie du sagst:
Die axi1(Tx) Daten generiere ich ja selber.
Aber der MAC1 generiert die XGMII Pakete selber.
=> Sofern mein axi1(Tx) korrekte Signale sendet, startet der MAC1 auch
seine XGMII-Übersetzung selbständig.
Ich denke ich habe keinen Einfluss auf die XGMII-Pakete.
Im Vivado-Scope wird das so angezeigt:
1
xgmii_txd=0xD5555555555555FB
2
xgmii_txc=0x01
Habe das noch mal im Anhang.
Und den IEEE Teil zur Präambel auch angehangen.
Dort wird festgelegt auf welche lane welches Signal kommen muss.
Habe das in einer kleinen Simulation nachgestellt und konnte sehen, dass
es wahrscheinlich wirklich so ist. Bei einer Variation wird der Frame
nicht mehr von einem MAC akzeptiert.
Und End of frame scheint flexibel zu sein:
Aber wird ja auch vom MAC selber generiert
Wie gesagt die Loopbacks funktionieren.
tja schrieb:> Kleiner Tipp: Hänge mal deine Hardware an einer Netzwerkkarte an und> schau einfach mal, was du da bekommst. Dann hast es aus erster Hand wie> es aussehen muss
Hab das schon öfters versucht, aber die Pakete kann ich mir aus
irgendeinem Grund nicht korrekt anzeigen lassen.
LED blinkt, aber in wireshark kann ich nie meine eigenen Daten sehen..
und die sind eigentlich wiedererkennbar.
Ich schaue gerade wo überall Fehler eingefügt werden können.
Es müssen ja die Blöcke sein, die für den Leitungscode zuständig sind.
Für Ethernet 10GBase R:
8B/10B und 64B/66B
* 8B/10B für XAUI
* 64B/66B für das Medium
* PCS enthält 64B/66B für PHY
* PCS enthält 8B/10B für XGXS
Für die PCS steht in der IEEE:
* Im XAUI Product Guide sehe ich auch gerade:
RXD = 0xFE , RXC = 1, when disparity errors or invalid data are received
or if the received inter frame gap (IFG) is to small...
* Ob es invalid data sind soll man sich mit mgt_codevalid anschauen.
ich glaub den vector gibt es gar nicht mehr. Aber trotzdem muss ich mir
mal ein paar transceiver vectoren anschauen..
* Die vorhandene Blockkette ist ja etwas länger.
* Also ich denke, da ich ja bereits XAUI1 geloopacked habe fügt er keine
Fehler ein.
* Ich müsste wahrscheinlich ab PCS1 schauen, ob fehler eingebaut werden.
* IFG beträgt laut IEEE " The minimum IPG at the XGMII of the receiving
RS is five octets"
Im XAUI Product guide steht: "XAUI Core is expected to signal an error
in this manner if t he received frame does not meet the specificiation"
Ok da steht, dass der RS durch "error control character" dem PHY
befehlen soll, dass er einen gut zu entdeckenden Fehler einbauen soll.
Also der Fehler der bei mir auftritt ist wirklich nicht zu übersehen..
der 10G-R PHY1 besteht aus ---> xgxs --> PCS PMA und PMD --->
Wenn ich einen internen loopback bei xgxs mache kommen die Daten auch
wieder ohne 0xfe zurück.
Wenn ich den Loopback nach der Gearbox im PCS mache kommen auch die
Fehler, die ich bei dem größeren Loopback beschrieben habe..
* Die Preamble wird einfach mit 0xfe behaftet ..
* Man sieht dann noch die IDLE Signale und den Rest der gesendeten
Daten.
* FD konnte ich nicht sehen, das wird dann auch mit 0xfe überschrieben.
Also das sieht dann ungefähr so aus:
Wie kann das sein, dass die PCS Fehler einfügt?!
Irgendeinen Grund muss sie haben...
Werde jetzt mal IFG stark erhöhen.
Zumindest werde ich weniger axi Frames senden.
Das sollte ja der Parameter sein oder?
also mein ifg habe ich variabel gemacht und z.B. auf 255 extra Takte
eingestellt. Aber es kommt immer dieses Muster. Also das sieht meine ich
genauso aus wie wenn ich die Daten weiterleiten würde zu PHY2.
(Ich teste das mit einem kleinen Loopback weil es schneller geht.)
Loopback PHY nach nach Gearbox in PCS:
MAC kann die Daten so nicht lesen, weil die Präambel defekt ist.
hey vlt. braucht mein phy lane0 <-> lane0
für alignment/ sync in der PCS
vlt muss s = start auf einer bestimmten lane sein...
oder die ganze Nachricht einfach in einer reihenfolge sein ...
grade sind die lanes etwas vertauscht
VHDL hotline schrieb im Beitrag #7103793:
> Evtl. was mit unsauberen clocks/Domänenübergängen? Wenn das alles Xilinx> IP ist, kannst du es simulieren?
Clocks und Domänenübergänge: Gute Frage.
Der Leitungscode hat ja auch Taktinformationen.
Der PHY taktet unabhängig von MAC und XAUI.
Der PHY ist ein eigener Chip.
Ich denke er lässt sich nicht simulieren oder?
Der Rest schon. MAC, XAUI ( GTP Transceiver)
Vorteilhaft ist es dabei MAC und XAUI zu synthetisieren, da die GTP
Transceiver sehr viel Zeit zur Initialisierung benötigen.
Gestern habe ich (wie gesagt) meinen Loopback hinter die PCS des PHY1
gesetzt.
(Nach der Gearbox - diese ist dafür da die Daten in passender größe zur
PMA zu senden.)
Die Daten werden dann zurückgesendet.
Aber kommen nur bis zum Eingang von MAC1.
Dort sieht man, dass die Präambel mit Fehlern behaftet ist (XGMII).
* Wenn ich z.B. XAUI1 Ausgang zu Eingang mache, würde es funktionieren.
* Wenn ich im laufenden Design sogar vor der PCS ein loopback im PHY
mache geht es auch.
* Oder wenn ich die GTP Transceiver per configuration vector des
XAUI-Cores in Loopback-Modus schalte, im laufenden Design, geht es
auch.
Nur wenn ich diesen Loopback nach der PCS im PHY mache kommt dieser
Fehler.
Bzw. auch der PHY2 würde wahrscheinlich diese Fehler erhalten und sie
weiterleiten.
Da PHY2 vom gleichen Typ ist verhält er sich gleich.
D.h auch er müsste diese Fehler hinzufügen.
Auf jeden Fall habe ich diesen Fehler das erste mal gesehen als ich den
MAC2 Eingang beobachtet habe.
10G-R Ethernet:
1
//Failed loopback because of error around preamble observed @ MAC1 XGMII -entrance
Es kann sein, dass es an der lane order liegt.
die Verbindung PHY2<-> XAUI2 habe ich jetzt auch mal bei PHY1<-> XAUI1
angewandt, indem ich im xilinx xaui core wizard die lanes getauscht
habe.
Ich finde die Kombination aber etwas seltsam. habe sie mal im Anhang..
Sie scheint keine Fehler zu erzeugen...
Wenn ich einen bestimmten loopback einsetze und die falsche XAUI-Lane
order eingestellt habe ist die Präambel ebenfalls mit Fehlern behaftet.
Dazu habe ich eine Übersicht im Anhang.
Vielleicht habt ihr eine Idee...
Gommlon schrieb:> folgendes Design liegt mir vor:axi1(Rx)-> MAC1 -> XAUI1-> PHY1 ->
PHY2->XAUI2->MAC2 -> axi2(Rx)
> axi1(Rx)<-
axi1 und axi2 sind verschiedene FPGA, oder?
Klappt denn Loopback auf dem zweiten Gerät?
Duke
Duke Scarring schrieb:> axi1 und axi2 sind verschiedene FPGA, oder?> Klappt denn Loopback auf dem zweiten Gerät?
Ja genau axi1 ist auf Gerät1 und axi2 ist auf Gerät2
Der 10GEMAC hat nur AXI-Stream als Schnittstelle.
Beide Geräte sind theoretisch identisch.
Soweit ich das beobachtet habe funktioniert alles normal wenn die
lane-order korrekt ist.
D.h. ich kann die Loopbacks überall in jede Richtung setzen.
Habe mal ein weiteres Bild im Anhang, wo ein weiterer Testloopback
eingezeichnet ist. Vielleicht meinst du den.
Aktuell sieht es so aus, als wäre eine bestimmte lane-order notwendig
also XGXS<-(xaui)-> PHY .
Allerdings macht die von mir eingestellte lane-order keinen Sinn oder?
Trotzdem funktioniert sie.
PCB Beschriftung könnte aber auch falsch sein ( Wahrscheinlichkeit ist
gefühlt 30 %)
Moin,
Von 10G Ethernet hab ich keine Ahnung, aber so allgemein wuerde es mich
eher wundern, wenn die verschiedenen Lanes untereinander so einfach
getauscht werden koennten...
Steht das irgendwo explizit, dass die Lanes getauscht werden koennen?
Gommlon schrieb:> PCB Beschriftung könnte aber auch falsch sein ( Wahrscheinlichkeit ist> gefühlt 30 %)
Vielleicht mal das Gefuehl neu justieren... :-)
Gruss
WK
Dergute W. schrieb:> Steht das irgendwo explizit, dass die Lanes getauscht werden koennen?
im xaui wizard kann folgendes gemacht werden:
xgmii -> xgxs-core -> gtp channel
Zwischen xgxs-core und gtp-channel liegt ein Vektor.
Dieser verbindet die xgmii lanes mit gtp channels 0 bis 3.
Jede lane hat 16 Bit und einen 2 Bit Kontrollvektor.
(xgmii mit sdr = 64 Bit data und 8 Bit Kontrollvektor )
Jede sowohl lane0tx als auch lane0rx gehen zusammen zu einem gtp-channel
Jetzt bietet der wizard an die lane(n)tx / lane(n) rx an einen anderen
Channel (n) anzuschließen. n = 0...3
D.h. hier wird eigentlich nur der XGMII Vektor anders an die GTP
Transceiver weitergegeben. ( Beim Empfangen werden die GTP Ausgänge dann
eben anders auf den XGMII Vektor verteilt)
Die Transceiver sind selber fest-verdrahtet mit dem PHY.
Im Phy selber können die XAUI lanes sogar getauscht werden. Aber nur 0
mit 3 und 2 mit 1 ... also nicht so flexibel. Aber immerhin. Auch
separat für RX und TX
Dergute W. schrieb:> Vielleicht mal das Gefuehl neu justieren... :-)
Das wäre viel zu schlimm wenn dort ein Fehler drin ist.
Deswegen ist das meine aktuelle Schätzung.
Natürlich können immer Fehler passieren.
Thread beobachten
Seitenaufteilung abschalten