Guten Morgen, von Xilinx Webpack war ich es immer gewohnt, dass nach der Timing-Analyse die maximale Frequenz meines CLKs ausgegeben wurde - auch ohne Constraints zu setzen. Weiß jemand, wo ich das bei Quartus Prime (aktuelle Version) sehen kann? Vmtl irgendwo im Timequest-Dingens? Das ist ja überladen ohne Ende ... Vielen Dank! Mampf
Gast
#4892025
Das geht auch mit Xilinx Vivado nicht so ohne weiteres. Grund ist, dass die Tools Optimierungsalgorithmen benutzen, die eben bei bestimmten Constraints ein lokales Optimum finden bzw. einfach nur so weit optimieren, bis es passt.
Im Report unter Fmax.
Frank S. schrieb: > Im Report unter Fmax. Ah endlich gefunden! Bei mir unter "Slow 1200mV 0C Model" ... Das hatte ich nie aufgeklappt, weil es unter "Fast 1200mV 0C Model" keine FMax Angabe gab ... Danke!
Gast
#4892517
Wozu brauchst Du denn diese Zeiten?
Weltbester FPGA-Pongo schrieb im Beitrag #4892517: > Wozu brauchst Du denn diese Zeiten? Damit ich weiß, ob die Taktfrequenz hoch genug ist oder ob ich etwas nochmal pipelinen muss und dann um die PLL zu bestimmen :) Aber so wie es aussieht passt es schon ... 2,2Mio Takte "Zeit", um meine Algorithmen zu berechnen :)
Gast
#4892958
Mampf F. schrieb: > Damit ich weiß, ob die Taktfrequenz hoch genug ist Um nochmal darauf zurückzukommen: Es kann sein, dass du mit entsprechenden constraints höhere Takte erreichen kannst, als die bei Fmax angegebenen. Das Fmax ist bei den verwendeten Algorithmen kein sinnvoller Wert, höchstens eine grobe Richtung. Zumindest bei Xilinx Vivado ist das so, kann mir vorstellen, dass das bei Altera Quartus ähnlich ist. Meine Quelle ist (neben persönlicher Erfahrung) dieser Thread: https://forums.xilinx.com/t5/Vivado-TCL-Community/Freq-at-which-whole-project-is-synthesized/td-p/282432
VHDL hotline schrieb im Beitrag #4892958: > Es kann sein, dass du mit > entsprechenden constraints höhere Takte erreichen kannst, als die bei > Fmax angegebenen. Das Fmax ist bei den verwendeten Algorithmen kein > sinnvoller Wert, höchstens eine grobe Richtung. Ah okay, danke für den Hinweis! VHDL hotline schrieb im Beitrag #4892958: > Xilinx Vivado Das ist vollständig an mir vorüber gegangen ... Muss ich mir anschauen :)
VHDL hotline schrieb im Beitrag #4892958: > Das Fmax ist bei den verwendeten Algorithmen kein > sinnvoller Wert, höchstens eine grobe Richtung. Quartus würfelt den Wert für Fmax nicht aus. Er ist natürlich sinnvoll. Ob er für Dich sinnvoll ist, steht auf einem anderen Blatt. Fmax ergibt für gleiches Clock- und Data-Delay aus: FMax = 1/(Tco(launch) + Tsu(latch))
Hier ist es gut zu erkennen: http://archive.ednchina.com/bbs.ednchina.com/images/attachments/201503/original/20150322154543298.jpg Ein stabiles Verhalten ist nur solange gewährleistet, solange die Summe aus Tco und Tsu kleiner/gleich der Periodendauer ist. Ist die Summe größer, wird Tsu verletzt.
Frank S. schrieb: > Fmax ergibt für gleiches Clock- und Data-Delay aus: FMax = > 1/(Tco(launch) + Tsu(latch)) Schon richtig. Ob das allerdings tatsächlich die größtmögliche Taktrate ist, die die Schaltung packt, ist nach meiner Ansicht keinesfalls gesagt. Der Fitter hört (spätestens) dann mit seinen Bemühungen auf, wenn alle Constraints erfüllt sind. Ob er nicht vielleicht doch noch eine bessere Lösung hätte finden können, wenn man ihn nur gelassen hätte, kriegt man so nicht raus. Wenn man wissen will, ob ein Design (z.B.) 100 MHz packt, muß man es m.E. auch mit 100 MHz synthetisieren lassen (oder eben 120 oder 150).
Diese Zeiten sind leider heute nichts mehr wert, weil die Taktfrequenzen bei immer kleiner werdenden Strukturen immer mehr von den Laufzeiten abhängen und nicht mehr von den Schaltzeiten. Laufzeiten sind aber erst NACH dem Platzieren bekannt. Erst dann weiß man, was geht. Damit sind die Schätzungen immer unrealistischer. Leider sind sie es nicht immer zum Negativen, sodass man noch Reserve hat. Bei voller werdenden FPGAs geht das sehr schnell, dass selbst die pessimistischen Schätzfrequenzen nicht mehr getroffen werden.