Hallo guten Tag,
von meinem IP Core gehen 16 Signale zu meinen MGT216 Transceiver.
Auf dem Schaltplan steht, man soll die Zuordnung und Polarität in der
FPGA-Konfig noch anpassen.
* Geht das oder sind die PADs direkt mit den Transceivern verbunden?
* Im Device Browser gehen die immer über eine Art Switch.
Aktuell ist die Konfiguration z.B.:
1
XTX0_3N-->(B11)MGTPRXP0_216-->GPE2_CHANNEL_X0Y4
Es müsste aber vermutlich z.B. folgendes sein:
1
XTX0_3N-->(B11)MGTPRXN3_216-->GPE2_CHANNEL_X0Y7
* Bei meinen ersten beiden Versuchen (*.xdc ändern / Signale in der
toplvl anders zuweisen) kamen identische/ähnliche critical warnings beim
Implementierungsschritt:
* Also bei dem PAD B11 wurde bereits etwas für C12 gesetzt?
* Außerdem kommt eine Meldung, dass OBUF nicht gesetzt werden kann.
* Das hatte ich bereit bei meiner Clock.
ah, da ich die transceiver nie einzeln instantiiert habe, sonder immer
durch meinen XAUI-Core, ist mir noch gar nicht die Idee gekommen die
Transceiver "einfach" anders an den XAUI anzuschließen.
Das hatten wir doch neulich hier schon. Du kannst, wenn dann überhaupt
nur die GTP Lanes innerhalb eines Quad verschieben. Die Polarität musst
du im IP Core einstellen, die GTP haben einen Parameter dafür. Ansonsten
stellst du doch auch für die Zuordnung zu den FPGA Pins alles über den
Core ein, oder? Also jedenfalls beim "nackten" MGT gebe ich da an,
welche(n) Transceiver ich nutzen will.
Christian R. schrieb:> Das hatten wir doch neulich hier schon.
Auf jeden Fall was mit Transceivern ... xD
Christian R. schrieb:> Die Polarität musst> du im IP Core einstellen, die GTP haben einen Parameter dafür.
* gibt im xaui ip core eine Einstellung zur änderungen der Lanes
* hier geht es aber nicht um ganze tx rx lanes sondern um einzelne
* man müsste das evtl. manuell erledigen:
* Wäre die Frage, ob das so einfach geht, weil der xaui-ip-core ein paar
Schaltungen dazwischen hat.
* Aber vielleicht muss ich mir nur die Zwischenstufen anschauen, ändern
und dann ist alles gut.
* Vielleicht aber auch einfach nicht.
>Ansonsten> stellst du doch auch für die Zuordnung zu den FPGA Pins alles über den> Core ein, oder?
* Ja genau nur dieses mal geht es nicht so einfach denke ich.
* Ich erhalte critical warnings.
* Entweder ich habe etwas einfaches übersehen, oder man kann die nicht
einfach so verbinden wie man will.
mehrrerer schrieb:> Ja genau nur dieses mal geht es nicht so einfach denke ich.> * Ich erhalte critical warnings.
Du stellst im Core ein, welche Lanes des/der Quad(s) er nutzen soll. Und
im ucf musst du gar nix extra angeben, denn das ist dann festgelegt. Die
MGT Pins sind ja dediziert, und da kann man quasi nicht abweichen. Im
anderen Thread schrieb einer, man könne die 4 Lanes innerhalb eines Quad
noch vertauschen, aber das hab ich nicht probiert. Ich nutze den
7-Series Transceiver wizzard, und da lege ich die Lanes fest, und die
sind dann so. UCF wird vom core geliefert.
Christian R. schrieb:> Du stellst im Core ein, welche Lanes des/der Quad(s) er nutzen soll.
* ich muss den Schaltplan noch mal genau checken
* Aber wenn da n und p und alle Nummerierungen durcheinander sind,
bringt das vlt. nicht mal was wenn ich die lanes abändere.
Ansonsten:
* xaui ip core hat die Option zum lanes wählen
* 7 series fpgas transceivers wizard schaue mich mir gerade an
Blicke da noch nicht ganz durch.
Schau mal ins Dokument UG482 rein, da ist in Appendix A das Placement
dargestellt. Es gibt nur genau diese eine Zuordnung der FPGA Balls zu
den Transceivern, da kann man nix ändern. "oberhalb" der Transceiver
kann man dann sicher viel swappen, aber das ist je nach Core mehr oder
weniger aufwendig. Bei lane bonding hat man da sicher weniger Spielraum
als bei 16 unabhängigen lanes.
Also ich muss das wirklich noch mal in Ruhe anschauen!
Vielleicht kann man doch einfach nur die lanes tauschen.
Glaube nur P und N müssen manchmal gedreht werden.
# Mist habe die Tabelle da oben zu schnell kopiert und original daten
überschrieben!
Also um nur ein Beispiel zu nehmen:
TX0_3_N/P geht zu RXP0/N0
Wenn ich jetzt die lanes tausche ist die zahl zwar korrekt aber P und N
bleiben verkehrt.
Also
TX0_3_N/P würde ich dann an RX3P/N legen können.
Sollte aber eigentlich an RX3N/P.
Muss mir das wie du sagst noch mal genau anschauen in den
Wizwardbeschreibungen!
OK.
Dann muss ich mal schauen, ob es da irgendeine Möglichkeit gibt die
Transceiver-Verbindung zu ändern...
1. Schritt: Transceiver Dokumentation
2. Design analysieren
3. Ändern
4. Testen
Das muss doch ein altbekanntes Thema sein oder?
Jeder möchte doch etwas mit transceivern senden.
Dann muss das doch lösbar sein xD
mehrrerer schrieb:> Das muss doch ein altbekanntes Thema sein oder?> Jeder möchte doch etwas mit transceivern senden.> Dann muss das doch lösbar sein xD
Naja, die meisten lesen die Doku und die Board Design Guidelines usw.
bevor sie die Platine machen. Klappt natürlich nicht immer, aber in
der Regel hat sich das bewährt
Christian R. schrieb:> mehrrerer schrieb:>> Das muss doch ein altbekanntes Thema sein oder?>> Jeder möchte doch etwas mit transceivern senden.>> Dann muss das doch lösbar sein xD>> Naja, die meisten lesen die Doku und die Board Design Guidelines usw.> bevor sie die Platine machen. Klappt natürlich nicht immer, aber in> der Regel hat sich das bewährt
Muss das wohl FPGA-Seitig lösen...
Interessant:
Habe das gerade gesehen in pg168:
Active-High signal to invert the polarity of the transmitter output.
Active-High signal inverts the polarity of the receive data signal.
TX/RX POLARITY wäre zu testen.
Müsste mal schauen ob es für den XAUI wichtig ist, ob PHY T1 zu XAUI T1
usw. geht.
Einfach mal in der Simulation testen/ Norm lesen.
leider nicht zwingend. Ich geh mal davon aus, dass im Transceiver für
XAUI u.U. spezielle Features für Channel Alignment etc. genutzt werden.
Da kann es durchaus sein, dass die Code-Wörter nicht auf allen Lanes
gleich sind. Wenn das in den Transceivern selber ausgewertet wird dann
macht es sehr wohl einen Unterschied, ob du die Lanes vertauscht hast.
Generell kannst du es aber mal versuchen.
P und N kannst du in der Tag über das Polarity leicht vertauschen und
funktioniert auch. Das ist gängige Praxis um das Layout besser zu
machen.
Wie sieht der Rest deiner Hardware aus? Passt dein Reference Clock? Habt
ihr ein Auge auf die Spannungsversorgung geworfen?
Bei Transceiver kann sich schnell ein Fehler einschleichen, so dass dann
gar nichts mehr funktioniert ...
tja schrieb:> Da kann es durchaus sein, dass die Code-Wörter nicht auf allen Lanes> gleich sind. Wenn das in den Transceivern selber ausgewertet wird dann> macht es sehr wohl einen Unterschied, ob du die Lanes vertauscht hast.
* ja dafür muss ich mir den Core anschauen und nachvollziehen. Der
beinhaltet den kodierten XAUI und die Wrapper um die Transceiver.
* XAUI-Core sendet dabei (denke ich) seine XAUI-Lanes über einen 64-Bit
Vektor.
Ein Versuch wäre es, diesen Vektor in seiner Reihenfolge zu ändern.
* denke ich muss nachvollziehen wie man normalerweise mit den
Transceivern arbeitet.
* ->Wie generell Input und Output verbinden
* -> welche Signale/ Handshakes sind notwendig
tja schrieb:> Generell kannst du es aber mal versuchen.
Ja hoffe, dass ich ein paar Daten -und Steuer Signale identifizieren
kann und dann neu verbinden kann.
tja schrieb:> P und N kannst du in der Tag über das Polarity leicht vertauschen und> funktioniert auch. Das ist gängige Praxis um das Layout besser zu> machen.
Wenn ich das schon so leicht gefunden habe, muss das andere auch so
leicht sein.
tja schrieb:> Wie sieht der Rest deiner Hardware aus? Passt dein Reference Clock? Habt> ihr ein Auge auf die Spannungsversorgung geworfen?
### Rest Hardware
- A7 200t, will nur Daten über meinen XAUI an meinen PHY senden^^
- vielleicht auch einen anderen XAUI core nehmen.. oder Testdaten
anders generieren xD
### Spannungsversorgung
- FPGA-Designs auf dem Board liefen stabil
### Reference Clock
- Referenz Clock dclk 50 MHz für die Transceiver und ist unabhängig von
den 156,25 MHz
Vielen Dank für deine Tipps!
:D
Habe eine interessante Stelle gefunden. Habe die Datei auch im Anhang...
xaui_0_block.vhd
Was denkt ihr darüber?
Kann ich etwa damit schon die gewünschte Änderung herbauführen.
Und dann noch "mgt_txcharisk" korrekt legen
Hmm,
(ich weiß nicht ob ich einen neuen Thread eröffnen soll für weiteres)
Also ich habe mir noch mal die fest-verdrahtete Konfiguration angeschaut
und überlegt, ob ich wenigsten einen XAUI-> PHY -> PC Sende-Test
hinbekomme.
Dafür würde ich mich nur auf die XAUI-TX lanes konzentrieren...
Vielleicht klappt das.
Zuerst habe ich die lanes alle so angeordnet, dass XAUI TXn (OUT) mit
PHY RXn (IN) verbunden ist.
Dann habe ich mir angeschaut welche Polaritäten vertauscht sind und habe
die entsprechenden polarities geändert.
Hier tausche ich rx ( auch wenn ich es gerade nicht testen will)
jetzt ist mein Status-vektor und mein debug-vektor noch nicht so wie er
sein sollte!
Möglicherweise etwas mit den TX Einheiten.
>status_vector= 0xfd = 0b1111 1101
Der sollte eigentlich
den Wert = 0xfc = 0b1111 1100 haben!
TX Local fault ist hierbei das LSB!
>debug = 0x3e = 0b 11 1110
der sollte eigentlich 0x3f = 0b11 1111 sein!
"Indicates when the TX phase alignment of the transceiver has been
completed"
Im einfachsten Fall habe ich einfach die dclk= 50 MHz falsch verbunden.
Ich habe einen Frame-Sender der ein Ethernet-Frame senden soll.
Aber es kommt nichts am PC an.
Ich schaue mir das per wireshark an...
Aus irgendeinem Grund scheinen auf Rx manchaml Daten zu kommen, Daten
versuche zu senden und dabei einen PHY loopback drinne habe.
Generell wird empfohlen XAUI loopback mit sich selber zu machen um zu
schauen, ob er sich richtig initialisiert.
Habe dclk von einem anderen FPGA und wandle dann diese ca. 100 MHz in 50
MHz. um. Allgemien erscheinen dadurch zeitkritische Fehler.
DCLK muss aber nicht zwingend 50 MHz sein.
Könnte die 100 MHz auch quasi "direkt" verwenden.
Werde das mal testen...
habe gerade reset manuell mit dem vio core ein reset im betrieb
durchgeführt.. jetzt ist der status vector korrekt und der debug vektor
auch. also so wie in der simulation.
Es blinkt jetzt zwar die LED an der Netzwerkkarte aber ich kann keine
meiner generierten Daten sehen.
Es geht aus wireshark nicht wirklich hervor, dass es meine generierten
Daten sind. Eher sowas wie eine Reaktion darauf, dass der fpga etwas
sendet.
Ich muss ggfs. die GTP Transceiver richtig resetten. Aber es steht nur
sehr vage wie das gehen soll.
Ich habe mal einen meiner Prototypen an einen anderen angeschlossen.
Der eine hatte eine "gute" TX konfiguration, der andere eine gute RX-
Konfiguration.
Zumindest denke ich, dass ich die lanes entsprechend gut gelegt habe.
Ich sehe jetzt sogar, dass da was ankommt.
Aber es gibt sehr viele Fehler daszwischen!
Als ob die lanes vertauscht wären.
Aber das kann nicht sein.
Ich habe doch darauf geachtet, dass bei dem einen Design korrekt für TX
zu machen und bei dem anderen korrekt für RX.
...
Mein PC reagiert nur instant mit der LED an der Netzwerkkarte.
Aber es werden keine Daten erkannt.
Der MAC verwirft das wohl.
Ich habe nämlich auch bei meinem RX Prototyp gesehen, dass meine MAC die
Daten nicht hinten wieder ausgibt!
So verhält sich wohl auch meine Netzwerkkarte.
Die sieht zwar was, kann aber nichts damit anfangen...
mehrerer schrieb:> Mein PC reagiert nur instant mit der LED an der Netzwerkkarte.> Aber es werden keine Daten erkannt.>> Der MAC verwirft das wohl.
Dann versuch doch mal den umgekehrten Weg: Sende permanent Pakete mit
bekanntem Inhalt. Auf der Gegenseite kannst Du dann alles an debugging
machen, was Dir zur Verfügung steht: Oszilloskop, Logicanalyzer,
Chipscope, ...
Duke
habe schon versucht was über den Ethernet Port an meinen Prototypen zu
senden.
Mit Mausezahn.
Habe da letztes mal noch nicht so viel erkannt.
Muss ich noch mal testen - weiß nicht genau was ich da als test senden
sollte.
Aber prototyp1 -> prototyp2 teste ich gerade wieder!
Es sieht gar nicht soo schlecht aus.
Obwohl ich gerade alle RX Kombinationen durchteste erhalte ich immer ein
paar richtige Werte.
Allerdings sollte es ein anderes Format haben:
0000535400005556
aber es sollte so sein:
0053005400550056
Habe im Anhang noch mal ein Bild von meinem Versuchsaufbau ....
Habe noch keinen "rxnotintable" Fehler gesehen bis her.
Deswegen liegt es vielleicht nur an der Lane-order.
bei der Kombiantion RX ( einstellbar im XAUI wizard)
sah es schon leicht besser aus.
Aber noch nicht perfekt.
1
1
2
0
3
2
4
3
Ich glaube es gibt 16 Möglichkeiten wie ich den XAUI wizard einstellen
kann für meinen RX Prototypen...
Das ist echt anstrengend ich muss immer wieder ein neues Bitfile in
Vivado erstellen, um das zu testen!
chipskope?
also ich verwende ILA und VIO
...
ILA ist sehr wichtig, da ich damit xgmii anschaue..
und eben xgmii sollte anders aussehen.
Nämlich so wie beim Senden.
Also wie oben beschrieben..
leider stimmt die Reihenfolge nicht.
Habe jetzt schon 8 Kombinationen durch.
gut habe jetzt mindestens 24 Mal die Konfiguration umgestellt und davon
ein Bitfile generiert um es zu testen.
Immer was irgendwas falsch mit der Reihenfolge oder es gab
Invertierungen.
Obwohl ich immer wieder den Schaltplan prüfe..
Wie soll man die GTP Reihenfolge bloß debuggen!?
werde jetzt mal schauen, ob ich während der Laufzeit die polarites
ändern kann, damit ich wenigstens ein bisschen schneller debuggen
kann...
Weil es erscheinen momentan einige inverse Zeichen....
haha das scheint ja echt zu gehen,
einfach ein vector wo ich die bits ändern kann xD
also aktuell sieht mein versuchsaufbau so aus:
device1 mit TX GTP -> device2 mit RXGTP wo ich mit dem wizard die lanes
tauschen muss aber jetzt wenigstens die polarities im Betrieb ändern
kann .
mehererer schrieb:> gut habe jetzt mindestens 24 Mal die Konfiguration umgestellt und> davon> ein Bitfile generiert um es zu testen.> Immer was irgendwas falsch mit der Reihenfolge oder es gab> Invertierungen.>> Obwohl ich immer wieder den Schaltplan prüfe..>> Wie soll man die GTP Reihenfolge bloß debuggen!?
Sowas kenne ich beim Artix MGT wenn der Reset nicht lang genug und/oder
nicht wie gewünscht synchron ist. Beim MGT Startup und Reset hat man
beim Artix insbesondere viel Spaß durch den Silicon bug. Außerdem
sollte/muss man immer noch nach dem Startup eine Weile warten, bis man
anfängt die MGT zu starten, das hängt bissl vom Board ab, vom REF_CLK
und allen möglichen anderen Dingen...
Was für ein Silikon Bug?
Konnte jetzt durch VIO-Togglen der polarity-order der RX lanes der GTP
transceiver, die bei der XAUI-Entity ausgeführt sind die getoggelten
Zeichen klar machen.
Durch eine weitere Umstellung im XAUI lane Wizard habe ich dann gestern
die Richtige lesbare Reihenfolge an Daten, die ich mit meinem anderen
Gerät gesendet habe empfangen!
Mein MAC übersetzt das empfangene noch nicht.
Währe natürlich vollständigkeitshalber schön.
Werde mal meine Testbench bemühen.
Oder/ Und am Ende wieder VIO verwenden um den Ethernettyp live zu ändern
xD.
Kontne außerdem auch mal mit dem Programm
https://man7.org/linux/man-pages/man8/mausezahn.8.html etwas an mein
device senden.
Allerdings konnte ich noch nichts an meinen PC senden.
Eigentlich müsste man doch wenigstens Rohdaten sehen können ...
Habe es noch mit keinem Programm geschafft..
mehererer schrieb:> Eigentlich müsste man doch wenigstens Rohdaten sehen können ...> Habe es noch mit keinem Programm geschafft..
Wireshark + Administratorrechte + Promiscous mode + alle Checksum
Offloadings ausschalten (Einstellungen Netzwerkkarte)
Sonst bekommst du nur ausgewählte Netzwerkpakete präsentiert.
Duke
Thread beobachten
Seitenaufteilung abschalten