Was Timing Constraints angeht bin ich noch ein voll-noob. Ich möchte nun feststellen, ob ein TimingConstraint für eine bestimmte Baugruppe tatsächlich greift. Dazu hätte ich gerne (in Verilog) Testsignale erzeugt, zwischen denen eine von mir spezifizierte Verzögerung besteht. Wenn ich diese Verzögerung dann zu groß setzte, muss der Timig-Checker anspringen. Hat jemand sowas schon mal gemacht?
Also Du willst herausfinden, ob Deine Timing-Constraints tatsächlich eingehalten werden und dazu ein (FPGA?)-Modul bauen, das das Timing überwacht? Ist das richtig?
Du meinst sicherlich Timing Checks wie $setuphold. Die kannst du natürlich auch mit falschem Timing testen.
Also Du willst herausfinden, ob Deine Timing-Constraints tatsächlich eingehalten werden und dazu ein (FPGA?)-Modul bauen, das das Timing überwacht? Ist das richtig? Nein, anders: Ich schreibe TimingConstraints und bin mir nicht sicher, dass ich diese richtig gesetzt habe. Deshalb möchte ich gewollt Signale erzeugen, die diese Constraints verletzen, um zu sehen, ob die Constraints tatsächlich anschlagen.
Du kannst einfach das Constraint so setzen das es nicht eingehalten werden kann, dann sollte es anschlagen.
Manche Clocks kommen bei mir aus einer PLL. Da kann ich die Periode eines Signals nicht so einfach einstellen, um damit eine Constraint zu triggern. Solche Constraints wollte ich auch irgendwie testen.
Du willst eine Timing-Violation haben? Ich kann dir ein paar von meinen günstig abgeben; die wollte ich sowieso längst mal loswerden ;)
"Du willst eine Timing-Violation haben?" Ja, zu Testzwecken. Einen Spannungsprüfer muss man vor Gebrauch ja auch testen. So möchte ich meine Constraints testen....
Martin O. schrieb: > Nein, anders: Ich schreibe TimingConstraints und bin mir nicht sicher, > dass ich diese richtig gesetzt habe. Deshalb möchte ich gewollt Signale > erzeugen, die diese Constraints verletzen, um zu sehen, ob die > Constraints tatsächlich anschlagen. Ah, ok. Aber was bedeutet "anschlagen"? Ein Timing-Constraint ist ja kein Alarm, der ausgelöst wird, wenn das Timing verletzt wird, sondern eine Vorgabe an den Toolflow, für die Einhaltung der Constraints zu sorgen. Es gibt keine deterministische Methode, um eine Timingviolation im laufenden Betrieb zu detektieren. Wenn z.B. eine Setupzeit unterschritten wird, kann es sein, dass das FF den neuen Wert nicht übernimmt, nur manchmal übernimmt, falsch übernimmt oder metastabil wird. Nichts davon kannst Du im Betrieb detektieren und auf eine Setup-Violation zurückführen (außer du machst so abgefahrene Sachen wir Triple Modular Redundancy, aber ich vermute, Du machst kein Spacegrade-Design). Es gibt keine Timing-Checker im laufenden Betrieb. Der übliche Weg ist, dass Du ein Constraint vorgibst (z.B. die Clockperiode) und die Tools dann versuchen, ein Design zu erzeugen, das diese Constraints einhält. Ob das funktioniert oder nicht, sagt dir dann das Lich... äh, der Timingreport. Wenn der Timing-Analyzer keine Violation findet, kannst Du davon ausgehen, dass alles passt. Dass diese Constraints eingehalten werden, sollten die Tools garantieren. Vielleicht habe ich noch nicht verstanden, was Du vor hast, aber für mich klingt das so: Du baust eine Garage die lang genug ist für Dein Auto. Dann willst Du testen, ob die Garage die richtige Länge hat, indem du immer größere Autos rein stellst und schaust, wann das Tor nicht mehr zu geht. Das ergibt irgendwie keinen Sinn. Sprichts Du eigentlich von einer Timingsimulation? Oder einem FPGA? Oder einem Chipdesign?
Eingangssignale kannst du verzögern
1 | assign #5 out = in; |
An deinen Eingängen sollte dann zum Testen noch $setup und $hold hängen.
"Vielleicht habe ich noch nicht verstanden, was Du vor hast, aber für mich klingt das so: Du baust eine Garage die lang genug ist für Dein Auto. Dann willst Du testen, ob die Garage die richtige Länge hat, indem du immer größere Autos rein stellst und schaust, wann das Tor nicht mehr zu geht. Das ergibt irgendwie keinen Sinn." Guter Vergleich. Ich baue eine Garage, von der ich glaube, dass Sie so und so gross ist. Mein Auto passt in die Garage, aber ich weiss nicht, wie gross sie wirklich ist. Weil Constraints für mich aber noch neu sind, will ich jezt nachmessen, ob die Grenzen tatsächlich richtig eingestellt sind.
:
Bearbeitet durch User
Wahrscheinlich hast Du deine I/O-Pins mit set_input_delay und set_output_delay constrained. Deren -min/-max-Parameter legen das Zeitfenster fest, das deine externe Beschaltung für die interne Verarbeitung übrig lässt. set_input_delay ... -max xxx sagt demnach, dass die Signalflanke maximal xxx ns nach der Clock kommt, -min entsprechend, dass sie frühestens xxx ns nach der Clock kommt. Machst Du also -max grösser und -min kleiner, verkleinerst Du das "Fenster" innerhalb der deine "innere" Schaltung fertig werden muss um die äusseren Anforderungen zu erfüllen und machst es entsprechend für den Fitter schwieriger, die Constraints einzuhalten (bis es irgendwann zur Timing Violation kommt). Umgekehrt beim Output: set_output_delay -max xxx ist die Setup-Zeit deines externen Registers, das Du bedienst (+ Signallaufzeit), -min die Hold-Zeit. Entsprechend kannst Du auch hier das Timing-Fenster enger machen. Das sind eigentlich schon die wesentlichen Beeinflussungsmöglichkeiten. Innerhalb des FPGAs sind dem Fitter alle Delays und Uncertainties aus der Netzliste und seinen Infos über den Chip bekannt, alles was er tun kann, ist an den kritischen Schaltungsteilen durch mehr oder weniger geschicktes Umplatzieren nach möglichen kürzeren Signalwegen zu suchen. Wenn's dann immer noch nicht reicht, kannst Du - wenn Du dein Design gut genug kennst - mit Multicycles für "Entspannung" sorgen. Der Timing-Analyzer geht immer davon aus, dass Daten aus einer Verarbeitung an der "naheliegensten" (also üblicherweise nächsten) Clock-Edge bereit stehen müssen. An manchen Stellen kann es ausreichend sein, wenn sie erst an der "übernächsten" Flanke (oder gar noch später) ankommen, entsprechend kannst Du da für Entspannung sorgen. Was Du hier an Margin gewinnst, kann der Fitter evt. an anderer, kritischerer Stelle zur Optimierung nutzen. Üblicherweise geht's beim Constrainen nicht darum, eine Timing Violation zu erzeugen, sondern sie loszuwerden. Deshalb meine flapsige Bemerkung oben. Was Du machen willst, ist eigentlich eher unüblich ;)
Martin O. schrieb: > Ich baue eine Garage, von der ich glaube, dass Sie so > und so gross ist. Wenn Du ein entsprechendes Constraint vorgibst, dann ist sie mindestens so groß. Falls sie das aus irgendwelchen Gründen nicht sein kann, dann sagt Dir das der Timingreport. > Mein Auto passt in die Garage, aber ich weiss nicht, > wie gross sie wirklich ist. Richtig, aber wozu willst Du das wissen? Ich meine, was bringt Dir die Erkenntnis, dass die Garage 10cm länger ist, als notwendig? Dein Auto ist der Anwendungsfall, für den die Garage gebaut wurde. Wenn es einen anderen Anwendungsfall gäbe, müsstest Du die Constraints ändern und eine neue Garage bauen. Der Headroom, den Dein Design oberhalb der Constraints noch hat, ist keine Größe, auf die Du Dich verlassen kannst. Der nächste Implementierungsdurchlauf kann mit den gleichen Constraints zu einem anderen Headroom führen. Wenn Du also erwartest, mal ein größeres Auto in die Garage zu stellen, musst Du sie von Anfang an größer constrainen. > Weil Constraints für mich aber noch neu > sind, will ich jezt nachmessen, ob die Grenzen tatsächlich richtig > eingestellt sind. Verstehe ich. Aber mach Dir klar, was Constraints eigentlich sind. Sie ergeben sich aus den Anforderungen und sie werden entweder eingehalten, oder nicht, und wenn nicht, steht das im Report. Das "Nachmessen" der Constraints im fertigen Design ist erstens nicht möglich und zweitens nicht sinnvoll. Stell Dir mal vor, ein Chipdesigner könnte sich nicht auf die Einhaltung der Constraints verlassen. Wie soll man da ein Design machen? Die Tools können Dir sogar sagen, wie groß der Headroom ist. Wenn Du Dein design für sagen wir 100Mhz constrainst, dann schaffen die Tools meistens eine etwas höhere Frequenz, bei der das ganze noch funktionieren würde. Und der Timingrpeort sagt Dir auch, viel höher.
Martin O. schrieb: > Hat jemand sowas schon mal gemacht? Ich habe das mal umgekehrt gemacht: Ich wollte wissen, ob ich für eine externe Baugruppe das Timing einhalte. Dazu habe ich die Werte aus dem Datenblatt genommen und für jeden Check (cycle time, setup time, hold time) einen eigenen Prozess im Modell angelegt:
1 | time_check_sclk_cycle_time: process |
2 | variable change: time; |
3 | variable diff : time; |
4 | begin
|
5 | wait until rising_edge(sclk); |
6 | change := now; |
7 | |
8 | wait until rising_edge(sclk); |
9 | diff := now - change; |
10 | |
11 | assert diff >= t_sck |
12 | report me_c & " SCLK cycle time to short: " & image( diff) |
13 | severity error; |
14 | end process; |
Duke
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.