Ich beschäftige mich gerade intensiver mit Timing Constraints.
Bislang waren mir die nicht so recht geheuer und ich habe immer nur das
Notwendigste gemacht, bis es eben lief, aber jetzt wollte ich mich mal
"richtig" einarbeiten (also nicht bloss irgendwie die Ports
"geradebiegen" bis das Design gerade so funzt, sondern ich hatte den
Ehrgeiz, eine simple Config vollständig zu constrainen und das auch noch
zu verstehen).
Verwendet habe ich dazu
http://www.alterawiki.com/uploads/3/3f/TimeQuest_User_Guide.pdf , das
allgemein als schlaue Anleitung für Dummies gilt.
Eine der ersten Regeln, die da drin stehen, ist die Verwendung von
Virtual Clocks für alles, was "draussen" passiert, damit interne und
externe Constraints sich nicht beissen. set_input_delay und
set_output_delay werden dann nur auf diesen Virtual Clocks verwendet.
Seh' ich ein.
also das da hingeschrieben:
set flexbus_in_ports [list FB_AD[*] FB_ALE FB_OEn FB_WRn]
2
set flexbus_out_ports [list FB_AD[*] FB_TAn]
(wen's interessiert: der Cyclone III hängt an einem FreeScale FlexBus
mit 33 MHz)
Der Bus ist INOUT, deswegen erscheint FB_AD in beiden Listen.
Dann constrained:
Soweit, so gut. TimeQuest meckert nicht und zunächst sieht der Timing
Report so aus, wie wenn ich direkt überall CLK_MAIN angegeben hätte.
Mit einer Ausnahme (und die will mir nicht in den Kopf):
virt_clk_main hat plötzlich ein lächerliches "Restricted Fmax" (und ich
bin eigentlich gewillt, das ernst zu nehmen).
Weiss jemand, wo das herkommt und was ich damit anzufangen (bzw. mir
darunter vorzustellen) habe?
Das passiert nur, wenn ich meinen INOUT Bus constraine und
virt_clk_main verwende. Sobald ich eine Richtung weglasse oder CLK_MAIN
verwende, ist alles wieder gut (das Design läuft übrigens in Hardware so
oder so - mit 33 MHz).
Markus F. schrieb:> Dann constrained:> foreach in_port $flexbus_in_ports {> set_input_delay -clock virt_clk_main -min -0 $in_port> set_input_delay -clock virt_clk_main -max 0 $in_port> }>> foreach out_port $flexbus_out_ports {> set_output_delay -clock virt_clk_main -min -0 $out_port> set_output_delay -clock virt_clk_main -max 0 $out_port> }>> Soweit, so gut.
.. aber noch nicht fertig, damit hast du erst das Gründgerüst,
die konkreten Zahlen müssen ja noch eingefügt werden.
"0" für Eingang liegt in deiner Verantwortung (in der Praxis
nicht erreichbar), "0" für Ausgang ist schlicht aus FPGA-Seite
ebenfalls nicht erreichbar (du hast Jitter im Clock-Netz als
auch in den IO-Ports und den Leitungen dahin etc.), vlt. liegt
da ja die Begründung für die Einschränkung. Aus deinen Angaben
lässt sich das aber nicht schliessen, dafür bräuchte man mehr
Infos (welcher Chip hängt dran, wie lange sind die Leitungen etc).
Sigi schrieb:> Markus F. schrieb:>> Soweit, so gut.>> .. aber noch nicht fertig, damit hast du erst das Gründgerüst,> die konkreten Zahlen müssen ja noch eingefügt werden.>
Danke.
Mir geht's nicht darum, was ich da hinschreiben soll (mir ist schon
klar, dass ich damit noch nicht fertig bin), sondern darum, warum die
"restricted Fmax" so drastisch runtergeht, wenn ich inout ports in beide
Richtungen constraine (tatsächlich ist es für die "restricted Fmax"
völlig wurscht, was - d.h. welchen Wert - ich da hinschreibe).
input_delay und output_delay beschreiben ja, wieviel Zeit vom
verfügbaren Fenster durch die äussere Beschaltung verbraten wird, also
für das FPGA-Design nicht mehr zur Verfügung steht. Mit 0 behaupte ich,
dass die externe Beschaltung keine Delays produziert und die FPGA-Seite
es gemütlich angehen kann.
Markus F. schrieb:> input_delay und output_delay beschreiben ja, wieviel Zeit vom> verfügbaren Fenster durch die äussere Beschaltung verbraten wird
Ja, genau (z.B. hatAltera dazu die MIN-MAX-Angaben, Xilinx
die IN(at)-VALID(for)-Angaben).
Zum Ursachenverständnis nur soviel, ich kenne ja nicht deine Schaltung:
Die Input-Constraints von "0" bedeuten ja etwa, dass sie Phasengleich
mit deiner Clock ankommen. Deine Clock braucht vlt 3-4ns bis zum
Latch-Register (grob geschätzt, je nach FPGA-Grösse abweichend),
deine Signale mal angenommen 5-6ns bis zur Logik bzw. Latch-Register.
Damit sind von Taktfenster 1-3ns verbraten (ergibt sich aus der
Differenz). Keine phasenverschobene Clock angenommen dürfte hier
nicht das Problem liegen.
Die Output-Constraints von "0" können dagegen sehr kritisch sein.
Wieder hast du hier die 3-4ns von Clock-Eingang bis
Launch-Register-Eingang. Dann nochmal angenommene 5-6ns bis zum
Pin ergibt 7-10ns (ergibt sich aus der Summe), also deutlich
mehr als deine 0ns.
Das beruht aber auf frei gesetzte aber realistischen Verzögerungen
innerhalb des FPGA.
Für die Ursachensuche öffne am Besten mal TimeQuest, und schau
dir die Pfade von Inputs und nach Outputs an. Bei 33MHz Ziel
und ca. 5MHz Restricted muss da ja ein Slack von so um die
30-200=-170ns auftauchen (=> Übertäter).
Sigi schrieb:> Für die Ursachensuche öffne am Besten mal TimeQuest, und schau> dir die Pfade von Inputs und nach Outputs an. Bei 33MHz Ziel> und ca. 5MHz Restricted muss da ja ein Slack von so um die> 30-200=-170ns auftauchen (=> Übertäter).
Danke, hab' ich gerade mal gemacht:
Ergebnis im Anhang.
Sieht für mich völlig unscheinbar aus, jedenfalls nichts dabei, dass mir
das Fmax erklären würde.
Ich habe was anderes festgestellt: wenn ich das .sdc-File von oben durch
das hier ersetze:
, also die eine Virtual Clock durch zwei identische ersetze (eine für
die "in"-Ports und eine für "out"), ist Fmax plötzlich wieder bei 140
Mhz.
Warum?
So auf die Schnelle fällt mir dann auch nichts
ein. Kannst du vlt noch die beiden Output-Zeiten
auf 30ns (statt 0ns) setzen und mal schauen, was
an Report ausgegeben wird?
Zum Design selbs habe ich noch nichts gesagt: das ist völlig simpel (ich
wollte ja nachvollziehen können, was passiert).
Am Bus hängt lediglich ein ALTSYNCRAM, das ich beschreiben und auslesen
kann.
Sigi schrieb:> Kannst du vlt noch die beiden Output-Zeiten> auf 30ns (statt 0ns) setzen und mal schauen, was> an Report ausgegeben wird?
Dann habe ich (natürlich) Timing Violations ohne Ende (mit -30 + dem,
was ich vorher als margin hatte). Restricted Fmax ist (bis auf's
i-Tüpfelchen) exakt gleich: 5.81 MHz
Ich glaub' ich mach' mal mit meiner "Doppelclock" weiter. Vielleicht
kommt ja noch die Erleuchtung.
Vielen Dank für deine Hilfe.
