FPGA 2 Clk Synchron, timing problem

Verwendest du die Hardware SerDes im FPGA?

Wenn nein hängt das stark von deiner implementierung ab. Wieviel Zeit hat denn der langsame Takt um das zuletzt deserialisierte Bit zu erfassen? Ist das eine ganze Periode von C0 oder doch eher nur eine Periode von C1?

Du kannst ja die deserialisierten Bits mit C1 in einen Vektor schreiben und dann mit diesem Vektor ein CDC nach C0 machen.

Gustl B. schrieb:

Verwendest du die Hardware SerDes im FPGA?

Nein HDL

Gustl B. schrieb:

Wenn nein hängt das stark von deiner implementierung ab. Wieviel Zeit hat denn der langsame Takt um das zuletzt deserialisierte Bit zu erfassen? Ist das eine ganze Periode von C0 oder doch eher nur eine Periode von C1?

Nun eigentlich lange, da dieser wert ja die nächsten 3 clk des schnellen clks nicht ändert. Quartus versteht dies vermutlich nicht (da nicht mitgeteilt) und versucht das timing innerhalb eines Zykluses des schnellen clk zu erreichen - was nicht geht.

Also: DFF(400MHz, update alle 4 CLK) -> DFF (100MHz)

Wie kann quartus gesagt werden, dass dieser übergang nicht das timing vom 400MHz clk einhalten muss da output konstant über mehrere clk?

Ich hab schon seit Jahren nicht mehr mit Quartus gearbeitet und ich kenne mich eher mit Vivado aus. Was du brauchst nennt sich multi-cycle path und das gibst du als constraints in deine SDC-Datei ein. Zur Not kann man auch ein false path zwischen den DFF nehmen, aber davon rate ich eher ab.

Falls es noch nicht von dir oder Quartus gemacht wurde, solltest du auch die Relation zwischen deinen clocks C0 und C1 angeben. Ansonsten wird angenommen, dass beide clocks eine willkürliche Phasenverschiebungen zueinander haben, aber in deinem Fall sind sie aber 0° verschoben und somit synchron.

Max M. schrieb:

Nun eigentlich lange, da dieser wert ja die nächsten 3 clk des schnellen clks nicht ändert.

Richtig, aber vom letzten Bit mit dem schnellen Takt bis zur Flanke vom langsamen Takt ist es nur eine Periode vom Schnellen Takt.

Fabian S. schrieb:

multi-cycle path und das gibst du als constraints in deine SDC-Datei ein.

Das scheint genau das zu sein.

Gustl B. schrieb:

aber vom letzten Bit mit dem schnellen Takt bis zur Flanke vom langsamen Takt ist es nur eine Periode vom Schnellen Takt.

Oh, hoppla, wo du recht hast hast du wohl recht.

Hmm Multi-Cycle path contstraints können gefährlich sein bez solcher stolperfallen? Also würde ich gewarnt werden wenn ich dies fälschlicherweise als multi-cycle path constraint hätte, aber das letzte bit dies gar nicht erfüllt? - Oder bekommt man ein nicht timing conformes design ohne Warnung?

Zum Design: Nun wollte möglichst wenig delay und hohe abtastungsrate. Dahr 2FF Sync + Deser mit 400MHz und danach system clk 100. Wie kann ich dies timingmässig entschärfen? mit 2 paralellen Schieberegistern arbeiten und jeweils deren Auslesen um 1 (400Mhz) clk verzögern (mit abwechselndem Wechsel der Schieberegister)?

Ich habe das RTL angeschaut, zwischen den Registern ist nur ein 16bit MUX. Dieser sollte der Fitter doch im MAX 10 in 2.5ns reinbringen können? Slack ist auch nur -0.14. Habt ihr evtl tipps wie der Fitter eingestellt werden könnte damits gehen könnte?

Der MUX ist nur ein Teil vom Pfad. Da ist auch Routing (Leitungen im FPGA).

Bisher hast du leider nur von Timing Problemen geschrieben. Was sind das denn genau für Probleme, was sagt Quartus genau? Und wieso willst du mit dem deserialisierten Vektor kein normales CDC machen?

Gustl B. schrieb:

Bisher hast du leider nur von Timing Problemen geschrieben. Was sind das denn genau für Probleme, was sagt Quartus genau?

Slack negativ. Konnte das Problem nun lösen in dem ich diesen MUX hinter das nächste Register verschieben konnte (geringfügiges umschreiben des codes). Also nun ist DFF (400) -> DFF (100) direkt und hat positiven slack.

Gustl B. schrieb:

Und wieso willst du mit dem deserialisierten Vektor kein normales CDC machen?

Würde ich gerne, mangelt aber an soft CDC IP. Wenn du hier etwas hast, sehr gerne; das einzige was ich kenne ist das rechtlich/ethisch nicht unproblematische reverseing des Aurora IP wo dieser noch als SRC verfügbar war.

Also es wird ja nicht nur CDC benötigt, sondern auch framesync, 8b10b, crc etc.

CDC ist nur das clock domain crossing, das geht auch ganz ohne IP. Man muss nur sicherstellen, dass die Daten zu dem Zeitpunkt zu dem sie in der Ziel Clock Domäne erfasst werden stabil sind. Und man kann da mit Constraints arbeiten. Register als asynchron definieren und so.

Gustl B. schrieb:

CDC

Entschuldige habe CDC und CDR verwechselt.

Du meinst damit sicher einen FIFO block?

Gustl B. schrieb:

das geht auch ganz ohne IP

Hmm oder auch nicht :P

Gustl B. schrieb:

Man muss nur sicherstellen, dass die Daten zu dem Zeitpunkt zu dem sie in der Ziel Clock Domäne erfasst werden stabil sind. Und man kann da mit Constraints arbeiten. Register als asynchron definieren und so.

Hier mangelts an meiner Expertise. Also ich habs nun einfach direkt ohne constraints 400->100FF erreicht ohne negativen Slack.

Aber wie die CDC "sinnvoler/professioneller" und algemeiner gestalten mit constraints - wie genau?

Also ich würde die Daten eine Zeit lang in Ruhe lassen um die mit dem langsamen Takt zu erfassen. Also bei dir zwei Vektoren A und B mit je 4 Bits. Während du mit dem schnellen Takt in A oder B deserialisierst, liegt der B oder A (also der jeweils Andere) in Ruhe rum und kann von dem langsamen Takt abgetastet werden.

@Max: Wie willst Du bei Dir das 'Clock Recovery' realisieren? Nimmst Du eine PLL dafür?

Bin gerade an einem ähnlichen Thema dran...

Wenn Dein FPGA mit 400 MHZ zurechtkommt (das muss es ja zum deserialisieren) und deine Clocks einen Phasenversatz von 0° haben und das Quartus auch bewusst ist (z.B. 100M und 400M Clock kommen aus der selben PLL), dann sollte es reichen, in der 100MHz Domain ein einfaches Register einzufügen und nicht direkt mit dem Wert aus der 400MHz Domain weiter zu rechnen. Dadurch bekommst Du 1 100MHz Takt Delay rein, aber das ist ja vielleicht verschmerzbar. Alternativ kannst Du in der 100M Domain ein Toggle signal implementieren, und damit in der 400M Domain erkennen, wann gesampelt wird. Dann musst Du dein SReg zum geeigneten Zeitpunkt in der 400M Domain kopieren und entsprechende Multicycle Constraints definieren.

Wenn Du uns Deine aktuelle Implementierung zeigst, dann können wir Dir konkrete Tips geben, so bleibt nur der Blick in die Glaskugel.

@Rick: Mit Clock Recovery hat das nichts zu tun, da die Takte ja Phasensynchron und bekannt sind