Hi allesamt, nur eine kleine Frage - ich hab bei euch auf der Seite gestöbert und bei "Grundregeln für synthetisierbaren VHDL-Code" habe ich die Regel gelesen: - Nur ein einziger Takt im gesamten Design, nur steigende ODER fallende Taktflanke auswerten... Kann mir jemand erklären welchen Hintergrund diese Regel hat? Mir erschließt sich der Zusammenhang nciht ganz. Vor allem weiß ich jetzt auch nicht so ganz was mit "im gesamten Design" gemeint ist - ich benutze ja auch FIFOs um die Taktdomänen voneinander zu trennen - und das klappt eigentlich ganz gut ;). Danke schon mal für die Antwort :) Gruß
@ Marc Schmitt (nightguardian) >Kann mir jemand erklären welchen Hintergrund diese Regel hat? Mir >erschließt sich der Zusammenhang nciht ganz. Ganz einfach. Es gibt real nur FlipFlops, welche auf EINE Flanke reagieren können. Die diversen Spezial-ICs kann man da mehr oder wenigr vergessen. > Vor allem weiß ich jetzt >auch nicht so ganz was mit "im gesamten Design" gemeint ist Halt im gesamten Design. Ist aber etwas zu strikt formuliert. Genauer gesagt in einem VHDL-Prozess. MfG Falk
Der Guide richtet sich auch mehr an VHDL-Anfänger, wenn man schon erfolgreich Taktdomänenübergänge zustande gebracht hat, was man immerhin schon was man tut und ist kein blutiger Anfänger mehr
> ich benutze ja auch FIFOs um die Taktdomänen voneinander zu trennen Wenn du das Wort "Taktdomäne" kennst und richtig schreiben kannst, bist du dir ja auf jeden Fall der Problematik bewusst. > - und das klappt eigentlich ganz gut ;). Wenn da jetzt noch irgendwo das Wort "meistens" gestanden hätte, hätte ich gesagt, du hast ein Problem am Taktdomänenübergang ;-) > nur steigende ODER fallende Taktflanke auswerten... > Kann mir jemand erklären welchen Hintergrund diese Regel hat? Wenn du abwechselnd steigende und fallende Flanken im Design verwendest, hast du (evtl. ohne dass das offensichtlich ist) in einem 100MHz Design auf einmal für einen Logikpfad zwischen zwei FFs die Anforderung, innerhalb von 5ns (=200MHz) die Kombinatorik fertig berechnet zu haben.
Wo wir gerade beim Thema sind: Der Xilinx Timing Constraints Guide sagt folgendes: The most common type of clock circuit is one in which: - The input clock is fed into a DLL/DCM/PLL - The outputs are used to clock the synchronous paths in the device In this case, the recommended methodology is to define a PERIOD constraint on the input clock to the DLL/DCM/PLL. By placing the PERIOD constraint on the input clock, the Xilinx tools automatically: - Derive a new PERIOD constraint for each of the DLL/DCM/PLL output clocks - Determine the clock relationships between the output clock domains, and automatically perform an analysis for any paths between these clock domains. Das bedeutet aber nicht, dass man auf Clock-Crossing von CLK nach CLKFX hinter der DCM verzichten kann, weil ISE etwa alle Timings richtig berücksichtigen würde, oder?
Theoretisch kannst du das dann schon vernachlässigen. Der Timinganalyzer kennt in diesem Fall ja die genaue Lage der Taktflanken zueinander, da sie ja durch die DCM mehr oder weniger phasenstarr miteinander gekoppelt sind. Je nach gewähltem Verhältnis von CLK und CLKFX kann er sich dann den Worst-Case ausrechnen und für den das Timing checken. Mal als Beispiel: CLK hat eine Periodenlänge von 5 ns, CLKFX von 10 ns. Der kürzeste Zeitraum zwischen zwei steigenden Flanken bei einem Übergang zwischen den beiden Takten ist halt 5 ns. Angenommen CLK bleibt bei ns und CLKFX hat jetzt eine Periodenlänge von 6 ns, so veringert sich die Zeit zwischen zwei Flanken auf minimal 1 ns. Da wirst du dann natürlich sofort Timing-Fehler bekommen. Da hilft dann nur den Pfad zwischen den beiden Takten als False Path zu definieren und irgendeinde passende Clock-Domain-Crossing-Schaltung einzubauen. Noch schlimmer ist es natürlich, wenn du rekonfiguriebare DCMs benutzt. Da weiß der Timing Analyzer ja garnicht was du tust. Von daher muß man schon genau wissen was man macht, bzw ob man es wirklich mit zwei Clock-Domains zutun hat (was ja bei dem ersten Beispiel nicht der Fall ist). Aus Erfahrung kann ich sagen, daß Clock Domain Crossing ein fieses Problem ist (teilweise auch für Profis, die ihr Leben lang Chips Design gemacht haben) und meine Ex-Firma da schon ein paar Millionen $ an Masken- und Chipherstellungskosten deswegen versenkt hat.
Hallo Hans! Danke für die gute Erklärung! Hans schrieb: > Aus Erfahrung kann ich sagen, daß Clock Domain Crossing ein fieses > Problem ist (teilweise auch für Profis, die ihr Leben lang Chips Design > gemacht haben) und meine Ex-Firma da schon ein paar Millionen $ an > Masken- und Chipherstellungskosten deswegen versenkt hat. Dann bin ich ja beruhigt ;) Grüße, Anguel
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.