Hallo! Ich hab einen Cyclone IV E FPGA, der mit 50 MHz läuft (dev board). Ich bekomme von einem CMOS Sensor Daten und einen Takt (CLK) von 20 MHz. Die Daten möchte ich jetzt an der fallenden Taktflanke von CLK latchen. Mein Problem ist nun, dass die Daten zwar stabil sind zwischen zwei steigenden CLK Flanken, CLK selber jedoch manchmal Glitches enthält. Das haut mir meinen Synchronizer für die Datenleitungen und die dahinterliegende Logik, welche die synchronisierten Signale verwendet, zusammen. Ich habe jetzt CLK als Eingang zu einer PLL, die im "normal mode", 1:1 und 0 deg Phasenverschiebung arbeitet und mir saubere 20 MHz liefern soll, womit ich die Synchronizer betreibe und auch meine Logik, die die Daten verarbeitet. Das Problem ist, dass die PLL anscheinend nicht mit dem instabilen 20 MHz Takt am Eingang klarkommt und mir ebenfalls unerwünschte Pegelwechsel liefert. Ich hab noch nicht viel Erfahrung mit FPGAs und PLLs, hat jemand einen Tipp für mich? Die PLL hab ich mit dem MegaWizard im Quartus angelegt. Die Dokumentation zu den PLLs finde ich aber relativ irreführend. So ist z.B. gleich am Anfang des Wizards ein Speed-Grade auszuwählen (6 bis 9 oder so), in der Doku steht aber nirgends beschrieben welche Zahl wofür steht.
Christopher G. schrieb: > Die Daten möchte ich jetzt an der fallenden Taktflanke von CLK latchen. Latchen? Kombinatorisch? Ein Latch ist pegelgesteuert.... Du meinst wahrscheinlich "eintakten" oder "übernehmen"... > Ich hab noch nicht viel Erfahrung mit FPGAs und PLLs, hat jemand einen > Tipp für mich? Ich mit Alteras PLLs auch nicht, aber mit einem glitschigen Takt brauchst du z.B. bei Xilinx DCMs gar nicht erst auftauchen. > Das Problem ist, dass die PLL anscheinend > nicht mit dem instabilen 20 MHz Takt am Eingang klarkommt und mir > ebenfalls unerwünschte Pegelwechsel liefert. Welche Toleranz/Schwankung/Abweichung/Jitter darf denn der Eingangstakt für die PLL laut Datenblatt haben? > Mein Problem ist nun, dass die Daten zwar stabil sind zwischen zwei > steigenden CLK Flanken, CLK selber jedoch manchmal Glitches enthält. Richtig: Dein Problem ist nicht die PLL, dein Problem ist der versaute Takt! > CLK selber jedoch manchmal Glitches enthält. Warum?
Ist dein CMOS Sensor auf dem Board oder extern angeschlossen? Wenn letzteres tippe ich auf versaute Signale. Die Aussage es sind ja nur 20 MHz gilt nicht, der FPGA kann ohne weiteres viel mehr als 100 MHz und wird deshalb auf unsaubere Clockflanken reagieren. Übersprechen von den Datenleitungen auf die Clockleitung ist auch ein Problem und mögliche Ursache für Glitches.
Falls Clk einigermassen sauber ist und Glitches nur im "Edge-Bereich" auftreten: Nimm deine 50MHz-Clk, DDR-FFs als Input-FFs und sample dein CMOS-Clk 10x. Suche H/L-Plateaus indem du nachfolgende Samples zusammenfasst: Plateau dann, wenn 2-3x H bzw L erkannt wird. So bekommst du abwechselnd H/L/H/L (sind 2-3 zu wenig: nimm PLL zur gen. von 100MHz etc.). Sind deine Daten zwischen RisingEdge stabil => nimm Daten nach H/L-Übergang (erkannte Falling Edge). Die Daten sind damit einsynchronisiert. Bleibt noch die Daten gleichmäs. auf in der 50MHz-Domain zu verteilen (kann man z.B. mit Zähler versuchen hinzubekommen). Gruss
Danke für die Antworten. Ich habe gerade festgestellt, dass die CLK Slew Rate des Sensors (ja, extern über (nicht austauschbares) Kabel) im Gegensatz zur Daten Slew Rate auf den höchsten Wert eingestellt ist. Ich werd mal zuerst versuchen, die CLK Slew Rate zu reduzieren. Ansonsten meint ihr, so wie ich es verstanden habe, dass ich selber überabtasten und manuell eine Art Tiefpass implementieren soll, richtig?
Christopher G. schrieb: > Ansonsten meint ihr, so wie ich es verstanden habe, dass ich selber > überabtasten und manuell eine Art Tiefpass implementieren soll, richtig? 50 MHz ist dafür etwas wenig, aber du kannst ja die Onboardclock verwenden um mit einer PLL eine höhere Frequenz zu erzeugen. Was auch of hilft sind Serienwiderstände (33-100 Ohm) an der Quelle.
Christopher G. schrieb: > Ansonsten meint ihr, so wie ich es verstanden habe, dass ich selber > überabtasten und manuell eine Art Tiefpass implementieren soll, richtig? Du sollst zuerst den Grund für den Fehler finden (falscher oder kein Abschluss, nicht angepasste Einkopplung, ...). Und wenn du dort den Fehler gefunden hast und den Fehlermechanismus kennst, dann kannst du eine Lösung suchen. Erst dann kannst du sagen, ob die brauchbarste oder einfachste Lösung ein zusätzlicher Widerstand, ein umprogrammiertes Register oder ein dazugebastelter Eintaktmechanismus ist... Christopher G. schrieb: > der CLK selber jedoch manchmal Glitches enthält. Wie sehen diese Glitches analog aus? Sind das Überschwinger? Wo sind diese Glitches im Taktsignal (zeitlich)?
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.