Neben der System-Clock mit 100 MHz benutze ich eine weitere, daraus
synchron abgeleitete Clock mit 51,2 MHz. Der langsamere Takt dient zur
Ansteuerung eines CS4344 Audio-Codecs mit nichtkonformen Sampleraten
(200/100/50/25 kSps/s).
Aufgrund der "krummen" Beziehung 1:1,953125 kommt es beim Übergang
zwischen den Domänen immer zu einer Setup-Time Violation:
Paths for end point AC/Vol_LMULT/Mmult_din_reg[15]_GND_268_o_MuLt_1_OUT
(DSP48_X2Y34.B9), 17 paths
------------------------------------------------------------------------
--------
Slack (setup path): -4.891ns (requirement - (data path - clock
path skew + uncertainty))
Source: DDR/ram_dq_o_9 (FF)
Destination:
AC/Vol_LMULT/Mmult_din_reg[15]_GND_268_o_MuLt_1_OUT (DSP)
Requirement: 0.052ns
Data Path Delay: 2.601ns (Levels of Logic = 1)(Component
delays alone exceeds constraint)
Clock Path Skew: -1.852ns (-3.265 - -1.413)
Source Clock: DDR/mem_ui_clk rising at 1386.666ns
Destination Clock: AC/mclk_pre rising at 1386.718ns
Clock Uncertainty: 0.490ns
Mit FiFo liegt die Timing-Violation im Datenpfad durch das FiFo,
verschwindet aber nicht.
Welche Art von Constraint wäre zur Auflösung der Violation angebracht?
Xilinx Timing Closure Guide (UG-612) erwähnt "Multi-Cycle Constraints"
und "Slow Exceptions" - aber so richtig schlau werde ich aus der
Beschreibung dort nicht?
Burkhard K. schrieb: > Neben der System-Clock mit 100 MHz benutze ich eine weitere, daraus > synchron Nun ja, "synchron" wäre für mich so ziemlich das letzte Attribut, das mir dazu einfiele ;) Du brauchst einen Dual-Clock FIFO und solltest dann (per set_false_path oder clock groups) den Timing-Pfad auftrennen.
Schau dir mal die Waveforms nach einer längeren Zeit an. Die laufen auseinander. Man kann diese fast wie asynchrone betrachten. Allein die Frequenzstabilität bleibt dir.
Burkhard K. schrieb: > Welche Art von Constraint wäre zur Auflösung der Violation angebracht? TIG - Timing Ignore, da du dich um das Clock Crossing selbst kuemmerst.
Markus F. schrieb: > Nun ja, "synchron" wäre für mich so ziemlich das letzte Attribut, das > mir dazu einfiele ;) Sollte nur darauf hinweisen, dass der Takt On-Chip, also nicht extern erzeugt wurde. Markus F. schrieb: > Du brauchst einen Dual-Clock FIFO und solltest dann (per set_false_path > oder clock groups) den Timing-Pfad auftrennen. False-Path ist dasselbe wie ein Timing-Ignore-Constraint? Bringt das nur den Fehler zum Verschwinden - oder gibt es noch weitere Auswirkungen auf das Routing/Timing? Wie beschrieben hatte ich es schon mit dem FiFo-Core von Xilinx versucht, aber das brachte die Violation nicht weg - allerdings ohne false-path Constraint. da ich annahm, dass der bei einem IP-Core mit Synch-Stufe dabei sein sollte.
Kannst du nicht den Systemtakt auf 102,4MHz hoch schrauben? Dann löst sich das Problem in Wohlgefallen auf
Burkhard K. schrieb: > False-Path ist dasselbe wie ein Timing-Ignore-Constraint? Bringt das nur > den Fehler zum Verschwinden - oder gibt es noch weitere Auswirkungen auf > das Routing/Timing? ja, ja und ja. Der Router muss sich dort keine Mühe mehr geben, da dort folglich keine Timinganfordernungen mehr gelten. Du musst nun selber Logik einfügen. 4-Phasen-Handshake mit Synchronizer wäre ein allgemeiner Ansatz. Für mehr Kontrolle würde ich ein set_max_delay stets vorziehen.
Klakx schrieb: > Für mehr Kontrolle würde ich ein set_max_delay stets vorziehen. set_max_delay braucht in diesem Fall ein -datapath_only, und das gibt's - soweit ich weiss - nur bei Xilinx.
Markus F. schrieb: > - soweit ich weiss - nur bei Xilinx. Und bei Lattice Klakx schrieb: > Du musst nun selber > Logik einfügen. 4-Phasen-Handshake mit Synchronizer wäre ein allgemeiner > Ansatz. Das wäre auch der Ansatz, den ich verfolgen würde. Eventuell reicht auch ein einfacherer Handshake. Aber das hängt vom Design ab. Die Handshakesignale könnten dann über set_max_delay constrained werden oder über ein multicycle-constraint. Oder eben, wie ich bereits erwähnte, den Systemtakt doppelt so hoch, wie den Audio-Takt wählen.
Wenn das Zieldevice nur mit (in etwa) dem halben Systemtakt läuft, würde ich mir keine Gedanken machen und den Timing-Pfad einfach auftrennen. Dafür wird's wohl immer reichen.
Markus F. schrieb: > würde > ich mir keine Gedanken machen und den Timing-Pfad einfach auftrennen. > Dafür wird's wohl immer reichen. Das ist aber stark abhängig von der Architektur, die gewählt wurde. Geht man über Handshakes, dannn muss schon sichergestellt sein, dass der Skew zwischen Daten und HS so ist, dass sichergestellt ist, dass am Ziel zuerst die Daten und dann ein Data-Valid ankommt. Annahme: Quell-Domain (100MHz) legt Daten an und einen Takt später ein DV (DataValid). Nun muss das Routing sicherstellen, dass aufgrund eines Skews das DV nicht plötzlich VOR den Daten in der Ziel-Domain ankommt. Bei 100MHz wäre das ein maximaler Skew von 10ns. Sollte normalerweise passen.. Aber ich würde auf jeden Fall nach PaR nen Blick auf die Pfade werfen und mich vergewissern, dass dem auch so ist.
Danke soweit für alle Hinweise. Schlumpf schrieb: > Kannst du nicht den Systemtakt auf 102,4MHz hoch schrauben? > Dann löst sich das Problem in Wohlgefallen auf Ja und Nein - Nessi taucht dann an einer anderen Stelle wieder auf (ADC- und Codec-Samplerate stünden dann nicht mehr in einem ganzahligen Verhältnis zueinander, der Frequenzähler müsste von 1024 auf 1000 ms umrechnen usw. ...) Markus F. schrieb: > set_max_delay braucht in diesem Fall ein -datapath_only, und das gibt's > - soweit ich weiss - nur bei Xilinx. Bin auf Xilinx unterwegs (Nexys4-DDR). Allerdings verstehe ich (noch) nicht, wie ein max_delay weiterhelfen könnte? Schlumpf schrieb: > Geht man über Handshakes, dannn muss schon sichergestellt sein, dass der > Skew zwischen Daten und HS so ist, dass sichergestellt ist, dass am Ziel > zuerst die Daten und dann ein Data-Valid ankommt. Grundsätzlich könnte der Handshake recht simpel ausfallen: Die Daten werden per fallender Flanke der LRCLK des Audio-Codecs aus der 100MHz Domäne angefordert, diese hat dann bis zur nächsten, steigenden Flanke der LRCLK Zeit Daten zu liefern (je nach gewählter Samplerate mindestens 50 Takte). Soweit das Sunny-Day Szenario. Leider ist die Leselatenz des DDR2-RAMs nicht vorhersehbar. Zwar brauchen 90 % aller Reads weniger als 350 ns, Ausreisser nach oben sind immer dabei. Also werde ich wohl doch wieder ein FiFo dazwischenschalten - aber diesmal ein Modul aus der gh_vhdl_lib (kommt mit 4 Memory-Locations aus).
:
Bearbeitet durch User
Burkhard K. schrieb: > Bin auf Xilinx unterwegs (Nexys4-DDR). Allerdings verstehe ich (noch) > nicht, wie ein max_delay weiterhelfen könnte? Wie oben schon (mehrfach) geschrieben, erfordert der Taktdomänenübergang am Dual-Clock FIFO ein Auftrennen des Timing Paths per set_false_path oder set_clock_groups. Der Fitter kann dann dort (eigentlich) machen was er will, auch die Daten einmal im Kringel ums FPGA rumführen (macht er nicht). Will man darüber die Kontrolle behalten, kann man mit set_max_delay -datapath_only wieder ein Constraint draufsetzen, das ohne Berücksichtigung des Clock Skew eine maximale Verzögerung der Daten an dieser Stelle constrained.
Man kann ein Dual-Clock-FIFO auch auf das Kleinstmögliche reduzieren, eines mit einem Wort Tiefe (simples Register). Von den Gray-Code-Schleppzeigern bleibt somit nur ein einzelnes Bit übrig - 1-bittiger Gray-Code sozusagen und vorausgesetzt, man benötigt keine Überlauferkennung, nur empty und not empty. Handshake (also mit Rückmeldung) ist überhaupt nicht nötig. Wie weiter oben erklärt, muss die Zeigerabfrage (if get /= put) um mindestens einen halben des schnelleren Clocks verzögert werden, damit die (neuen) Daten sicher gültig sind. Dazu tastet man das put 180° vorher ab.
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.