Forum: FPGA, VHDL & Co. TimeQuest Timing Constraints: inout ports + virtual clocks


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Markus F. (mfro)


Bewertung
1 lesenswert
nicht lesenswert
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 period [expr roundto(1000000.0 / 33000.0, 3)]

create_clock -period $period -name CLK_MAIN [get_ports {CLK_MAIN}]
create_clock -period $period -name virt_clk_main

dann meine Ports definiert:
set flexbus_in_ports [list FB_AD[*] FB_ALE FB_OEn FB_WRn]
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:
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. 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):
+-----------------------------------------------------------------------------------------------+
; Slow 1200mV 85C Model Fmax Summary                                                            ;
+------------+-----------------+---------------+------------------------------------------------+
; Fmax       ; Restricted Fmax ; Clock Name    ; Note                                           ;
+------------+-----------------+---------------+------------------------------------------------+
; 61.66 MHz  ; 5.81 MHz        ; virt_clk_main ; limit due to minimum period restriction (tmin) ;
; 141.96 MHz ; 141.96 MHz      ; CLK_MAIN      ;                                                ;
+------------+-----------------+---------------+------------------------------------------------+

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

von Sigi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sigi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Markus F. (mfro)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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:
report_timing -setup -from [all_inputs] -detail summary -nworst 2
report_timing -setup -to [all_outputs] -detail summary -nworst 2
report_timing -hold -from [all_inputs] -detail summary -nworst 2
report_timing -hold -to [all_outputs] -detail summary -nworst 2

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:
create_clock -period $period -name CLK_MAIN [get_ports {CLK_MAIN}]
create_clock -period $period -name virt_clk_main_in
create_clock -period $period -name virt_clk_main_out

derive_pll_clocks
derive_clock_uncertainty

## FlexBus constraints

set flexbus_in_ports [list FB_AD[*] FB_ALE FB_OEn FB_WRn]
set flexbus_out_ports [list FB_AD[*] FB_TAn]

foreach in_port $flexbus_in_ports {
    set_input_delay -clock virt_clk_main_in -min -0 $in_port
    set_input_delay -clock virt_clk_main_in -max  0 $in_port
}

foreach out_port $flexbus_out_ports {
    set_output_delay -clock virt_clk_main_out -min -0 $out_port
    set_output_delay -clock virt_clk_main_out -max  0 $out_port
}

, 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?

von Sigi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.