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!
Ein gut gezielter Reset reicht leider nicht. Die ISERDES sind oft aber nicht garantiert synchron. Du brauchst eine Synchronisation über den Datenstrom der ISERDES. Stichwort Comma Detection/Alignment.
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.
Andreas H. schrieb: > Ein gut gezielter Reset reicht leider nicht. Die ISERDES sind oft aber > nicht garantiert synchron. Du brauchst eine Synchronisation über den > Datenstrom der ISERDES. Stichwort Comma Detection/Alignment. Es geht auch ohne COMMA, zb wenn man LVDS ADC anbindet, da gibt es kein Comma!
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??
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.
:
Bearbeitet durch User
Antti L. schrieb: > Wie hilft dir die Frame Sync signal bit-slip logic zu implementieren?? Auch das Frame Signal kann man in den SerDes schieben und dann so lange bitslippen bis man "11..111000..00" erhält. Habe ich so bei einem ADC gemacht.
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!
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.
> 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??
Antti L. schrieb: > LESEN: Word alignment wird da mit training pattern gemacht. Hast du kein > training pattern dann pech gehabt! Es geht mir nur um das Bit/Phasealignment.
Gustl B. schrieb: > Antti L. schrieb: >> LESEN: Word alignment wird da mit training pattern gemacht. Hast du kein >> training pattern dann pech gehabt! > > Es geht mir nur um das Bit/Phasealignment. Ok, wenn du kein bit-slip brauchst, dann ja. Phasenabgleich ist schon möglich.
Aber wie wenn die SerDes nach dem Reset versetzt starten? Wenn das so ist wie ihr meine Eingangsfrage beantwortet habt, dann geht das Phasenalignment so wie es in dem verlinkten Whitepaper steht nicht.
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.