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?
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.
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.
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.
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.
Du kannst mit x% höherer Frequenz synthetisieren...aber ich würd's lassen, solange du das Timing triffst ist alles gut!
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.
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.
:
Bearbeitet durch User
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.
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.
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.
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.
:
Bearbeitet durch User
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.
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.
:
Bearbeitet durch User
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.
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!
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.
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.
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.
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.
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.
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.