Ich realisiere IIR Filter mit dem red Pitaya (Zynq7010). Die Filter arbeiten mit einer Abtastrate von 125MHz=8ns Takt. Laut VIVADO habe ich eine timing-violation und der krit- Pfad hat eine Länge von 9.5 ns ( d.h. 1.5ns zu langsam). Der krit. Pfad besteht aus 7 CARRY4 units gefolgt von einem DSP48 Multiplizierer gefolgt von nochmal 7 CARRY4 units. Die CARRY4 chains stammen aus 25 Bit Addierern. Der krit. Pfad besteht also aus Addition+Multiplikation+Addition. Wenn ich das Filter mit Testsignalen teste, scheint es erstaunlicherweise einwandfrei zu funktionieren. Ich frage mich warum. Mögliche Ursachen sind: a) Die Pfadberechnung von VIVADO ist pessimistisch, und in Wirklichkeit ist der krit. Pfad kürzer als 8ns. b) Die Daten bei den Filtertests führen gar nicht dazu, dass der krit. Pfad eine Rolle spielt. c) Die Berechnungen sind tatsächlich teils fehlerhaft, aber die Fehler sind so klein oder selten, dass man sie beim Filtertest nicht bemerkt. Was glaubt ihr ist der Grund? Gibt es weitere Theorien? Wie konstruiert man zu einem kritischen Pfad Testdaten, die den krit. Pfad benutzen?
a) = sehr wahrscheinlich b) = durchaus möglich c) = durchaus möglich d) Weitere Möglichkeit: Dein Design ist an dieser Stelle unkritisch, da du z.B. die Daten nicht beim nächsten Takt verwendest, sondern ein Steuersignal hast, welches dazu führt, dass da ein Takt "Luft" entsteht. Sowas könnte man dann durch mit einem Multicycle-Constraint "entspannen".. Aber das ist natürlich abhängig von deinem Design. Btw: Ich habe oft während der Entwicklungsphase irgendwelche Zwischenstände meines Designs am Laufen, die Timing-Errors aufweisen und habe mir nie nen Kopf darüber gemacht, warum es trotzdem lief. Sondern eher im Hinterkopf behalten, dass ich mich nicht wundere, falls es NICHT läuft. Für das endgültige Design habe ich dann natürlich schon geschaut, dass es keine Timing-Errors mehr gibt.
Martin O. schrieb: > a) Die Pfadberechnung von VIVADO ist pessimistisch, und in Wirklichkeit > ist der krit. Pfad kürzer als 8ns. äußerst wahrscheinlich. Der Pfadberechnung ist für die kleinste erlaubte Betriebsspannung bei gleichzeit höchster Temperatur durchgeführt. Beide Punkte sind bei der Entwicklung eher unüblich. In diesem Fall hilft es meist, den FPGA deutlich zu erhitzen, um das Fehlverhalten zu provozieren.
Martin O. schrieb: > a) Die Pfadberechnung von VIVADO ist pessimistisch, und in Wirklichkeit > ist der krit. Pfad kürzer als 8ns. Die signallaufzeit ist von der Die- temperatur und der Corespannung abhängig. Die Timing-analyse läuft da meist unter worst case (Corespannung unteres Limit, Temp kurz vor Maximum) während das target im grassgrünen bereich (alles easy spannung und T im Otpimum) läuft. Für die timinganalyse sollte man die zu verwendete Temp. und die Corespannung angeben können zumindest als best Case Worst case scenario. Lass mal best case durchrechnen. Und selbst bei verletzten timing (Hold und setup) muss nicht gleich das FF schlagartig falsche Werte speichern. Die Wahrscheinlichkeit für fehler steigt eben. Und selbst das kann man in grenzen abmildern. bspw. durch Gray statt binary counter. Frag mal einen Overclocker woran er erkennt das der Chip wirklich am Limit taktet.
Ein weiterer Grund könnte der Speedgrade Deines FPGA sein. FPGA Hersteller garantieren typischerweise eine Mindestgeschwindigkeit. Gibt es beispielsweise die Speedgrades 1,2,3 wobei 3 der langsamste sei, kann es durchaus sein, dass Du ein Speedgrade 1 oder 2 Baustein bekommst, auf dem dann Speedgrade 3 draufsteht. In Deinem Timing Report findest Du typischerweise auch, bei welchem Baustein der Worst Case auftritt. Gruß FPGA-Ing
Fpga I. schrieb: > Gibt es beispielsweise die Speedgrades 1,2,3 wobei 3 der langsamste sei, > kann es durchaus sein, dass Du ein Speedgrade 1 oder 2 Baustein > bekommst, auf dem dann Speedgrade 3 draufsteht. Na, DAS möchte ich ja mal erleben! Ist ja dank der Label-Fälscher eher anders herum. Kann es sein, dass die Timings aufgrund der Neuheit bei Vivado sehr pessimistisch ausgelegt sind?
Also diese Timings sind ja meistens für den worst case ausgelegt. Also z.B. bei maximaler Temperatur. Es kann schon sein, wenn du den FPGA mit 85° (oder wie hoch auch immer) betreibst, dass du dann Fehler bekommst. Bei Raumtemperatur spielen ein paar Prozentkeine große Rolle.
Wie groß sind denn da überhaupt die Unterschiede? Da ich wirksam die Temperatur eines FPGAs steuern konnte und es der Synthese mitgegeben hatte, tat sich nicht viel. Konkret hatte ich mal die Temperatur des FPGA auf maximal 50 Grad limitieren können, weil er in einem gekühltem System mit maximal 20 Grad läuft (25 Übertemperatur gemessen) aber es sprangen keine 10% Frequenzreserve raus - von wegen FFs einsparen oder kleineren SpeedGrade nehmen.
FPGA-Ingenieur schrieb im Beitrag #4347415: > aber es sprangen keine 10% Frequenzreserve raus Selektier neben der tieferen Temperatur auch gleich auch das Device mit dem langsameren Speedgrade und schau was die Synthese meint. Wenn Du nur die Temperatur anpasst, muss ich der Fitter einfach weniger Mühe bei der Optimierung geben (wenn das Ziel, sprich Timing Closure, erreicht ist, macht das Tool nicht mehr weiter auch wenn noch Reserve wäre).
FPGA-Ingenieur schrieb im Beitrag #4343471: > Fpga I. schrieb: >> Gibt es beispielsweise die Speedgrades 1,2,3 wobei 3 der langsamste sei, >> kann es durchaus sein, dass Du ein Speedgrade 1 oder 2 Baustein >> bekommst, auf dem dann Speedgrade 3 draufsteht. > > Na, DAS möchte ich ja mal erleben! Ist ja dank der Label-Fälscher eher > anders herum. Das ist gängie Praxis bei den Halbleiterherstellern. Du fertigst einen Type und misst dann aus, wie schnell der kann. Wenn deine Ausbeute gut ist, könntest du mehr auf Speedgrade 1 labeln als du von dem Speedgrade verkaufen könntest, was machst du also: Du labelst die als Speedgrade 2 und so weiter...
genervt schrieb: > Du fertigst einen Type und misst dann aus, wie schnell der kann. Njein, es wird nicht gemessen wie schnell der Chip ist sondern es wird getestet ob er die Prüfung für den bestimmten speedgrad besteht. werden also 10k St. -2 und 100k-1 gefordert wird solange auf -2 getestet bis die 10k aussortiert sind, dann nur noch auf -1. So ein Test braucht auch seine Zeit, die spart man sich. und so gelangen einige -2 chip die als -1 gelabelt sind auf den markt. Blöderweise weiss man nicht ob jetzt der -1 einer ist der beim -2 Test aussortiert wurde oder nie auf -2 getestet wurde. Oder wie oben beschrieben marketingtechnisch ge-down-gradet wurde. MfG,
FPGA-Ingenieur schrieb im Beitrag #4343471: > Fpga I. schrieb: >> Gibt es beispielsweise die Speedgrades 1,2,3 wobei 3 der langsamste sei, >> kann es durchaus sein, dass Du ein Speedgrade 1 oder 2 Baustein >> bekommst, auf dem dann Speedgrade 3 draufsteht. > > Na, DAS möchte ich ja mal erleben! Ist ja dank der Label-Fälscher eher > anders herum. Das habe ich aber auch schon mehrmals gelesen. Stell dir folgendes vor: Der Hersteller bekommt bei der Fertigung 50% Speedgrade A (langsam) und 50% Speedgrade B (schnell) heraus. Die Käufer kaufen nun aber 75% Speedgrade A und nur 25% benötigen wirklich Speedgrade B. Was machst du jetzt? Letztendlich hättest du sehr viele Speedgrade B Chip übrig, bei Speedgrade A kannst du nicht liefern. Also druckst du einfach Speedgrade A auf die schnelleren Chips drauf. Denn es ist ja nur spezifiziert, wie schnell der Chip MINDESTENS ist. Die Beobachtung des OPs, das Design läuft trotz Timing-Violations, hatte ich auch schon zahlreiche Male während der Entwicklung. Ist also durchaus "normal" dass es in Grenzen gut funktioniert.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.