Jitter-Simulation in FPGAs

[Weltbester FPGA Pongo (Gast)]

Wie realisiert ihr die Berücksichtigung von Jitter in FPGAs, speziell 
bei der Analyse von clock domain crossing?

Hatte die Tage eine ernste Diskussion in einem "Expertenkreis" und wie 
immer bei Ingenieren im FPGA-Umfeld gab es bei 5 Leuten am Ende 10 
Meinungen.

Die Ideen rangierten von "gar nicht" über "macht doch das Tool" bis 
"einfach alles auf höheren Frequenzen bauen". Einige verwenden spezielle 
Jitter-Generatoren für ihre Takte, um doe zahllosen Situationen von 
möglichen Übergängen zu simulieren. Ging so in Richtung Monto Carlo 
Analysen.

[Falk B. (falk)]

@ Weltbester FPGA Pongo (Gast)

>Wie realisiert ihr die Berücksichtigung von Jitter in FPGAs, speziell
>bei der Analyse von clock domain crossing?

Wahrscheinlich gar nicht, weil asynchrone Takte so oder so undefinierte 
Phasenbeziehungen haben. Alle gängigen Techniken berücksichtigen das.

>Die Ideen rangierten von "gar nicht"

Jain.

>über "macht doch das Tool" bis

Nein.

>"einfach alles auf höheren Frequenzen bauen".

Nein.

> Einige verwenden spezielle
>Jitter-Generatoren für ihre Takte, um doe zahllosen Situationen von
>möglichen Übergängen zu simulieren.

Kann man machen, bringt real eher wenig. Wenn, dann muss man das live 
testen, denn dort kann man millionenfach schneller bzw. mehr testen.

> Ging so in Richtung Monto Carlo Analysen.

In Monte Carlo sollte man andere Dinge tun als analysieren ;-)

[Weltbester FPGA Pongo (Gast)]

das war jetzt leider ein sehr unbefriedigender Beitrag zumal Du Dir mit:

>Alle gängigen Techniken berücksichtigen das.

und

>>über "macht doch das Tool" bis
> Nein.

auch zu widersprechen scheinst.

Fangen wir noch mal vorne an: Welche Techniken der Jitter-Simuation 
verwendet ihr:

[Duke Scarring (Gast)]

Weltbester FPGA Pongo schrieb im Beitrag #4308530:
> Welche Techniken der Jitter-Simuation
> verwendet ihr:
Bei Xilinx wird in der statischen Timing-Analyse der Jitter 
berücksichtigt.
Die allermeisten Nutzer werden die Standardwerte nehmen. Nur wenige 
werden dort reale Messwerte berücksichtigen, schon alleine weil das 
Equipment für Jittermessungen nicht in jedem Labor steht.

Von daher: Bei mir wird Jitter nicht mit simuliert, sondern maximal im 
Nachgang gemessen.

Duke

[Klakx (Gast)]

Falk B. schrieb:
> Wahrscheinlich gar nicht, weil asynchrone Takte so oder so undefinierte
> Phasenbeziehungen haben. Alle gängigen Techniken berücksichtigen das.

so ist es. Beim Asynchronen sampeln kannst du eh nicht sagen, ob du vor 
oder nach der Flanke absampelst.

Vielleicht ist die Frage auch falsch? Jitter ist relevant für synchrone 
Taktübergänge. Höherer Jitter ist in der STA unter Clock uncertainty mit 
berücksichtigt bzw. sollte dort berücksichtigt werden. Der Jitter 
verringert damit das mögliche sichere Zeitfenster zur Übernahme des 
Flipflops.

[Sigi (Gast)]

Weltbester FPGA Pongo schrieb im Beitrag #4308479:
> Wie realisiert ihr die Berücksichtigung von Jitter in FPGAs, speziell
> bei der Analyse von clock domain crossing?

Welche Analyse: Timing, Simulation etc.?

Timing: Zwischen internen sync. Übergängen analysiert das
Synt.Tool Jitter automatisch, laufen Signale von Aussen
ins FPGA, dann muss der komplette Datenweg per Constraints
spezifiziert werden.
Zwischen async. Übergängen verweigert das Tool idR die Analyse,
gibt idR eine entsprechende Message aus. Abhilfe: TIG Constraint.

Simulation: Jitter wird nicht berücksichtigt (<=Delta-Zyklus
Mechanismus). Du kannst aber eigene Register modelieren,
die auf Jitter und Setup/Hold "richtig" reagieren.

> ... . Einige verwenden spezielle
> Jitter-Generatoren für ihre Takte, um doe zahllosen Situationen von
> möglichen Übergängen zu simulieren. Ging so in Richtung Monto Carlo
> Analysen.

Hab ich auch mal spasseshalber gemacht: Je MC-Pfad einen
Zeitabschnitt, der mit zufälligen Clock-Zuständen beginnt.
Dann eine Weile zufallsgesteuert laufen lassen und die
Signalübergänge auswerten. Nach einer Weile wird dann ein
neuer Pfad aufgesetzt, indem beide Clocks wieder neu
gestartet werden. Das eignet sich aber nur zur Beobachtung
von async. Übergängen, nicht aber zur Analyse ganzer Systeme.

Je Pfad kann dann analysiert werden, wie "weit" man von
einem "ungünstigen" Fall entfernt ist etc. War bei mir
hilfreich bei der analyse von Handshacke-Protokollen.
Je Pfad habe ich eine kleine Info in ein Textfile ausgegeben
und später graphisch ausgewertet.

[J. S. (engineer)]

Eine Möglichkeit ist es, den Verlauf der Takte dreiecksförmig "Jittern" 
zu lassen, d.h. es erfolgt eine Phase der Beschleunigung und des 
Bremsens und dann umgekehrt. Damit entstehen Taktvorlauf und -nachlauf. 
Mit einer sinnvollen Einstellung diesbezüglich bei allen Takten kann man 
alle prinzipiellen Konstellationen der Takte zueinander abklappern. Die 
andere Option ist, dass ein Takt permanent etwas schneller läuft, als er 
nominell spezifiziert ist, weil sie aus irgendwelchen Quarzen kommen.

Diese Betrachtungen haben Auswirkungen auf die benötigten minimalen 
FiFo-Längen bei asynchroner Übergabe von Daten, wenn sich Takte nicht 
sehr strak unterscheiden. Theoretisch lässt sich das alles natürlich 
auch rechnerisch lösen, um es zu designen, aber ein formeller Beweis der 
Extremfälle ist eben nur möglich, wenn man ihn praktisch auch 
nachstellt.

Damit hat man auch gleich eine Dokumentation dieser Fälle, wenn es in 
bestimmten Branchen nötig ist, diesen formellen Beweis anschaulich zu 
führen. Im Prinzip lässt sich natürlich auch dass alles wider mit 
Diagrammen aufzeigen und veranschaulichen. Aber oft finde ich es 
einfacher, eben mal schnell die Takte zu verstellen und sich den Fall in 
der Simulation zu suchen, bzw ihn zu provozieren. ModelSim "malt" das 
Timing-Diagramm dann automatisch und ich habe in Nullkommanix einen 
Sreenshot für die Doku.