Servus, wenn ich bei Xilinx das Timing für einen Übergang zwischen 2 clockdomains constrainen möchte, mache ich das so: NET "CLK_1" TNM_NET = "TIMEGROUP_CLK_1"; NET "CLK_2" TNM_NET = "TIMEGROUP_CLK_2"; TIMESPEC "TS_1_TO_2" = FROM TIMEGROUP_CLK_1 TO TIMEGROUP_CLK_2 8 ns; TIMESPEC "TS_2_TO_1" = FROM TIMEGROUP_CLK_2 TO TIMEGROUP_CLK_1 8 ns; Wie sieht ein solches Konstrukt bei Lattice aus?
Wozu ist dieses Constraint eigentlich gut? Sind die Takte voneinander abgeleitet?
HansDampf schrieb: > Wozu ist dieses Constraint eigentlich gut? Um dem Router zu sagen, welche Laufzeit ein Signal, das in der einen Domain getrieben wird maximal haben darf, bis es in der anderen Domain eingetaktet wird. > Sind die Takte voneinander abgeleitet? Nein
>Um dem Router zu sagen, welche Laufzeit ein Signal, das in der einen >Domain getrieben wird maximal haben darf, bis es in der anderen Domain >eingetaktet wird. Wozu dann? Wenn die Takte asynchron gegeneinander sind, dann ist es doch eigentlich relativ egal, wie lange das zu synchronisierende Signal benötigt?
Wenn ich mehrere Signale parallel (Adress- und Datenbus) übertrage, stelle ich so sicher, dass sie innerhalb einer gewissen Zeit, also einigermaßen synchron eintreffen. Sonst kann es doch theoretisch passieren, dass ich ein Strobe-Signal detektiere, während z.B. die Adresse noch gar nicht gültig ist. Mag sein, dass das in einem schnellen FPGA relativ theoretisch ist, aber ich halte es für möglich, insbesondere wenn das Eintakten mit einem schnellen Takt geschieht.
pks schrieb: > Wie sieht ein solches Konstrukt bei Lattice aus? MULTICYCLE FROM CLKNET "Clock1" TO CLKNET "Clock2" 3 X;
Irgendein constraint muss man setzen und sei es ein TIG. Das Problem ist aber dann die konsistente Übernahme von Daten aus Bussen. Wenn die einzelnen routings zu weit auseinanderlaufen, klappt das Einsynchen gfs nicht mehr wie gewünscht: pks schrieb: > Mag sein, dass das in einem schnellen > FPGA relativ theoretisch ist, aber ich halte es für möglich, > insbesondere wenn das Eintakten mit einem schnellen Takt geschieht. Die Bedenken sind begründet. Wenn man das Timing mit einem TIG entspannt, könnte es passieren, dass die unterschiedlichen Laufzeiten zugehöriger Signale so stark gespreizt sind, dass man sie nicht mit derselben Flanke des Zieltaktes erwischt und man niemals (auch bei noch so starkem oversampling) einen konsistenen Bus sieht. Da nutzt dann das beste strobe nichts. Leider ist es mir noch nicht gelungen herauszubekommen, ob die Synthestools das automatisch berücksichtigen, oder ob es gfs durch die Art des Platzierens (timing driven) mehr oder weniger automatisch hinhaut oder ob nict viele Designs einfach Glück haben. Bei einigen zurückliegenden Designs habe ich diesbezügliche constraints nicht gebraucht. Grundsätzlich schaden sie aber nicht, meine ich.
Du hast absolut recht, mit deinen Befürchtungen. Wenn die Takte keinen Bezug haben, dann kann das echt ein Problem werden. Das Risiko steigt, je knapper die Zeit zwischen anlegen der Daten und dem Strobe-Signal an der Quelle wird. Ich würde hier auch auf jeden Fall ein Constraint vergeben, das sicherstellt, dass das Strobe-Signal die Daten nicht überholen kann. Also einen Max-Delay der kleiner ist, als der Abstand zwischen Daten an der Quelle gültig und Strobe an der Quelle gültig. MULTICYCLE, wie Lattice User ja bereits angegeben hat, ist da das passende Constraint. Meines Wissens kann man anstelle eines Faktors auch eine absolute Zeit angeben. MAXDELAY müsste auch gehen. Wobei du hier vermutlich mit DATA PATH ONLY oder so ähnlich klar machen musst, dass der Quell-Takt und der Zielt-Takt keinen Bezug zueinander haben.. Aber musst mal nachlesen, wie das mit den Constraints genau geht. Stichworte zum googeln hast ja ;-)
Oder aber Du sorgst dafür, dass das Strobe in der neuen Taktdomäne garantiert nach den Busdaten anliegt. Kommt halt ein wenig auf das Bus-Timing an...
Hallo pks, meiner Einschätzung nach geht deine Frage am eigentlichen Problem vorbei. Wenn Du ganze Busse von einer Taktdomäne in eine andere hinüberführen muss, dann hift da kein Constraining. Da muss man die Logik richtig bauen und dann ist das Timing schlicht egal. Das Problem hat man ja nicht nur zwischen zwei Taktdomänen im FPGA, sondern auch wenn man einen externen uC an ein FPGA mittels eines parallelen Interfaces anschließt. Meine Vorgehensweise ist da üblicherweise, den (Adress-)Bus überhapt nicht einzusynchronisieren, sondern nur das Strobe-Signal. Durch drei Flipflops durch, Differenzsignal von 2. und 3. Stufe als enable für nachfolgende Logik nehmen, und gut ist's. Funktioniert zuverlässig. Grüße, Harald
Harald Flügel schrieb: > Meine Vorgehensweise ist da üblicherweise, den (Adress-)Bus überhapt > nicht einzusynchronisieren, sondern nur das Strobe-Signal. Durch drei > Flipflops durch, Differenzsignal von 2. und 3. Stufe als enable für > nachfolgende Logik nehmen, und gut ist's. Funktioniert zuverlässig. Hallo Harald, Genau so mach ich es ja auch. Es ging mir um den Fall, dass ein Bit des Adressbusses eine längere Signallaufzeit hat, als die Eintaktung des Strobes dauert.
Hallo pks, den Fall, dass ein Bit des Adressbusses eine längere Signallaufzeit hat, als die Eintaktung des Strobes dauert, den vermeide ich zuverlässig dadurch, dass die Eintaktung lange genug dauert. Die zwei ohnehin nötigen Flipflops hintereinander reichen da üblicherweise aus, und wenn nicht, dann kommt halt noch ein drittes oder ein viertes rein. Grüße, Harald
Harald Flügel schrieb: > Meine Vorgehensweise ist da üblicherweise, den (Adress-)Bus überhapt > nicht einzusynchronisieren, Wie soll das denn gehen? Du brauchst doch in jedem Fall eine FF-Bank, um die Daten zu erfassen. Nach Deiner Methode erfasst du doch das strobe 3 Takte zu spät, musst Dich also auf die Daten von drei Takten vorher beziehen.
Das klappt gut bei entsprechenden Timingvorschriften für den Sender. Also in diesem Fall, dass die Daten nach dem Strobe noch mindestens für die Zeit 3x FPGA interne Taktzyklen anliegen müssen. (Thold) Das schränkt die erreichbare Geschwindigkeit natürlich ein. Wenn der ganze Adress-/Daten-/Steuerbus einsynchronisiert wird, können die nötigen Setup- und Hold Zeiten natürlich kürzer sein (bei entsprechend höherem Resourcenverbrauch).
pks schrieb: > TIMESPEC "TS_1_TO_2" = FROM TIMEGROUP_CLK_1 TO TIMEGROUP_CLK_2 8 ns; > TIMESPEC "TS_2_TO_1" = FROM TIMEGROUP_CLK_2 TO TIMEGROUP_CLK_1 8 ns; Kann ich diesen Konstruktu auch für einen timing ignore verwenden? Bei mir spukt der Synthesizer, dass er das nicht verarbeiten kann, weil es mit der Clock time spec interferiert: Beitrag "Problem mit Timing Constraint bei Xilinx"
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.