fmax Analyse von einzelnen Modulen bei Altera

[Harald (Gast)]

Hallo,

ich habe ein VHDL Design in Quartus das aus mehreren Modulen besteht. 
Alle Module werden mit einem Takt versorgt.
In der Timing Analyse kann ich mir die fmax des Takteingangspins 
anschauen.
Mich würde jetzt interessieren wie schnell ich die einzelnen Module 
theoretisch takten könnte? Das was mir angezeigt wird hängt ja immer vom 
langsamsten Modul ab und ich weiss nicht mal welches das ist.

Kennt jemand die Lösung dafür?

[P. K. (pek)]

Du könntest Dir im TimingAnalyzer die längsten Pfade pro MODULE anzeigen 
lassen, so in der Art:

report_timing -from [get_registers {MODULE:*|*[*]}] -from [get_registers {MODULE:*|*[*]}] -npaths 10 -panel_name {Report Timing: MODULE}

Dann kriegst Du ziemlich schnell ein Gefühl dafür. Allerdings, wenn 
Deine Constraints zu locker waren sind die Resultate nur bedingt 
aussagekräftig (Quartus gibt sich zufrieden, wenn das Timing erfüllt ist 
obwohl der Baustein vielleicht noch schneller könnte).

[Karl (Gast)]

Meiner Meinung nach sagt ein Fmax Test einzelner Module nicht viel aus. 
Später muss ja sowieso das komplette Design mit einer bestimmten 
Taktrate laufen, die Arbeit würde ich mir daher sparen und gleich das 
komplette Design nehmen.

Ich würde schrittweise die Taktfrequenz erhöhen (z.B im 25 MHz Raster) 
und prüfen ob er das Timing des Gesamt-Designs noch einhält. Irgendwann 
wirst du dann "rote Pfade" haben und kannst dir da ja mal mittels 
Timequest genauer ansehen welcher Pfad Probleme bereitet.

Wie mein Vorredner schon sagte ist der FMax-Report im Timequest auch 
keine Aussage über die maximale Performance die der Chip theoretisch 
könnte. Wenn du Quartus sagst dass du einen Takt von 100MHz hast, muss 
es sich auch keine Mühe geben das auch für 200MHz auszulegen und kann so 
Ressourcen oder Kompilier-Zeit sparen. Du wirst also um das Rantasten an 
die Obergrenze nicht drum herum kommen.

[Schlumpf (Gast)]

Neben dem, was die Vorredner schon sagten, kommt hinzu, dass es noch 
lange nicht heißen muss, dass wenn jedes Modul mit 100 MHz laufen 
könnte, dein gesamtes Design das immer noch kann.
Es kann durchaus passieren, dass auf dem Chip genug "Luft" zum guten 
Routing ist, wenn das Design klein ist (einzelnes Modul) und eine hohe 
Taktrate erreicht werden kann, aber wenn du dann alles zusammen 
synthetisierst, ist die Auslastung des Chips so groß, dass Pfade nicht 
mehr optimal geroutet werden können und die Taktrate sinkt.

Also alles in Allem ist es ziemlich wenig aussagekräftig, was du da vor 
hast

[berndl (Gast)]

Was man durchaus machen kann, vor allem, wenn man eine Komponente in 
verschiedene Zieltechnologien bringen will: Nur diese eine Komponente in 
ein Design packen, die I/Os ueber evtl. mehrere Schieberegister 
'entkoppeln', dann die Daumenschrauben bzgl. Timing anziehen.

Ergebnis: Man bekommt eine ganz passable Aussage, wieviele LUTs in Reihe 
liegen, deren Durchlaufzeit ist vom Ziel-FPGA vorgegeben. Nun noch mit 
etwas Phantasie einen 'Routing-Nasenfaktor' pro LUT drauf. Damit hat man 
ein ganz gutes Gefuehl, was die Komponente denn so maximal an Takt 
zulaesst. Dass das in einem realen Design dann passt ist meist zwar 
illusorisch, aber aufschlussreich.

Ich hab's vor ein paar Jahren mal fuer einen CORDIC gemacht, die 
Implementierung sollte in 90nm/65nm/45nm Designs von X, A, und L. Und 
bei allen 90nm Technologien bin ich dann auch nicht auf die gewuenschten 
100MHz gekommen. Aufpassen muss man auch, dass man LUT4 oder LUT6 
beruecksichtigt.

Alles in allem war's eine Spielerei, ziemlich sinnbefreit... Schneller 
geht's wenn man eine Komponente einfach in sein Design instanziiert 'und 
einfach mal probiert'. Aber interessant war es schon, den Timing Report 
von 3 verschiedenen Tools mal wirklich im Detail zu analysieren, sollte 
man vlt. wirklich mal durchexerzieren. Man kommt dann naemlich bei ganz 
anderen Designs auch irgendwie schneller zum (Timing-)Problem wenn's mal 
hakt.

Also Fazit von meiner Seite: Gebracht hat's nix, aber umsonst war's auch 
nicht :o)