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
Wie werden denn die Takte erzeugt? Sind das verschiedene Taktquellen, oder sind alle Takte aus einer Quelle abgeleitet? Duke
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.
>Ich habe im Moment set_false_path auf alle Pfade gemacht
Was meinst du mit "alle Pfade" ?
Hast Du eine kleine HDL-Beschreibung, die deine Sync-Mechanismen zeigt?
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.
Gibt es zu deiner Prosa-Lösung auch ein wenig HDL+Constraints?
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!
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.