Hallo Zusammen, ich will eine Serdes Verbindung zwischen zwei Spartan 6 aufbauen, die Daten mit 4b/5b überträgt. Wenn ich über den Core-Generator die Eingangsseite über ein SelectIO Interface erstelle, wird intern eine Art Frame-Signal für die 5 Bit breiten Datenpakete durch einen BUFIO2, der durch 5 teilt, erstellt. Hinter dem SelectIO/Serdes würde ich nun einen 4b/5b decoder setzen. Was ist aber, wenn im Fehlerfall der Eingang z.B. am Takteingang eine "Extraflanke" sieht oder eine Flanke übersieht - ab dem Moment würden alle 4b/5b Datenpakete Empfängerseitig ein Bit verschoben und komplett falsch ankommen. Habe ich da einen Denkfehler und wenn nein, wie fängt man sowas ab? Danke und viele Grüße Achim
Du musst Dein Signal entweder über-abtasten oder mit einem externen Baustein den Takt aus dem Datenstrom zurückgewinnen.
>Serdes Verbindung zwischen zwei Spartan 6 aufbauen, die Daten mit 4b/5b
Wird hier nicht standardmäßig 8b10b verwendet?
pks schrieb: > Du musst Dein Signal entweder über-abtasten oder mit einem externen > Baustein den Takt aus dem Datenstrom zurückgewinnen. Den Takt will ich mit übertragen, also Clock und Daten getrennt - in dem Fall kann ich mir die Taktrückgewinnung sparen. 8b/10b wäre auch eine Möglichkeit, da stoße ich aber 1. an die Grenzen der Breite des SelectIOs mit SDR und 2. brauche ich es eigentlich nicht, da ich wie oben beschrieben keine Taktrückgewinnung mache.
Achim schrieb: > Den Takt will ich mit übertragen, also Clock und Daten getrennt - in dem > Fall kann ich mir die Taktrückgewinnung sparen. nein, der Takt bei ist mehr ein Frame Sync als ein Takt. Du musst daraus Deinen Takt generieren.
Nee, im Normalfall kommt der (HighSpeed) Takt zu dem die Daten und das Frame Sync synchron sind aus der Quelle. Mit dem Takt betreibst du die ISERDES über die BUFIO2 Geschichte. Das Frame Sync dient nur dazu beim Starten die Bits richtig zu schieben, das geht über das BitSlip. Wenn das einmal ausgrichtet ist, kann eigentlich bei so einer source synchronous Strecke nicht mehr viel passieren. Siehe XAPP1064
Dieter schrieb: > nein, der Takt bei ist mehr ein Frame Sync als ein Takt. Du musst daraus > Deinen Takt generieren. Wenn ich mich an den Core-Generator halte, ist er das nicht - da ist der Takt ein Takt und im Empfangs-FPGA wird dieser runter geteilt um ein Frame Sync daraus zu machen. Daher rührt meine Frage oben. Ist der Ansatz vom CoreGen grundsätzlich falsch und man sollte den Weg gehen, ein langsames Frame Sync (im Fall von 4b/5b Rechteck in 5 Datenbit Breite) übertragen und dann im Empfangs-FPGA via DCM auf Datenfrequenz multiplizieren?
Angehängte Dateien:
-
SERDES.PNG
59 KB
Das Frame Sync intern erzeugen bringt ja nichts. Das muss der Sender erzeugen, damit der Empfänger weiß, wann ein neues Byte anfängt (oder bei dir halt wann das MSB/LSB des nächsten 5 Bit Wortes kommt). Du musst das Frame Sync vom Sender ausgeben und ein konstantes Muster einstellen, anhand dessen du im Empfänger zweifelsfrei feststellen kannst, wann die Bits ausgerichtet sind. Am LTC2175 ADC wird das beispielsweise so gemacht wie im Bild. Mit jeder Flanke des High Speed Cloks wird ein Datenbit abgetastet und das Frame Signal zeigt eindeutig die Lage an. Intern musst du dann beim Starten solange das Bit Slip machen bis die Lage stimmt, also am Frame Sync Parallel Vektor dein am Sender eingestelltes konstantes Muster anliegt.
Christian R. schrieb: > Du musst > das Frame Sync vom Sender ausgeben und ein konstantes Muster einstellen, > anhand dessen du im Empfänger zweifelsfrei feststellen kannst, wann die > Bits ausgerichtet sind. Das klingt gut und sinnvoll, nur brauche ich dann für das FS extra Pins, auf die ich gerne verzichten würde (muss). Ich hatte grade die Idee, in regelmäßigen Abständen, also vor jedem größeren "Datenblock" eine Sync-Sequenz aus 5x Steuerwörtern zu schicken (z.B. J -> 11000). Dann könnte der Empfänger darauf warten, maximal 5x Bit Slippen und wäre dann für den nächsten größeren Traffic im FS. Gute oder schlechte Idee? ;)
Achim schrieb: > Christian R. schrieb: >> Du musst >> das Frame Sync vom Sender ausgeben und ein konstantes Muster einstellen, >> anhand dessen du im Empfänger zweifelsfrei feststellen kannst, wann die >> Bits ausgerichtet sind. > > Das klingt gut und sinnvoll, nur brauche ich dann für das FS extra Pins, > auf die ich gerne verzichten würde (muss). Ich hatte grade die Idee, in > regelmäßigen Abständen, also vor jedem größeren "Datenblock" eine > Sync-Sequenz aus 5x Steuerwörtern zu schicken (z.B. J -> 11000). Dann > könnte der Empfänger darauf warten, maximal 5x Bit Slippen und wäre dann > für den nächsten größeren Traffic im FS. Gute oder schlechte Idee? ;) Genau das meinte Christian auch so. Wenn man noch sicherstellt, dass auch ein verschobenes Sync kein legales Symbol ist, wird ein Versatz einfach detektier- und korrigierbar.
Stimmt, ich hätte besser lesen/verstehen sollen. Mein J-Symbol muss auch nicht 5x gesendet werden, sondern nur ein mal beim Start jedes Datenblocks - so wie auch in der xapp495 beschrieben. Also, danke und Euch ein schönes Wochenende! Viele Grüße Achim
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.