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
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?
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
