Forum: FPGA, VHDL & Co. Synchrone Taktdomänen 100/51.2 MHz - Requirement 0.052 ns


von Burkhard K. (buks)


Lesenswert?

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?

von Markus F. (mfro)


Lesenswert?

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.

von Klakx (Gast)


Lesenswert?

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.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

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.

von Burkhard K. (buks)


Lesenswert?

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.

von Schlumpf (Gast)


Lesenswert?

Kannst du nicht den Systemtakt auf 102,4MHz hoch schrauben?
Dann löst sich das Problem in Wohlgefallen auf

von Klakx (Gast)


Lesenswert?

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.

von Markus F. (mfro)


Lesenswert?

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.

von Schlumpf (Gast)


Lesenswert?

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.

von Markus F. (mfro)


Lesenswert?

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.

von Schlumpf (Gast)


Lesenswert?

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.

von Burkhard K. (buks)


Lesenswert?

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
von Markus F. (mfro)


Lesenswert?

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.

von dfIas (Gast)


Lesenswert?

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.

Bitte 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
Noch kein Account? Hier anmelden.