Reset mehrerer ISERDESE3

OP #7869519
Lesenswert?

Hallo zusammen,

wenn ich mehrere ISERDESE3 habe die schön neben einander sitzen, gleich Takt, Daten, Reset bekommen, geben die nach einem Reset (der ja asynchron ist) garantiert die gleichen Wörter aus (beginnen die Deserialisierung mit dem gleichen Bit)?

Die Frage zieht darauf ob ich zwingend einen Bitslip brauche oder ein gut gezielter Reset zum richtigen Zeitpunkt reicht.

Vielen Dank!

OP #7869571
Lesenswert?

Mir ist klar wir man das richtig macht.

Mir geht es um https://docs.amd.com/v/u/en-US/wp249 dort werden die Wörter aus zwei SerDes für dynamischen Phasenabgleich verglichen. Aber wie kann das funktionieren wenn nach dem Reset gleich einer der SerDes um ein/mehrere Bits versetzt arbeitet?

Wird da vor dem Phasenabgleich schon ein Wordalignment mit Bitslip gemacht? In dem Dokument nicht.

Man müsste die beiden Bits aus den IDELAYs vergleichen. Ist aber eben höhere Frequenz und das wird dann in irgendeine LUT geroutet, man muss also auch die Routingdelays gleich halten zum Komparator.

#7869653
Lesenswert?

Gustl B. schrieb:

Mir ist klar wir man das richtig macht.

Mir geht es um https://docs.amd.com/v/u/en-US/wp249 dort werden die Wörter aus zwei SerDes für dynamischen Phasenabgleich verglichen. Aber wie kann das funktionieren wenn nach dem Reset gleich einer der SerDes um ein/mehrere Bits versetzt arbeitet?

Wird da vor dem Phasenabgleich schon ein Wordalignment mit Bitslip gemacht? In dem Dokument nicht.

LESEN: Word alignment wird da mit training pattern gemacht. Hast du kein training pattern dann pech gehabt!

#7869654
Lesenswert?

Antti L. schrieb:

Christian R. schrieb:

Die ISERDES2 am Artix kommen auch nicht garantiert gleich aus dem Reset. Da braucht man schon das Bit-Slip. Ist ja aber auch kein Hexenwerk, ADCs usw liefern ja das FRAME Sync Signal in der Regel mit.

Interessant! Wie hilft dir die Frame Sync signal bit-slip logic zu implementieren??

Indem ich das wie ein Datensignale behandle und ebenfalls über ISERDES einlese. Dann solange die im Beispielcode befindliche Bitslip Logik laufen lassen, bis das "Pattern" des Frame Sync erreicht ist. Bei einem 16 Bit ADC oder einem ADC mit 16 Bit Wortbreite am Ausgang wäre das dann das Muster 0xFF00 oder 0x00FF je nachdem wie rum die Daten raus fallen. Nur mit dem Reset alleine ist das nicht sicher, mit dem Frame Sync per Bit Slip schon. Aber die Quelle muss das natürlich liefern, klar.

#7869655
Lesenswert?

Indem ich das wie ein Datensignale behandle und ebenfalls über ISERDES einlese. Dann solange die im Beispielcode befindliche Bitslip Logik laufen lassen, bis das "Pattern" des Frame Sync erreicht ist. Bei einem 16 Bit ADC oder einem ADC mit 16 Bit Wortbreite am Ausgang wäre das dann das Muster 0xFF00 oder 0x00FF je nachdem wie rum die Daten raus fallen. Nur mit dem Reset alleine ist das nicht sicher, mit dem Frame Sync per Bit Slip schon. Aber die Quelle muss das natürlich liefern, klar.

Ja wirklich? Frame und Alle datenleitungen resetten unterschiedlich und starten mit anderen bit positionen, und jetzt liest du Frame sync raus und machst was mit den anderen datenleitungen??

OP #7869672
Lesenswert?

Und siehe da, ISERDESE2 und ISERDESE3 haben einen unterschiedlichen Reset. UG953 https://docs.amd.com/r/en-US/ug953-vivado-7series-libraries/ISERDESE2

The reset input causes the outputs of all data flip-flops in the CLK and CLKDIV domains to be driven low asynchronously. ISERDESE2 circuits running in the CLK domain where timing is critical use an internal, dedicated circuit to retime the RST input to produce a reset signal synchronous to the CLK domain. Similarly, there is a dedicated circuit to retime the RST input to produce a reset signal synchronous to the CLKDIV domain. Because the ISERDESE2 is driven into reset asynchronously but comes out of reset synchronously it must be treated as a synchronous reset to the CLKDIV time domain and have a minimum pulse of one CLKDIV cycle. When building an interface consisting of multiple ISERDESE2 ports, all ISERDESE2 ports in the interface must be synchronized. The internal retiming of the RST input is designed so that all ISERDESE2 blocks that receive the same reset pulse come out of reset synchronized with one another.

Während beim UG974 https://docs.amd.com/r/en-US/ug974-vivado-ultrascale-libraries/ISERDESE3

Asynchronous Reset, active level based on IS_RST_INVERTED.

Dabei steht. Also das aus dem verlinkten Whitepaper wird mit ISERDESE3 nicht funktionieren.

#7869682
Lesenswert?

Antti L. schrieb:

Ja wirklich? Frame und Alle datenleitungen resetten unterschiedlich und starten mit anderen bit positionen, und jetzt liest du Frame sync raus und machst was mit den anderen datenleitungen??

Argh, stimmt, Kurzschluss im Kopf. Sorry. Nee, beim ISERDES2 kommen die am gleichen Reset schon gleich raus (steht ja jetzt auch hier). Ich war gedanklich an einer anderen Stelle, nämlich an dem Teiler des BUFR, der mir im Zusammenhang mit dem Reset und dem ISERDES mal Probleme gemacht hatte.

(Firma: Starfleet) #7869896
Lesenswert?

Es steht in mehreren User Guides - UG???, das und wie sich die SERDES in der Baureihe Ultrascale+ von denen der Vorgänger-Baureihen unterscheiden.

Das es in mehreren verschiedenen UG steht, iritiert, als ob es innerhalb der US+ noch Unterschiede gäbe, bspw. zum Spartan 7 US+. Vielleicht wäre es besser gewesen, Xilinx hatte weiter nummeriert statt mit Ultrascale und + lediglich die Strukturbreite als Vermarktungsinstrument zu benutzen. Aber wenn halt Ingenieure das Marketing übernehmen ...

Der TO hat den konkreten Chip noch nicht genannt - man geht davon aus, das es ein beliebiger (Artix, Kintex, Virtex, Zynq, Spartan) aus der US+ Familie sein soll.

Der Auszug oben ist aus UG861 (Spartan US+): https://docs.amd.com/r/en-US/ug861-ultrascale-selectio/ISERDESE3

wenn ich mehrere ISERDESE3 habe die schön neben einander sitzen

Dunkel erinnere ich mich an Channel-Bonding, das ist aber nicht das, was man hier vorhat ?! https://docs.amd.com/r/en-US/am002-versal-gty-transceivers/Using-RX-Channel-Bonding

(" Clock Correction and Channel Bonding: Allows for correction of the difference between the transmit clock and the receive clock. Also allows for skew correction between multiple channels. (Channel bonding is optional and not always included in SERDES.")

Auszug zum "channel bonding" aus: https://www.xilinx.com/publications/archives/books/serialio.pdf

Angehängte Dateien:
OP #7869936
Lesenswert?

Es geht mir nur um das Resetverhalten.

Es geht mir nur um den ISERDESE3.

Es geht mir um die Anwendung die im verlinkten Whitepaper beschrieben ist. Und dort nur um das Phasealignment mit zwei dieser ISERDESE3 in Kombination mit den IDELAYE3.

Ich dachte ich hätte mich bisher klar ausgedrückt. Wordalignment und Channelbonding interessiert mich nicht. Das ist einfach wenn man das Phasealignment gemacht hat und ein Trainingspattern und Sync Wort kennt.

Es geht mir wirklich nur um das automatische Phasealignment. Also das verschieben der Daten damit schön im Auge abgetastet wird.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren