Hallo Leute, Ich habe einen Clock und einen optischen Trigger. Das Problem ist halt das die Phase zwischen den Clock und dem Trigger nicht konstant ist. Der Trigger wird aus einem optischen Signal erzeugt. Dies ist halt sehr empfindlich. Die Digitaisierung startet mit dem Trigger. Nun habe ich jedoch das Problem das ich einen Jitter bei meinem abgetastetem Signal besitze. Dies war auch zu erwarten. Denn wenn der Trigger sehr dicht an der Setuptime Grenze kommt, dann Jittert das Signal um 1 Pixel. Nun muss das digitalisierte Signal am PC unbedingt gemittelt werden. Demnach darf das Signal Jitterfrei sein. Jetzt war meine Überlegung wie folgt. Ich beutze einen FF. Ein den D Eingang des FF lege ich den Trigger und auf den Clock Eingang mein Clock. Anschließend benutze ich einen 2. FF und mache das gleiche. Der unterschied ist nur das ich den 2.FF im FPGA so platzieren muss, das die Daten (Trigger 250ns verspätet an den FF ankommen. Wenn beide FFs den selben Wert besitzen. Dann weis ich das die Septup Time eingehalten wurde und der Trigger nicht gerade zu einer üngünstigen Phase anlag. Mein Problem ist nur wie kann ich dem Xilinx Placer sagen das die Laufzeit von dem Trigger Signal xns Länger zum 2FF betragen soll? Gibt es da ein Constraint. Ich wollte jetzt nicht über LOC den FF selber irgendwo platzieren und dann über eine Timing Simulation prüfen obe alles funktioniert hat.
Ich verstehe nicht, was Du möchtst und anderen wird es ähnlich gehen. Sebastian schrieb: > Demnach darf das Signal Jitterfrei sein. Das scheint mir nicht ganz sinnvoll. Generell hört sich Deine Lösung nach einer Analogverschiebekette an und ich bezweifle, ob das in einm FPGA machbar ist.
Sebastian schrieb: > Der > unterschied ist nur das ich den 2.FF im FPGA so platzieren muss, das die > Daten (Trigger 250ns verspätet an den FF ankommen. ich hoffe mal, du willst um 250ps verzögert eintakten, nicht um 250ns. Um Eingangssignale definiert zu verzögern besitzen einige FPGAs sogenannte "IDELAYs". Damit kannst du das Signal in Schritten von einigen 10ps in einem Bereich von eingen ns verschieben bevor es eingetaktet wird. Vielleicht hilft dir das weiter? Aber weniger als einen Takt Jitter für die Abtastung schaffst du damit auch nicht nicht wirklich. Wenn dir das zu viel ist: die Abtastrate um Faktor x hochdrehen (das gibt dir den genaueren Triggerzeitpunkt) und dann nur in jedem x-ten Takt nach dem Trigger das Signal übernehmen.
Ich meinte natürlich 250ps Ein Idelay kann ich nicht verwenden, denn der Trigger kommt nur an einem Pin rein. Von den Input Pin soll das Signal auf 2 unterschiedliche FF geleitet werden. Das Triggersignal soll zum 1. FF z.B. 1000ps benötigen und zum 2. FF z.B. 1250ps benötigen. Der Clock liegt an beiden FF zeitgleich an. Demnach würde ich das Signal zu 2 unterschiedlichen Zeiten abtasten.
Sebastian schrieb: > Der Clock liegt an beiden FF zeitgleich an. Demnach würde ich das Signal > zu 2 unterschiedlichen Zeiten abtasten. Was soll das bringen? Was möchtest Du optimieren? Sebastian schrieb: > Demnach darf das Signal Jitterfrei sein. Diese Aussage verstehe ich nicht. Du wirst immer einen Jitter haben. Die Frage ist, wie groß darf der sein. Sebastian schrieb: > Dann weis ich das die Septup > Time eingehalten wurde und der Trigger nicht gerade zu einer üngünstigen > Phase anlag. Was machst Du, wenn der Trigger in einer ungünstigen Phase anlag? Ignorieren? Warum nicht einfach über zwei hintereinandergeschaltete FF synchronisieren? BTW, ich würde es mal mit einer Plazierung per Hand (LOC constraints) versuchen. Das dürfte die sichersten Ergebnisse bringen. Kennst Du den FPGA-Editor? Der ist zwar etwas kryptisch zu bedienen, aber man kann gut nachschauen, ob das Ergebnis passt. Duke
Es ist doch eigentlich sehr einfach. Wenn die Phase des Triggers nicht konstant ist, dann ist nicht immer sichergestellt das die Setup Zeit vom FF eingehalten wird. Und genau diesen Fall möchte ich erkennen. Daher ja der 2. FF. Dieser bekommt das Signal verzögert um eine Zeit x z.B. 250ps. Der Takt kommt bei beiden FFs ca zur gleichen Zeit an. Wenn beide FFs nicht den selben Zustand am Ausgang besitzen, dann weis ich das die Setup Zeit vom FF verletzt wurde. Dann würde ich das Signal nicht zum mitteln nehmen. Ich kann natürlich den FF per Hand platzieren doch ich dachte das die der Xilinx Mapper auch macht nur weis ich die Anweisung nicht.
Sebastian schrieb: > Es ist doch eigentlich sehr einfach. Für dich schon, im Gegensatz zu uns kennst du deinen Aufbau ;-) Geht es dir darum, den Jitter von +/- 1 t_CLK auf +/- 0.5 t_CLK runter zu bringen? Dann taste den Trigger doppelt so schnell ab. Oder geht es dir darum, dass am Ausgang des Trigger-FF eine Statemachine ab und zu falsch reagiert, weil die Setup-Zeit verletzt wurde? Dann synchronisiere über zwei hintereinandergeschaltete FF.
Was du vor hast, ist eine total unübliche Lösung. Mit dem Trigger wird vermutlich ein Vorgang ausgelöst, mit dem dann irgendwelche Daten erfasst werden, richtig? Du hast also offensichtlich Zeit genug, um den Trigger in 2 Register zu speichern und dann musst du ja noch die Zustände der beiden Register plausibilisieren. Das kann auch nicht rein kombinatorisch erfolgen, da das Auswertesignal glitchen kann. Also musst du alles eh noch über eine Registerstufe führen. Somit hast du noch einen Takt verloren. Was du vor hast, kann man sicher machen, aber ich habe so meine Zweifel dran, ob es schlau ist, das so zu tun. Beim Übergang von einer Taktdomäne in eine andere hast du IMMER einen Jitter, wenn die Takte nicht phasensynchron sind. Egal, wie du es machst.
Meines Wissens gibt es kein Constraint, mit welchem du eine Mindestlaufzeit einstellen kannst. Was du aber ebenfalls als Constraint übergeben kannst ist das Placement. Wie das bei Xilinx funktioniert, weiss ich nicht. Bei Lattice kann man einzelne Teile des Designs als Gruppe "markieren" und diese dann platzieren. Geht alles in Textform im Constraintfile. Allerdings kannst du auch hier das Routing nur über einen MAXDELAY beeinflussen. Aber geschickt gemacht, kannst du Quelle und Ziel so weit auseinander platzieren, dass bei idealem Routing (kürzester Weg) die Zeit rauskommt, die du dir wünschst. Mit dieser Zeit belegtst du dann MAXDELAY für dieses Signal. Dann sollte bei jedem darauffolgenden Syntheselauf das Gleiche rauskommen. Muss man sich aber vermutlich erstmal rantasten. Aber abgesehen davon vermute ich, dass du mit deinem Vorhaben auf dem Holzweg bist und vermutlich deutlich eleganter gelöst werden kann. Wenn du das aber unbedingt über so einen Delay lösen musst oder willst, dann wäre das o.g. eine Lösung
Ich denke, dass Du einen Überlegungsfehler in Deiner Vorstellung hast, denn letztendlich wirst Du immer einen Jitter von ca. einem Taktzyklus zwischen Ereignis und Abtastung haben. Deine Trickschaltung verbessert das Ganze nur minimal. Beispiel : Takt 100 ns, Setup Zeit 250 ps, Hold-time 20 ps. Fall 1 : Ereignis bei t=300,021 ns, direkt nach dem Takt-Flanke Abtastung Sensor erfolgt bei t=400 ns, ist sauber, Setup und Hold-Zeiten eingehalten. -> Fehler (Jitter) 99,979 ns. Fall 2 : Ereignis bei t=399 ns, kurz vor Takt-Flanke Abtastung Sensor erfolgt bei t=400 ns, ist sauber, Setup und Hold-Zeiten eingehalten. -> Fehler (Jitter) 1 ns Fall 3 : Ereignis bei t=399,9 ns, kurz vor Takt-Flanke Abtastung Sensor erfolgt bei t=400 oder t=500 ns, da Setup verletzt -> Jitter 100,1 ns Wenn ich richtig verstanden habe, willst Du gerade diesen Fall erkennen, damit Du eventuell das ganze um einem Takt veschieben kannst und den Fehler von 100,1 ns auf 0,1 ns reduzierst. Das bringt Dir nun wirklich nichts, da Du immer einen maximalen Fehler von 99,9 ns hast.
@ Schlupf Genau so wollte ich es auch machen. Man kann unterschiedliche Bauteile Gruppieren und dann in einer Aerea platzieren und das gleiche mit dem 2.FF.
Warum ist mir das Wort "Holzweg" in den Gedanken hängen geblieben? Das Problem kann m.E. ohne Funktionseinschränkung einfach über ein einziges Sync-Flipflop erledigt werden. Denn der Jitter wird hier immer +-1/2 Taktzyklus sein. Auch dieser dubiose Zwei-Flipflop-Trick ändert daran nichts...
Lothar Miller schrieb: > Warum ist mir das Wort "Holzweg" in den Gedanken hängen geblieben? Weil es unangenehm ist, wenn man merkt, dass die "schöne" Idee nichts bringt :-) Lothar Miller schrieb: > Das Problem kann m.E. ohne Funktionseinschränkung einfach über ein > einziges Sync-Flipflop erledigt werden. Denn der Jitter wird hier immer > +-1/2 Taktzyklus sein. Auch dieser dubiose Zwei-Flipflop-Trick ändert > daran nichts... Sehe ich genauso und hab ich ja weiter oben auch schon geschrieben. Aber wenn er an seiner Lösung festhalten will... Sebastian schrieb: > @ Schlupf > Genau so wollte ich es auch machen. Man kann unterschiedliche Bauteile > Gruppieren und dann in einer Aerea platzieren und das gleiche mit dem > 2.FF. Ja dann mach es doch genau so.. Jedes FF in eine separate Gruppe, diese platzieren und los geht´s..
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.