TestSignale gesucht um TimingConstraint zu testen

[Martin O. (ossi-2)]

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?

[Vancouver (Gast)]

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?

[Erik (Gast)]

Du meinst sicherlich Timing Checks wie $setuphold.
Die kannst du natürlich auch mit falschem Timing testen.

[Martin O. (ossi-2)]

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.

[user (Gast)]

Du kannst einfach das Constraint so setzen das es nicht eingehalten 
werden kann, dann sollte es anschlagen.

[Martin O. (ossi-2)]

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.

[Markus F. (mfro)]

Du willst eine Timing-Violation haben?

Ich kann dir ein paar von meinen günstig abgeben; die wollte ich sowieso 
längst mal loswerden ;)

[Martin O. (ossi-2)]

"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....

[Vancouver (Gast)]

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?

[Klakx (Gast)]

Eingangssignale kannst du verzögern

assign #5 out = in;

An deinen Eingängen sollte dann zum Testen noch $setup und $hold hängen.

[Martin O. (ossi-2)]

"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.

[Markus F. (mfro)]

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 ;)

[Vancouver (Gast)]

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.

[Duke Scarring (Gast)]

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:

    time_check_sclk_cycle_time: process
        variable change: time;
        variable diff  : time;
    begin
        wait until rising_edge(sclk);
        change := now;

        wait until rising_edge(sclk);
        diff := now - change;

        assert diff >= t_sck
            report me_c & " SCLK cycle time to short: " & image( diff)
            severity error;
    end process;

Duke