Hallo,
ich bin gerade unsicher, welche Timing Constraints ich für die folgende
Situation vergeben muss:
Ich habe Clock Domain Crossing Schaltungen mit Handshake Signalen, soll
heißen, dass mehrere std_logic_vector's von einer Clock Domäne in die
andere übergeben werden sollen in folgender Weise: Die Daten werden in
Pufferregister geschrieben und ein "Strobe" Signal wird getoggelt. In
der Zieltaktdomäne wird dieses Signal einsynchronisiert und, sobald hier
eine Flanke auftritt, werden die Daten aus dem Pufferregister
übernommen. Rücksignal für einen Handshake gibt es nicht überall, weil
in der Quellentaktdomäne sichergestellt ist, dass nicht zu schnell Daten
übergeben werden.
Ich bin mir jetzt nicht sicher, wie das zu constrainen ist, das eine ist
das "Strobe" Signal und das andere die Bitvektoren. Durch das
Einsynchronisieren vom Strobe haben die Datenvektoren einige Zeit,
stabil zu werden. Ich habe im Moment set_false_path auf alle Pfade
gemacht aber denke jetzt, dass das Tool ohne Vorgabe theoretisch die
Pfade zwischen den Bitvektoren so lange machen könnte, dass der
Zeitgewinn durch die Synchronisationsstufen wieder aufgefressen wird
(zugegebenermaßen etwas unrealistisch aber theoretisch vielleicht
möglich). Ideal fände ich sowas set_max_delay aber das kann ich laut
Altera AN545 nicht auf einem Register-Register Pfad vergeben.
Wie macht man sowas richtig?
lg
Matthias
Es gibt verschiedene Quellen: Zwei Oszillatoren, daraus werden intern
mit PLL diverse Takte abgeleitet, von beiden Quellen wird jeweils ein
abgeleiteter Takt zu einer anderen Komponente geschickt und kommt mit
einem noch nicht bestimmten Phasenversatz zurück, inklusive
Input-Signale, die zu dieser abgeleiteten Clock synchron sind.
Matthias schrieb:> von beiden Quellen wird jeweils ein> abgeleiteter Takt zu einer anderen Komponente geschickt und kommt mit> einem noch nicht bestimmten Phasenversatz zurück
Den Phasenversatz kannst Du auch nicht bestimmen. Du hast zwei
verschiedene Taktquellen. Die laufen selbst bei nominell gleicher
Taktfrequenz auseinander.
Duke
Hi,
die Schaltung implementiert das, was in folgendem Paper in Abschnitt
10.1 beschrieben ist:
http://www.sunburst-design.com/papers/CummingsSNUG2001SJ_AsyncClk.pdf
(übrigens find ich diese Cummings Papers überwiegend sehr gut) bzw wie
in Abbildung 15 in diesem Paper
w2.cadence.com/whitepapers/cdc_wp.pdf
Beim Cummings steht auch, dass false path gesetzt werden soll. Als
alternative Lösung habe ich multicycle constraints gesehen, die ich nach
derzeitigem Stand als korrekter betrachte.
@Duke: Missverständnis, ich habe gemeint, dass ich intern einen 100 MHz
Takt habe, den ich an eine Gegenstelle sende, die mit diesem Takt Daten
sampelt und diese dann an einem source synchronous Interface mit
demselben 100 MHz Takt zurückschickt. Diese Daten werden dann wieder zu
den internen 100 MHz synchronisiert. Die Frequenz ist also identisch,
die Phasenlage hängt aber von so Dingen wie Kabellänge, Propagation
Delay durch die Treiberbausteine und nicht zuletzt davon ab, wie
reproduzierbar der Kollege seine Synthese hat.
Wenn bei allen Signalen jeweils vor und nach dem Domainübergang Register
hast, Du also keine Logiclevels dazwischen hast (ist aus anderen Gründen
eh unabdingbar), sehe ich nicht wirklich ein Problem, da kommt ja nur
der Interconnect Delay dazu. Un das ist in der Regel weniger als Du in
der schnelleren Clockdomain mit mindestens einem Logic Level hast, auch
ohne Constraints (mindestens bei FPGA's, wenn Du ASIC machst musst Du
die Register nahe beienander platzieren).
Da Du beim Handshake sowieso auf die langsamere Clockdomain Rücksicht
nehmen musst, denke ich solltest Du mit den false_path-Constraints auf
der richtigen Seite sein. Spiel's doch mal durch, und lass dir im
Timinganalyzer die Pfade zwischen den beiden Registern (von vor zu nach
dem Übergang) anzeigen.
Ich hab mir das jetzt für diverse Register angeschaut und bin bei der
aktuellen Umsetzung gottseidank weit auf der sicheren Seite. Es fehlte
mir halt die Methodik, die CDCs richtig zu "verwalten". Aber es
funktioniert ja und das nächste Mal werde ich 1) nicht so leichtfertig
diverse CDCs einführen und 2) doch den multicycle_path nehmen weil ich
da wenigstens noch irgendwelche Grenzen vorgeben kann, in denen das
geroutet werden muss während ich bei set_false_path eigentlich gar keine
Kontrolle darüber habe.
Ist leider alles Code, den ich für die Firma geschrieben habe und die
Lage ist hier derzeit so, dass ich von meinem Vorgesetzten eindeutig
andere Dinge schneller/wichtiger brauche als die Erlaubnis, Code online
zu stellen.
>eindeutig andere Dinge schneller/wichtiger brauche als die Erlaubnis, Code >online zu stellen.
Dann braucht man hier im Forum auch keine vernünfitge Hilfe zu erwarten.
Karlo schrieb:>>eindeutig andere Dinge schneller/wichtiger brauche als die Erlaubnis, Code>>online zu stellen.>> Dann braucht man hier im Forum auch keine vernünfitge Hilfe zu erwarten.
Naja, bitte nicht gleich pampig werden. Hilfe gibts auch gerne, wenn es
eine eindeutige Problembeschreibung gibt. Da im FPGA Forum meist Fragen
auftauchen, die nicht unbedingt der Bastelbude zu Hause entspringen, ist
das völlig OK, wenn man den Code nicht veröffentlichen kann.
Und Matthias hat sein problem derart detailliert beschrieben, dass man
auch ohne Code helfen kann.
>, dass man auch ohne Code helfen kann.
Ja? Was haben wir denn jetzt eigentlich aus der ganzen Sache gelernt?
Richtig, so ziemlich nichts, weil es im Prinzip ein Selbstgespräch war!
