Hallo zusammen,
ich habe einen einfachen, exemplarischen vhdl-Code:
1
entityand_gatteris
2
port
3
(a,b:instd_logic;
4
c:outstd_logic;
5
end;
6
architecturertlofand_gatteris
7
begin
8
c<=aandb;
9
end;
Es gibt also keinen Takt und es ist ein rein kombinatorisches Element.
Kann mir Quartus hierfür eine maximal mögliche Taktfrequenz ausrechnen?
Mein eigentlicher Code ist natürlich komplizierter, aber ebenfalls ohne
Takt. Wie kann ich nach dem P&R dafür die maximal mögliche Taktfrequenz
ermitteln, denn die Gatterlaifzeiten limitieren ja irgendwann die ganze
Sache...
Oder habe ich noch einen Denkfehler und es fehlen für die Berechnung
noch ein paar Angaben/Constraints?
Vielen Dank!
Chris
Christian Z. schrieb:> Kann mir Quartus hierfür eine maximal mögliche Taktfrequenz ausrechnen?
Nein, denn es gibt keinen Takt. Eine maximale Taktfrequenz kann erst
errechnet werden, wenn vor und nach dieser Logik ein Register sitzt.
Christian Z. schrieb:> Wie kann ich nach dem P&R dafür die maximal mögliche Taktfrequenz> ermitteln, denn die Gatterlaifzeiten limitieren ja irgendwann die ganze> Sache...
Welche Sache?
Du kannst bestenfalls nach sowas wie "Combinatorial Delay" suchen. Denn
du hast ja keinen Takt, sondern nur eine Durchlaufzeit durch IO-Treiber
und Logik ...
Eigentlich ist es ne unübliche Vorgeshensweise, erst zu synthetisieren
und dann zu schauen, wie schnell das Design maximal laufen kann.
Üblicherweise hat man Mindestanforderungen, die man als Constraint
vorgibt und die Synthese "versucht" dann, das Placement und Routing so
zu machen, dass deine Anforderugen erfüllt werden können. Gibst du
nichts vor, so wird die Synthese es so machen, wie sie es für "gelungen"
hält. Das heißt aber noch lange nicht, dass es die schnellste Lösung
ist, die theoretisch möglich ist. Vielleicht ist es die
platzsparendste..
Daher musst du Constraints vergeben, die so sind, dass der Rest deiner
Schaltung damit zurechtkommt. Musst mal schauen, ob Quartus sowas wie
ein Pin-to-Pin-delay Constraint anbietet. Könnte eventuell auch Tpd
heißen.
Du gibst also das passende Constraint vor und die Synthese wird dann
versuchen, das Design so in das FPGA zu packen, dass deine Anforderungen
erfüllt sind.
Nach der Synthese kannst du dann im Report sehen, wie groß der
tatsächlich erreicht Wert ist.
Hallo und vielen Dank,
Lothar Miller schrieb:> Nein, denn es gibt keinen Takt. Eine maximale Taktfrequenz kann erst> errechnet werden, wenn vor und nach dieser Logik ein Register sitzt.
also würde es in etwas so funktionieren?
1
entityand_gatteris
2
port
3
(clk:instd_logic;
4
a,b:instd_logic;
5
c:outstd_logic;
6
end;
7
architecturertlofand_gatteris
8
9
signalaa,bb,cc:std_logic;
10
11
begin
12
aa<=awhenrising_edge(clk);
13
bb<=bwhenrising_edge(clk);
14
15
cc<=aaandbb;
16
17
c<=ccwhenrising_edge(clk);
18
end;
Muss ich, wenn ich wieder am Arbeitsrechner sitze, mal austesten.
Vielen Dank!
Chris
Christian Z. schrieb:> also würde es in etwas so funktionieren?
Ja, die Frage ist allerdings, was dann der Sinn bei der Sache ist. Eine
Durchlaufzeit durch Kombinatorik lässt sich auch einfacher ermitteln...
Hallo,
Lothar Miller schrieb:> Ja, die Frage ist allerdings, was dann der Sinn bei der Sache ist. Eine> Durchlaufzeit durch Kombinatorik lässt sich auch einfacher ermitteln...
Genau das ist mein Ziel, die Durchlaufzeit der Kombinatorik ermitteln
und daher wollte ich den (Um)weg über die maximal mögliche Taktfrequenz
gehen.
Lothar Miller schrieb:> Du kannst bestenfalls nach sowas wie "Combinatorial Delay" suchen.
Dieser Hinweis erschien mir wenig konkret und ich habe auch keine
derartige Funktion im Quartus gefunden.
Vielen Dank!
Chris
Christian Z. schrieb:> keine derartige Funktion im Quartus gefunden.
Die Funktion findet sich nicht im Quartus direkt, sondern im TimeQuest
Timing Analyzer. Dort baust Du dir (nach der Synthese) die
Timing-Netzliste auf, danach heisst der Schlüsselbegriff "report_path"
(mit -from, -to). Entweder im GUI (Irgendwas wie Reports > Custom
Reports oder so), oder direkt auf der TCL Commandline.
So, wie ich es beschrieben habe, hab ich es grad mal synthetisiert und
das klappt einwandfrei.
Allerdings nicht mit Altera, sondern mit Lattice
Die Vorgabe:
MAXDELAY FROM PORT "*" TO PORT "*" 5.000000 ns ;
ergab folgendes Ergebnis:
======================================================================
Preference: MAXDELAY FROM PORT "*" TO PORT "*" 5.000000 ns ;
2 items scored, 0 timing errors detected.
----------------------------------------------------------------------
Passed: The following path meets requirements by 0.179ns
Logical Details: Cell type Pin type Cell/ASIC name (clock net +/-)
Source: Port Pad b
Destination: Port Pad c
Delay: 4.821ns (59.3% logic, 40.7% route), 3 logic levels.
Das ist doch genau die Information, die du willst, oder?
Schlumpf schrieb:> Das ist doch genau die Information, die du willst, oder?
Nein, das ist eben nicht die Laufzeit durch die Kombinatorik, sondern
die Laufzeit durch 2 Stück IO-Treiber plus die Laufzeit durch die
Kombinatorik. Denn ein AND-Gatter allein darf bestenfalls 500ps
brauchen, sicher nicht länger! Denn das ist ja nur 1 LUT, die diese
Funktion beinhaltet...
@ Lothar:
Der Fragesteller stellte einen Code ein, der die Ports enthält und
wollte HIERFÜR die maximale Taktfrequenz.
Christian Z. schrieb:> Kann mir Quartus hierfür eine maximal mögliche Taktfrequenz ausrechnen?
Dass es hierfür keine Taktfrequenz gibt, sondern nur eine Laufzeit, ist
ja bereits geklärt.
Aber nachdem er HIERFÜR schrieb, gehe ich davon aus, dass er die gesamte
Laufzeit für das meint, was er beschrieben hat. Also von Port zu Port.
Sollte die Frage so gemeint sein, wie du denkst, dann kann er entweder
vor und nach der Logik ein Register setzen und dann den
Register-to-Register-Delay constrainen, oder er zieht einfach von o.g.
Port-to-Port-Delay die PAD-Delays und ggf. die Routing Delays zur LUT
ab.
Wie groß die jeweils sind, findet man ja im P&R-Report.
In meinem Fall:
Physical Path Details:
Name Fanout Delay (ns) Site Resource
PADI_DEL --- 0.953 N2.PAD to N2.PADDI b
ROUTE 1 1.372 N2.PADDI to R25C2D.C0 b_c
CTOF_DEL --- 0.238 R25C2D.C0 to R25C2D.F0 SLICE_0
ROUTE 1 0.591 R25C2D.F0 to P1.PADDO c_c
DOPAD_DEL --- 1.667 P1.PADDO to P1.PAD c
--------
4.821 (59.3% logic, 40.7% route), 3 logic levels.
Hallo und Danke für die Hilfreichen Antworten!
Peter K. schrieb:> Dort baust Du dir (nach der Synthese) die> Timing-Netzliste auf
Nach P&R und dem Timing Analyer bekomme ich von Pfad b => c folgendes
Bild.
Leider weiß ich nun nicht, wie ich die Angaben richtig interpretiere. So
eine schöne Aufschlüsselung von PADs ubnd Logik finde ich leider nicht.
Für ein einfaches AND-Gatter sind das ganz schön viele ns und die
einzige Angabe die dazu passt wären in Zeile 4 die 0,225ns - aber ob das
die Antwort auf meine Frage ist?
Und was genau geben IC und CELL an?
Vielen Dank!
Chris
Christian Z. schrieb:> Leider weiß ich nun nicht, wie ich die Angaben richtig interpretiere. So> eine schöne Aufschlüsselung von PADs ubnd Logik finde ich leider nicht.
Es geht so:
1
0 1634ns 1,665ns 225ps 3,866ns 1,113ns
2
Pad --> Eingangstreiber --> Routing --> LUT --> Routing --> Ausgangstreiber -- Pad
Jetzt findest du die Zeiten wieder. Und auch hier wird recht viel Zeit
im Routing verplempert...
> Und was genau geben IC und CELL an?
IC = Interconnect, Routing
CELL = irgendeine fertige Zelle (IO-Treiber, LUT, ...)
Alles klar!
Vielen, vielen Dank!
Nun habe ich einen Anhaltspunkt und kann weiter arbeiten. Sind also
erstmal nur die addierten CELL Werte (ohne die IN/OUT Buffer)
interessant. Das ROUTING kommt dann später.
Viele Grüße,
Chris!
Thread beobachten
Seitenaufteilung abschalten