TimeQuest Analyzer Quartus

[Donni D. (Gast)]

Hey Leute,

ich habe ein paar kleine Fragen zum TimeQuest Analzyer, bzw generell zum 
Timing von Signalen etc. Ich habe sonst immer nur ein kleines FPGA Board 
mit nur einem Clock Eingang genutzt (z.B. DE0 Nano). Jetzt arbeite ich 
mit einem größeren Board (DE5 Net) und habe dort verschiedene IO-Bänke 
mit verschiedenen Clock Eingängen.

Da kommen natürlich direkt einige Timing Probleme auf mich zu. Einige 
davon konnte ich beheben, manche verstehe ich nicht und manche denke ich 
zu verstehen, bin mir aber bei der Behebung der Probleme unsicher. Mir 
fehlt wohl ein bisschen das Grundverständniss wie ich mit verschiedenen 
Takteingängen umgehe und diese miteinander vereine, oder eben nicht 
vereine. Deshalb stelle ich einfach mal ein paar Fragen und hoffe auf 
aufschlussreiche antworten.


1. Ich habe häufig gesehen, das die Pfade von Buttons (Reset) oder LEDs 
als false_paths angegeben werden. Damit werden sie ja Timing technisch 
nicht weiter beachtet oder? Mache ich das, da die Laufzeit dieser 
Signale unkritisch ist? Die LEDs sind jam eist eh nur Anzeige von Status 
etc und ob da einmal "unwahre" Daten ankommen wäre nicht schlimm?

2. Ich habe Signale, die in verschiedenen Taktdomänen liegen. Signal X 
wird von der Clock A gesetzt, in einem anderen Teil von Clock B gelesen 
(auch ein unkritisches Signal, ein Valid Bit). Hier bekomme ich auch 
Timingfehler. Setze ich hier auch false_paths? Bekomme sonst Setup 
Timing Fehler.

3. Zu guter letzt habe ich eine Dual Clock FIFO um Daten zwischen zwei 
Takten zu syncroniseren. Da habe ich einfach über clock_groups die 
beiden Takte (lesen und schreiben) auf komplett asyncron gesetzt und 
bekomme nun keine Fehler mehr. Ist das so richtig?

Wie man sieht, was Timing angeht habe ich leider recht wenig 
Ahnung/Erfahrung. Ich würde mich auch über generelle Informationen 
freuen wie man bei so einem Design vorgeht, wenn mehrere Takte vorhanden 
sind, worauf ich achten muss, Tipps für den Timing Analyzer etc.


Liebe Grüße

[Markus F. (mfro)]

Ob Du Taktdomänenübergänge (oder komplett asynchrone Pfade wie Reset 
oder Tastendrücke) per set_false_path, clock groups oder "lässig offene" 
Delays voneinander trennst ist, eigentlich wurscht.

Wichtig ist, dass Du sicherstellst, dass dein Design an den 
entsprechenden Stellen über geeignete Synchronisierungsmethoden (z.B. 
Synchronizer für einzelne Signale, FIFOs für Busse) verfügt, die dir 
eine solche Vorgehensweise überhaupt erlauben.

Erst damit kannst Du über das Auftrennen solcherart "entschärfter" 
Timing-Pfade (und der dadurch "gewonnenen" Timing-Margin) dafür sorgen, 
dass sich die Timing-getriebene Synthese auf die wirklich kritischen 
Pfade in deinem Design "konzentrieren" und entsprechend opimieren kann.

"Timing-Driven Design" ist eigentlich der Prozess, dem Analyzer zu 
erklären: "darum habe ich mich schon gekümmert, damit brauchst Du dich 
nicht mehr rumzuärgern".

[Donni D. (Gast)]

Markus F. schrieb:
> Wichtig ist, dass Du sicherstellst, dass dein Design an den
> entsprechenden Stellen über geeignete Synchronisierungsmethoden (z.B.
> Synchronizer für einzelne Signale, FIFOs für Busse) verfügt, die dir
> eine solche Vorgehensweise überhaupt erlauben.

Das habe ich für den Datenbus mit einer DC FIFO gemacht, scheint auch 
gut zu funktionieren. Gibt es eine Komponente die ich für einzelne 
Signale gut nutzen kann, also 1 Bit breit? Wie setze ich sowas um und 
muss ich dann weitere Timing Constrains setzen?

[Markus F. (mfro)]

Donni D. schrieb:
> Gibt es eine Komponente die ich für einzelne
> Signale gut nutzen kann, also 1 Bit breit? Wie setze ich sowas um und
> muss ich dann weitere Timing Constrains setzen?

Mach' dir eine.

Das muss zum Eintakten lediglich durch zwei (oder mehr) mit dem Takt der 
empfangenden Clock-Domain getakteten FF's durch, die metastabile 
Zustände zuverlässig verhindern. Den Timing-Pfad zum ersten FF setzt Du 
dann einfach als false_path.

Beim Übergang von einer "schnellen" zu einer "langsamen" Taktdomäne 
musst Du natürlich darauf achten, ob eine Signaländerung auf der 
"langsamen" Seite überhaupt zuverlässig wahrgenommen werden kann und 
evt. ein Hold basteln.

Weil synchrones Design zwischen Clock-Domains mit der Anzahl der 
Clockdomänenübergänge schnell unübersehbar komplex wird, heisst die 
erste Regel: vermeide CDCs, wo's geht. Das entsprechende Design, bei dem 
die "langsame Seite" über Enables in derselben Clock-Domain läuft, ist 
meist viel simpler.