Worst Negative Slack Vivado

[Gustl B. (-gb-)]

Hallo,

ich habe eine Frage zu Vivado und Timing. Ich habe ein Design und das 
läuft auch gut durch, zeigt mir aber als worst negative slack einen sehr 
kleinen Wert an, 0,182 ns. Nun ist meine Frage:

Hört Vivado mit der Optimierung auf wenn das Timing erfüllt wird? Sprich 
dann wird nicht weiter optimiert und das Ergebnis ist zwar OK aber nicht 
optimal.

Oder wird weiteroptimiert und das Ergebnis zeigt was tatsächlich möglich 
ist?

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

Gustl B. schrieb:
> Hört Vivado mit der Optimierung auf wenn das Timing erfüllt wird? Sprich
> dann wird nicht weiter optimiert und das Ergebnis ist zwar OK aber nicht
> optimal.

Exakt.

Es macht auch keine Sinn weiter zu optimieren. Der FPGA laeuft deswegen 
weder besser noch schlechter, es wird einfach nur mehr Zeit und damit 
Geld verschwendet.

[Gustl B. (-gb-)]

Danke!

[J. S. (engineer)]

Tobias B. schrieb:
> Der FPGA laeuft deswegen
> weder besser noch schlechter,
Nicht ganz. Je größer der slack, desto größer ist die Reserve gegen 
unkalkulierten Jitter infolge von Analogeffekten sowie anderen zufällige 
Störungen, sowohl bei der Taktflanke, als auch den Daten, weil das 
kritische Zeitfenster kleiner wird. Insbesondere wächst damit auch die 
Robustheit gegen metastabile Zustände.

Allerdings sind das alles Dinge, die sich schlecht quantifizieren und 
bewerten lassen, daher sind sie auch nicht Teil der konkreten 
FPGA-Spezifikation / Constraints, bzw. sie sind indirekt über Annahmen 
in den Vorgaben und Timingreserven der Tools verpackt. Beim Jitter ist 
das z.B. so ein Thema. Die Qualität der Eingangsdaten und externer Takte 
ist bei Störungen in der Realität beliebig schlecht und überschreitet 
mitunter mehr oder weniger stark die angenommenenen typischen 
Schankungen auf denen die Timingkalkulationen basieren und mit denen die 
Tools hantiern.

Praktisch ist es damit in der Tat so, dass FPGAs mit größeren 
Timingreserven in EMV-Tests, wenn man künstlich mit entsprechenden 
Feldern drauf geht, robuster sind.

[Gustl B. (-gb-)]

Nun, bei mir ist der WNS sehr gering seit ich das Projekt neu aufgebaut 
habe (gleicher Code). Dann habe ich viel ausprobiert und den größeren 
WNS im alten Projekt bekomme ich daher, weil das einen alten IP-Core 
gecached hat, also dessen Syntheseerzeugnisse. Wenn ich das neu aufbaue 
sind die nichtmehr da, der Core wird neu gebaut und es wird schlechter 
obwohl sich nichts verändert hat ausser der Vivado Version mit der der 
Core gebaut wird.

Daher die Frage:
Kann man das irgendwie constrainen, dass die Toolchain solange rechnen 
soll bis sie x ns WNS schafft oder eben nach x Minuten Rechenzeit 
aufgibt und sagt dass es nicht geht? Das wäre nämlich cool und ich habe 
ja Zeit zum Rechnen.

[Blechbieger (Gast)]

Gustl B. schrieb:
> Nun, bei mir ist der WNS sehr gering seit ich das Projekt neu aufgebaut
> habe (gleicher Code). Dann habe ich viel ausprobiert und den größeren
> WNS im alten Projekt bekomme ich daher, weil das einen alten IP-Core
> gecached hat, also dessen Syntheseerzeugnisse. Wenn ich das neu aufbaue
> sind die nichtmehr da, der Core wird neu gebaut und es wird schlechter
> obwohl sich nichts verändert hat ausser der Vivado Version mit der der
> Core gebaut wird.

Keine Ahnung ob das bei Vivado anders herum ist aber bei Quartus ist 
negativer Slack (dt. würde ich das Spielraum nennen) schlecht und 
bedeutet dass das Timing nicht eingehalten wird.

[Hallo (Gast)]

Du kannst mit x% höherer Frequenz synthetisieren...aber ich würd's 
lassen, solange du das Timing triffst ist alles gut!

[T.U.Darmstadt (Gast)]

Gustl B. schrieb:
> der Core wird neu gebaut und es wird schlechter
> obwohl sich nichts verändert hat ausser der Vivado Version mit der der
> Core gebaut wird.

Irgendwas an den globalen Einstellungen geändert - z.B. FPGA-Type?
Das hat nämlich Einfluss auf den Core und wie er gebaut wird.

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

Jürgen S. schrieb:
> Nicht ganz. Je größer der slack, desto größer ist die Reserve gegen
> unkalkulierten Jitter infolge von Analogeffekten sowie anderen zufällige
> Störungen, sowohl bei der Taktflanke, als auch den Daten, weil das
> kritische Zeitfenster kleiner wird. Insbesondere wächst damit auch die
> Robustheit gegen metastabile Zustände.

Das stimmt natuerlich. Allerdings laesst sich der Jitter auch 
quantifizieren und als System Jitter Constraint angeben.

Da der Pk-to-Pk Jitter einer Gaussverteilung folgt kann man durch Angabe 
eines erhoehten System Jitters die MTBF drastisch erhoehen. Dann hat man 
auch die Reserve parameterisierbar, was deutlich einfacher zu handhaben 
ist als sich den Slack anzuschauen und zu hoffen, dass die Tools bei 
einem Run mal mehr oder weniger rausholen.

Kleiner Tipp: Messen kann man den System Jitter indem man einen Takt auf 
einen ODDR Buffer gibt und den Jitter mittels Realtime Oszi misst.

Jürgen S. schrieb:
> Beim Jitter ist
> das z.B. so ein Thema. Die Qualität der Eingangsdaten und externer Takte
> ist bei Störungen in der Realität beliebig schlecht und überschreitet
> mitunter mehr oder weniger stark die angenommenenen typischen
> Schankungen auf denen die Timingkalkulationen basieren und mit denen die
> Tools hantiern.

Bei kritischen Eingaengen kann man auch den Jitter einzeln 
spezifizieren.

[Gustl B. (-gb-)]

So, der WNS war sehr klein und es hat manchmal dann doch nicht 
funktioniert. Jetzt habe ich testweise den Speedgrade mal eins langsamer 
eingestellt, 1 statt 2 und schon wird das Timing verletzt. Dann habe ich 
die kritischen Pfade entschärft und das WNS war wieder leicht positiv 
und besser. Dann habe ich jetzt mal Vivado 2018.3 installiert und sonst 
nichts verändert, alles neu bauen lassen und schon wurde das WNS 
deutlich besser. Statt 0,193 ns sind das jetzt 0,249 ns.

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

Gustl B. schrieb:
> So, der WNS war sehr klein und es hat manchmal dann doch nicht
> funktioniert.

Dann ist dein Design under-constraint. Ich kann dir nur waermstens 
empfehlen die STA als "Design erfuellt Bedingungen" oder "Design 
erfuellt Bedingungen nicht" zu interpretieren. Sollten damit Probleme 
auftreten sind die Timing Constraints einfach nicht ausreichend.

Die Tools rennen nur solange bis sie das Timing geschafft haben. wenn du 
jetzt herausfindest, dass ein Design Run nur funktioniert wenn du genug 
Luft nach oben hast, dann solltest du unbedingt auch diese Luftgrenze 
definieren. System und Input Jitter sind dafuer zwei hervorrangende 
Tools die dir Xilinx mitgibt und sich heute damit zu befassen spart dir 
den Aerger von morgen.

[Klakx (Gast)]

falls du noch mehr Puffer haben willst, dann setz es mit 
set_clock_uncertainty.
Prinzipiell sollte dein WNS = 0 am Ende auch abbilden, dass du es 
geschafft hast. Ich kenne das, man bekommt mal designruns mit +0.05 und 
mal mit +0.10, aber die sind beide gut genug (oder das Design ist 
falsch). Die Stellschraube setzt du am Anfang.

[Gustl B. (-gb-)]

Danke, ja das vermute ich auch, aber ich weiß nicht was ich constrainen 
soll. In das FPGA geht eine Clock rein mit 25 MHz, die ist so 
beschrieben:

set_property PACKAGE_PIN P17 [get_ports clk]
set_property IOSTANDARD LVCMOS33 [get_ports clk]
create_clock -add -name sys_clk_pin -period 40.00 -waveform {0 20} 
[get_ports clk]

Ich kann im Constraint-Editor jetzt System- und Inputjitter constrainen. 
Was sind da brauchbare Werte? Muss ich da nachgucken welchen Oszillator 
der Hersteller verbaut hat und dann im Datenblatt gucken?

Ich habe jetzt mal
set_input_jitter sys_clk_pin 0.200
gemacht. Mal gucken ob es das schafft.

[Klakx (Gast)]

Gustl B. schrieb:
> Ich kann im Constraint-Editor jetzt System- und Inputjitter constrainen.
> Was sind da brauchbare Werte? Muss ich da nachgucken welchen Oszillator
> der Hersteller verbaut hat und dann im Datenblatt gucken?

Eigentlich schon. Kannst ja mal nachschauen was der (realistisch) 
ausgeben würde. Das meiste ist in der Regel mit set_clock_uncertainty 
0.1 (ns) erledigt.
Wenn der Clock auf eine DCM/PLL geht, dann ist das sowieso nicht mehr so 
sehr wichtig. Das gibt dann die DCM/PLL hauptsächlich vor.

[Gustl B. (-gb-)]

Genau, der MMCM macht eine Constraint mit 0.4 ns als Jitter.

Gibt es eigentlich eine Reihenfolge in der Constraints abgearbeitet 
werden?

Jetzt mit
set_input_jitter sys_clk_pin 0.200
habe ich weiterhin 0.1 ns WNS bei dem langsameren Speedgrade. Da hat 
sich nichts verändert, aber es wurde länger gerechnet.

Ich habe jetzt mal noch
set_clock_uncertainty sys_clk_pin 0.200
dazugeschrieben. Mal gucken.
Am liebsten wäre mir weiterhin eine Option wie "Rechne n Stunden und hol 
raus was geht".

Edit:
Ey Xilinx, was soll der Quatsch?
set_input_jitter sys_clk_pin 0.200
set_clock_uncertainty 0.200 sys_clk_pin

Mal steht die Zeit vor der Clock, mal danach. Weia ...

Edit:
Irgendwie ist das seltsam. Ich hatte jetzt mit
set_input_jitter sys_clk_pin 0.200
set_clock_uncertainty 0.200 sys_clk_pin
einen WNS von 0.12 ns.
Dann habe ich beide Werte auf 0.5 ns erhöht und erhalte eine WNS von 
0.154 ns.

Edit:
set_input_jitter sys_clk_pin 0.750
set_clock_uncertainty 0.750 sys_clk_pin
Jetzt ist der WNS bei 0.094 ns.

Edit:
set_input_jitter sys_clk_pin 1.000
set_clock_uncertainty 1.000 sys_clk_pin
Hat eine WNS von 0.147 zur Folge. Ich verstehe nicht wirklich was ich da 
machen sollte ... vermutlich wie bei vielen Optimierungsproblemen 
einfach irgendwann aufhören. 1 ns finde ich nämlich schon ziemlich viel.

Edit:
set_input_jitter sys_clk_pin 2.000
set_clock_uncertainty 2.000 sys_clk_pin
Hat eine WNS von 0.167 ns zur Folge. Hat jetzt auch deutlich länger 
gerechnet.

[Gustl B. (-gb-)]

So, diese uncertainty finde ich ziemlich sinnfrei. Ich habe das jetzt 
mal getestet und bin jeweils von 0 bis 4 ns bei uncertainty und jitter 
durchgegangen. 4 ns uncertainty schafft das Xilinx-Tool problemlos, 4 ns 
Jitter nicht. 3 ns Jitter auch noch nicht, aber nur sehr knapp nicht. 4 
ns Jitter und sogar 1 ns Jitter sehen besser optimiert aus als 4 ns 
uncertainty.
Ich werde also in Zukunft immer den Jitter verwenden und den so 
einstellen, dass ich auf der sicheren Seite bin.

[Weltbester FPGA-Pongo (Gast)]

Gustl B. schrieb:
> So, diese uncertainty finde ich ziemlich sinnfrei.
Deren Wirkung ist eine worst case Abschätzung die du real nicht 
nachstellen kannst. Diese hart einstellen zu wollen ist sinnfrei. Wenn 
man sie anders herum ignoriert, verletzt man Sicherheitskriterien und 
muss dann das Design selber einschränken, also funktionell constrainen. 
Das kann man machen, sollte man aber nur, wenn man weiss, was man tut.

Besser ist es, man arbeitet von oben herunter und released die 
Constraints von hart nach weich, dahingehend, dass man Temperaturen und 
Spannungen einsgrenzt und nicht den theoretischen Raum belässt, der 
möglich ist.

Dann fällt die uncertainty auch entsprechend kleiner und realistischer 
aus.

> Ich werde also in Zukunft immer den Jitter verwenden und den so
> einstellen, dass ich auf der sicheren Seite bin.
Schlecht. Du solltest den Jitter so einstellen, wie er real ist oder so 
gross wie er laut SPEC ist, weil dir das nämlich die Arbeit mit dem 
Design erleichtert. Tust du das nicht, dann kann das tool dir die worst 
case Thematik nicht abnehmen und du musst selber ran.

Viel Spass!

[Gustl B. (-gb-)]

Weltbester FPGA-Pongo schrieb im Beitrag #5739012:
> Besser ist es, man arbeitet von oben herunter und released die
> Constraints von hart nach weich, dahingehend, dass man Temperaturen und
> Spannungen einsgrenzt und nicht den theoretischen Raum belässt, der
> möglich ist.

Welche Constraints soll ich releasen? Ich will etwas vorgeben, also 
constrainen damit sich die Toolchain mehr Mühe gibt. Das erreiche ich 
indem ich der mitteile, dass die Clock viel Jitter drauf hat. Wenn dann 
am Ende das Timing erfüllt wird, dann läuft das auch auf der Mardware 
mit einer Clock die weniger Jitter hat.

Weltbester FPGA-Pongo schrieb im Beitrag #5739012:
> Du solltest den Jitter so einstellen, wie er real ist oder so
> gross wie er laut SPEC ist, weil dir das nämlich die Arbeit mit dem
> Design erleichtert. Tust du das nicht, dann kann das tool dir die worst
> case Thematik nicht abnehmen und du musst selber ran.

Verstehe ich nicht. Ich stelle mehr Jitter ein als in der Realität und 
bekomme dadurch ein Design das mehr optimiert wurde als es hätte 
optimiert werden müssen. Das bezahle ich mit Rechenzeit. Den echten 
Jitter kann ich kaum herausfinden. Klar ich kann im Datenblatt von der 
Clock nachgucken, aber reicht das? Da ist noch ein Stück Leiterbahn 
dazwischen und die Versorgungsspannung ist auch nicht ideal.

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

Gustl B. schrieb:
> Den echten
> Jitter kann ich kaum herausfinden. Klar ich kann im Datenblatt von der
> Clock nachgucken, aber reicht das? Da ist noch ein Stück Leiterbahn
> dazwischen und die Versorgungsspannung ist auch nicht ideal.

Weiter oben habe ich beschrieben wie man den messen kann. Der Clock 
jitter im Datenblatt gibt nur einen Anhaltspunkt wie gross der Jitter 
ist wenn die Clock in dein FPGA eingespeist wird. Thermik, Rauschen der 
Spannungsversorgung und bei grossen Designs die zig tausende 
gleichzeitige Schaltvorgaenge (vor allembei suboptimalem PCB Design) 
sind die Faktoren die dir den Jitter nach oben treiben.

Daher wenn mal die Logik soweit funktional ist, wirklich mal hingehen 
und den Jitter messen, am besten eine Langzeitmessung machen und schauen 
wie sich der Jitter verhaelt. Den Maximalwert wuerde ich dann nehmen und 
mir daraus meine Constraints bauen.

[Gustl B. (-gb-)]

Klar kann man das messen, aber was ist denn der Nachteil einfach 
hinzugehen und einen Jitter anzugeben der sicher über dem realen Jitter 
liegt? Ausser mehr Rechenzeit kostet mich das doch nichts.

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

Gustl B. schrieb:
> Klar kann man das messen, aber was ist denn der Nachteil einfach
> hinzugehen und einen Jitter anzugeben der sicher über dem realen Jitter
> liegt? Ausser mehr Rechenzeit kostet mich das doch nichts.

Klar, wenn du dir das leisten kannst, kann man das machen. Sobald du mal 
etwas groessere FPGA Designs hast (bzw. der FPGA anfaengt voll zu 
werden), wird dir der Workflow allerdings wieder auf die Fuesse fallen.

[Gustl B. (-gb-)]

Da hast du Recht. Dann würde ich mit der Jitter soweit runter gehen, 
dass die Rechenzeit erträglich bleibt und der Jitter größer oder gleich 
dem tatsächlichen Jitter ist.

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

Und genau dann bekommst du Probleme. Irgendwann weisst du nicht mehr ob 
der angegebene Jitter ausreichend ist oder nicht. In allen 
naturwissenschaftlichen Disziplinen gilt: Nur durch Messung gibts 
Bestaetigung.

Solange du allerdings noch nicht in dem Bereich bist, ist es auch noch 
in Ordnung das Thema hinten anzustellen und mit einer Abschaetzung mit 
genuegen Reserve zu Leben. Wenn es langsam mal losgeht, dass deine 
Timings nur noch mit Jitter unterhalb einer Nanosekunde zurecht kommen, 
solltest du dir langsam mal Gedanken machen das Ganze etwas analytischer 
und quantitativer anzugehen.

Irgendwann kommt halt immer der Punkt an dem Pragmatismus einem das 
Genick brechen kann.