Konfigurieren eines GTXE2-Transceivers der 7er-Serie für Serial-ATA (Gen1/2/3)

Hallo, dies wird eine Expertenfrage sein :) Sie sollten mit den folgenden Themen vertraut sein

  • Xilinx Multi-Gigabit-Transceiver (MGTs), insbesondere die GTX/GTH-Transceiver der 7er-Serie (GTXE2_CHANNEL)
  • Serial-ATA Gen1, Gen2 und Gen3, insbesondere Out-of-Band (OOB)-Kommunikation

Frage:

Wie sollte eine GTXE2 für Serial-ATA konfiguriert werden?

Die OOB-Signalisierung funktioniert nicht, weder RX_ElectricalIdle noch ComInit.

Einführung:

Ich habe für mein letztes Bachelor-Projekt einen SATA-Controller implementiert, der mehrere Hersteller-/Geräteplattformen unterstützt (Xilinx Virtex-5, Altera Stratix II, Altera Stratix IV). Jetzt ist es an der Zeit, diesen Controller auf die nächste Gerätefamilie zu portieren: Geräte der Xilinx 7-Serie, namentlich ein Kintex-7 auf einem KC705-Board.

Der SATA-Controller verfügt über eine zusätzliche Abstraktionsschicht im Physical Layer, die auf SAPIS und PIPE 3.0 basiert. Um den SATA-Controller auf eine neue Gerätefamilie zu portieren, muss ich also nur einen neuen Transceiver-Wrapper für einen GTXE2 MGT schreiben.

Da der CoreGenerator von Xilinx die SATA-Protokolle im CoreGen-Assistenten nicht unterstützt, habe ich ein Transceiver-Projekt von Grund auf neu gestartet und alle erforderlichen Einstellungen vorgenommen, soweit sie vom Assistenten abgefragt werden. Danach kopierte ich die GTXE2_COMMON-Instanziierung in mein Wrapper-Modul, ordnete die Generika und Ports in ein sinnvolles vollständiges Schema.

Als dritten Schritt habe ich alle nicht verbundenen Ports (die Assistenten weisen nicht alle Werte zu !!) auf ihre Standardwerte (die Standardwerte von UG476 oder Null, wenn nicht definiert) verbunden.

In Schritt 4 habe ich nochmal alle Generics und Ports gegen das UG476 auf Kompatibilität zu den SATA Einstellungen überprüft. Danach habe ich meine Wrapper-Ports mit dem MGT verbunden und ggf. Cross-Clock-Module eingefügt.

Da das KC705-Board keinen 150-MHz-Referenztakt hat, programmiere ich das Si570 so, dass es diesen Takt als "ProgUser_Clock" nach jedem "Bootup" des Boards liefert. Während dieser Neukonfiguration befindet sich das MGT im Powerdown-Modus (P2). Wenn der Si570 stabil ist, wird das MGT eingeschaltet, die verwendete Kanal-PLL (CPLL) sperrt nach ca. 6180 Taktzyklen. Diese CPLL_Locked-Ereignisse geben die GTX_TX|RX_Reset-Leitungen frei, die nach weiteren 270|1760 Zyklen (alle Zyklen bei 150 MHz -> 6,6 ns) ein GTX_TX|RX_ResetDone-Ereignis verursachen.

Dieses Verhalten ist im Chipscope zu sehen, aufgenommen mit einem stabilen, unterbrechungsfreien Hilfstakt (200 MHz, leicht überabgetastet).

Das GXTE2 scheint also eingeschaltet und betriebsbereit zu sein und alle Uhren sind stabil.

GTXE2-Ports zur Steuerung der OOB-Signalisierung:

Das MGT hat mehrere Ports für die OOB-Signalisierung. Bei TX sind dies:

  • TX_ElectricalIdle – zwingt TX in einen elektrischen Leerlaufzustand
  • TX_ComInit - sendet eine ComInit-Sequenz
  • TX_ComWake – sendet eine ComWake-Sequenz
  • TX_ComFinish - Sequenz wurde gesendet -> bereit für nächsten Befehl

Auf RX:

  • RX_ElectricalIdle - RX_n/TX_p befinden sich im elektrischen Ruhezustand (Low-Level-Schnittstelle)
  • RX_ComInit_Detected - Eine vollständige ComInit-Sequenz wurde gesendet
  • RX_ComWake_Detected - Eine vollständige ComWake-Sequenz wurde gesendet

Detaillierte Fehlerbeschreibung:

  1. TX sendet keine OOB-Sequenzen, wenn TX_ComInit für einen Zyklus hoch ist.
  2. RX_ElectricalIdle ist immer hoch

Tests:

  1. SATA-Loopback-Kabel: Schneiden Sie ein SATA-Kabel und löten Sie die entsprechenden Drähte ;) -- Ich verwende einen speziellen SFP-zu-SATA-Adapter, der den KC705 um einen SATA-Anschluss erweitert - http://shop.trioflex.ee/product.php ?id_product=73
  2. SMA-Loopback-Kabel: Ich habe das MGT verschoben und die LVDS-Kabel mit den SMA-Buchsen verbunden und 2 SMA-Kabel als Crossover installiert.
  3. Ich habe meinen alten ML505 (Virtex-5) mit Onboard-SATA-Anschluss so programmiert, dass er ComInit-Sequenzen sendet. Die 2 Platinen werden mit einem speziellen SATA-Crossover-Kabel verbunden.
  4. Ich habe eine Festplatte mit einem teilweise abisolierten SATA-Kabel an den KC705 (SFP2SATA-Adapter) und ein 2,5-GSps-Oszilloskop angeschlossen (ja, die Signale sind unterabgetastet, aber es ist gut, Bursts und Leerlaufzeiten zu sehen ...).

Erfahrungen:

  • Test 3 zeigt übertragene OOB-Sequenzen von Virtex-5 zu Kintex-7, aber das ChipScope-Trigger-Ereignis tritt nicht auf – Rx_ElectricalIdle ist immer noch hoch.
  • Test 4 zeigt keine übertragenen OOB-Sequenzen auf dem Kabel.

Soll ich Teile oder die komplette Transceiver-Instanziierung posten?

nur die Instanz hat ca. 650 Zeilen :(

Anhang:

Elektrischer Leerlauf bedeutet, dass das MGT beide LVDS-Leitungen (TX_n/TX_p) mit einer Gleichtaktspannung (V_cm) ansteuert, die im Bereich von 0 bis 2000 mV liegt. Wenn diese Bedingung erfüllt ist, beträgt die Gleichtakt-Dreieckspannung weniger als 100 mV, was als ElectricalIdle-Zustand bezeichnet wird.

OOB-Signalisierung bedeutet, dass das MGT Bursts elektrischer Leerlauf- und normaler Datensymbole (D10.2 in 8b/10b-Notation) auf den LVDS-Leitungen überträgt. SATA/SAS definiert 3 OOB-Sequenzen mit den Aufrufen ComInit, ComWake, ComSAS, die unterschiedliche Burst-/Leerlaufzeiten haben. Host-Controller und Geräte verwenden diese "Morse-Signale", um eine Verbindung herzustellen.

Bearbeiten 1:

Nachdem ich Common Voltage Trim (RX_CM_TRIM) und (Differential Swing Control) TXDIFFCTRL auf Maxima gesetzt und TX_ElectricalIDLE und TX_ComInit mit Drucktasten verbunden hatte, konnte ich einige kleine Ergebnisse sehen:

  1. TX_ElectricalIDLE funktioniert, aber der TX OOB FSM nicht (TX_ComInit, TX_ComWake)
  2. wenn TX_ComInit für immer hoch ist, sendet der Transceiver ALIGN-Primitive, aber mit einem Viertel des korrekten Takts, etwa 375 MHz statt 1,5 GHz
  3. RX_Electrical IDLE funktioniert immer noch nicht

Ich habe auch versucht, die alternative OOB-Uhr zu verwenden, aber dies hat keine Auswirkung.

Haben Sie AR# 53364 gesehen ?
Ja, ich kenne dieses AR :) Es bietet nur verschiedene CDR-Tuning-Parameter zur Unterstützung von SSC. Ab sofort verwende ich in meinen Tests SATA Gen1 und habe den entsprechenden Parameter aus dieser Liste zugewiesen. Soweit ich sehen kann, funktionieren Bit-Synchronisation, Komma-Erkennung und Byte-Ausrichtung in den Loopback-Tests. Aber die CDR-Einheit ist weit hinter der OOB-Schaltung, was mein aktuelles Problem ist :) Parallel zu dieser Frage schreibe ich eine Simulation:testbench <=> phy-layer <=> GTXE2 <=> GTXE2 <=> phy-layer <=> testbench
Dies ist eine sehr gut erklärte Frage, obwohl sie selbst für Benutzer, die Erfahrung mit dieser Art von Technologie haben, hochspezialisiert ist. Ich würde vorschlagen, sich nicht ausschließlich auf diese Seite zu verlassen, um eine Antwort zu erhalten. Während einer vorbeikommen kann, würde ich auch vorschlagen, an ein paar anderen Orten zu fragen, um sicherzustellen, dass Sie Hilfe bekommen.
@Funkyguy Hallo, ja ich habe diese Frage an mehreren Stellen gepostet und versuche gerade Zugang zu Xilinx Webcases zu bekommen. Ich versuche auch, ein 20-GHz-Oszilloskop an der Universität zu finden :)

Antworten (1)

Ich glaube, ich habe einige Antworten auf das Problem gefunden und möchte sie teilen.

Ich habe begonnen, das Hardmakro GTXE2_CHANNEL zu simulieren. Die Simulation verhält sich genauso "falsch" wie die Hardware. Also habe ich versucht, das MGT in Verilog zu simulieren und eine Instanzvorlage von hier verwendet: http://forums.xilinx.com/t5/7-Series-FPGAs/Using-v7gtx-as-sata-host-PHY-and-there -is-issue-bout-ALIGN/td-p/374203

Diese Vorlage simuliert ElectricalIDLE-Bedingungen und OOB-Sequenzen nahezu korrekt. Also fing ich an, beide Lösungen zu unterscheiden:

  1. TXPDELECIDLMODE, ein Port zur Auswahl des Verhaltens von TXElectricalIDLE, funktioniert nicht wie erwartet. Also benutze ich jetzt den synchronen Modus.

  2. PCS_RSVD_ATTR ist ein nicht eingeschränkter bit_vector-Generic von 48 Bit. Wenn Sie sich den Wrapper-Code der Secureip GTXE2_CHANNEL-Komponente ansehen, finden Sie eine Konvertierung von bit_vector => std_logic_vector => string. Intern werden alle Generika als DOWNTO-Range behandelt. Daher ist es wichtig, eine DOWNTO-Konstante an die GTXE2-Generika zu übergeben!

Jetzt könnten Sie also fragen, warum er Konstanten und Generika mit to-Bereichen verwendet?

Xilinx ISE bis zur neuesten Version 14.7 hat einen großen Fehler bei der Handhabung von Vektoren benutzerdefinierter Typen in uneingeschränkten Generika. Die Standardrichtung von Vektoren ist TO. Wenn Sie Aufzählungsvektoren als DOWNTO an unbeschränkte Generika in eine Komponente übergeben, kehrt ISE die Vektorelemente um und "gibt" einen TO-Bereichsvektor in den Komponenten aus !!

Dies ist besonders "lustig", wenn die Designhierarchie, die dieses Generikum verwendet, kein ausgewogener Baum ist ...

Wenn Sie Aufzählungen von 2 Elementen verwenden, besteht das Problem nicht -> möglicherweise ist diese Aufzählung einem booleschen Wert zugeordnet.

Welche Bugs sind übrig?

  1. TXComFinish bestätigt immer noch nicht die gesendeten OOB-Sequenzen.
  2. Ich muss diese beiden Bugfixes in Synthese untersuchen und die OOB-Sequenzen mit einem Scope messen - das kann einige Tage dauern :)

Bearbeiten 1 - weitere Fehler:

Einen weiteren Bug gibt es im Reset-Verhalten der GTXE2. Wenn GTXE2 mit Ausgangstaktteilern verwendet wird, die auf 1 gesetzt sind (TX_ und RX_RateSelection = "000"), dann bootet die GTXE2 und gibt nur 3 Taktzyklen (mit falscher Taktperiode) auf TX_OutClock aus. Danach ist TX_OutClock 'X'. Wenn Sie die GTXE2 nach dieser falschen Ausgabe zurücksetzen, bootet sie ein zweites Mal mit jetzt Fehler und einer korrekten Uhr auf TX_OutClock.

Zusätzlich zu diesem Fehler ignoriert das GXTE2 alle zugewiesenen Resets (CPLL sowie TX/RX_RESETs), bis 'X' auf TX_OutClock zu sehen ist. Sie MÜSSEN also ca. 2,5 uns warten, um einen Reset durchzuführen.

Wenn Sie Taktteiler mit 2 oder 4 verwenden (8 und 16 sind noch nicht getestet), tritt dieses Problem nicht auf.

Edit 2 - Probleme gelöst:

Lösung für Fehler 1:

Ich habe einen Timeout-Zähler hinzugefügt, dessen Timeout von der aktuellen Generation (Taktfrequenz) und der aktuellen zu sendenden COM-Sequenz abhängt. Wenn das Timeout erreicht ist, erzeuge ich mein eigenes TXComFinished-Signal. Nicht oder das Timeout-Signal mit dem ursprünglichen TXComFinished-Signal von GTX, da dieses Signal manchmal hoch ist, während COMWAKE gesendet werden soll, aber dieser fertige Strobe gehört immer noch zur vorherigen COMRESET-Sequenz!

Lösung für einen anderen Bug:

RXElectricalIDLE ist nicht störungsfrei! Um dieses Problem zu lösen, habe ich diesem Kabel ein Filterelement hinzugefügt, das Spitzen auf dieser Leitung unterdrückt.

Derzeit läuft mein Controller mit SATA Gen1 mit 1,5 GHz auf einem KC705-Board mit einem SFP2SATA-Adapter, und ich denke, diese Frage ist gelöst.

Es scheint ein Problem mit der CDR-Schaltung zu geben, die den Takt von modernen Geräten nicht wiederherstellen kann, wenn diese Spread-Spectrum-Clocking (SSC) verwenden. Die bereitgestellten RX_CDR_CFG-Werte von Xilinx für SSC-fähige Geräte bei 1,5, 3,0 und 6,0 ​​GHz funktionieren nicht. Das Fehlermuster zeigt 3 korrekte Datenwörter und dann ein beschädigtes Datenwort mit Bitverschiebungen und/oder Flips. Dieses Muster ist bei 140 kHz periodisch.
Ich habe eine Lösung für das CDR-Konfigurationsproblem gefunden. Der Trick ist die richtige Steuerung von RX_CDR_HOLD, die weder dokumentiert noch mit den Beispieldesigns des Assistenten verbunden ist!
Konfigurieren eines GTXE2-Transceivers der 7er-Serie für Serial-ATA (Gen1/2/3)
AntwortenHierDatenschutz-Bestimmungen1y, 0v