Hallo,
ich wollte mal in die Runde hören wer Retiming einsetzt und wenn ja mit
welchen Erfahrungen.
Ich stehe an einem Punkt wo mein Design zu 90% fertig ist, aber jede
weitere Änderung ist nur noch schwer durchzubringen wegen des Timings.
Mit ein paar Durchläufen geht es meistens, aber es kommt ja auch noch
ein bischen rein.
Jetzt gibt es 2 Möglichkeiten:
- selbst optimieren
- retiming
Bisher war ich immer sehr skeptisch, weil wenn man sich erstmal auf
diesen Pfad begibt, dann kommt man nicht allzu schnell zurück und ich
mache mir Sorgen, wenn ich doch mal ein Problem cyclegenau debuggen
muss, das ich mich dann selbst veräpple.
Vielleicht habt ihr aber gute Erfahrungen gesammelt?
Oder auch nicht?
Was verstehst du unter Retiming? Einfach nur dass sich das Synthese Tool
um die Reihenfolge der Pipeline Register kuemmert um das Timing
dazwischen auszubalancieren oder sogar das setzen zusaetzlicher Register
um sich mehr Luft zu verschaffen?
Im Prinzip ist es immer ein Mix aus allen Loesungen. Was ich noch in den
Topf werfen wuerde, waere das Auflockern von Timing Constraints, zum
Beispiel durch Multicycles oder False-Paths (natuerlich nur da wo man es
sich erlauben kann ;-)).
Ein Beispiel fuer den Mix sind z.B. komplexe Video Algorithmen. Ein paar
Pipeline Register stoeren in der Regel nicht. Selbst in Echtzeit
Anwendungen ist das bisschen Latenz das auf den Videostream
aufgeschlagen wird nicht der Rede wert. Viele Video Algorithmen haben
Register fuer die Algorithmus Settings und da diese haeufig statisch
sind (bzw. quasistatisch) kann man diese zu False-Paths machen. Den
Tools bleiben dann mehr Ressourcen fuer die kritische Pfade.
Mit dieser Strategie fahre ich haeufig ganz gut.
Ich meine nur das Retiming Feature der Place&Route/Fitter Tools.
Siehe auch hier:
https://en.wikipedia.org/wiki/Retiming
Insbesondere die Punkte unter "Problems" machen mir Sorgen.
Die Aussicht auf besseres Timing ohne viel Arbeit ist aber verlockend.
Die anderen, vorgeschlagenen Lösungen sind auch hilfreich, wenn man sie
nutzen kann.
In meinem Fall geht es um einen Softcore mit Pipeline. Da helfen mir die
Varianten alle leider nicht weiter, bzw. würden das schon, reduzieren
aber den Durchsatz.
Leider kann man wohl reitiming nicht auf bestimmte Register/Module
beschränken, sonst wäre die Entscheidung einfacher...
FPGA zum Spass schrieb im Beitrag #5869242:
> Insbesondere die Punkte unter "Problems" machen mir Sorgen.> Die Aussicht auf besseres Timing ohne viel Arbeit ist aber verlockend.
Dann musst du wohl oder uebel eine Post P&R Simulation durchfuehren. Ich
sehe das Problem in der Praxis jetzt erstmal als nicht so riesig an.
Klar, wenn du mit Chipscope (oder nenn anderen ILA) das debuggen
anfaengst, dann ist es erstmal nervig, wenn die Signale nicht mehr
wirklich zu denen im Code passen. Abhilfe schafft dann aber auch wieder
ein Blick in die Schematics der Synthese. Dann sieht man ja was geandert
wurde und kann das entsprechend handhaben.
FPGA zum Spass schrieb im Beitrag #5869242:
> Leider kann man wohl reitiming nicht auf bestimmte Register/Module> beschränken, sonst wäre die Entscheidung einfacher...
Doch, das geht schon. Du kannst einzelne IPs separat und mit
unterschiedlichen Settings synthetisieren! Das Synthese Produkt kannst
du dann in einem uebergeordneten Design (z.B. dem Toplevel) einfach
einbinden.
Hat natuerlich den Nachteil, dass das Synthesetool nur ueber einen Core
optimieren kann und nicht ueber mehrere wenn sich diese z.B. gleiche
Logik teilen.
Da hilft nur probieren und verschiedene Strategien zu fahren. Zum Glueck
kann man das mittlerweile alles anstaendig automatisieren, z.B. via Tcl
Skripte. :-)
FPGA zum Spass schrieb im Beitrag #5869617:
> Für die Synthese schon, jedoch ist das Retiming eine Option für den> Fitter(P&R) und da geht es soweit ich weiß nicht.
Nope, Retiming ist ueblicherweise ein Synthese Setting. Welches Tool
nutzt du denn, dass ein Retiming waehrend P&R durchfuehrt?
Ich kann mir zwar vorstellen, dass es Tools gibt die ein Retiming
erlauben waehrend der P&R Phase, jedoch macht dass dann deine bedenken
auch wieder obsolet. In dem Fall wuerde ich einfach parallele
Implementierungslaeufe starten, einmal mit und einmal ohne Retiming. Es
ist gaengige Praxis, bei Designs die staendig die regelmaessig Probleme
haben die Timing Constraints einzuhalten, einfach verschiedene
Strategien/Settings in parallelen durchlaeufen zu starten und das beste
Ergebnis herauszupicken.
Quartus schreibt dazu:
"Specifies that Quartus should perform physical synthesis optimizations
on registers, specifically allowing register retiming, during synthesis
and fitting to increase circuit performance."
Also sowohl Synthese als auch P&R.
Ich habe kein konkretes Problem, schrieb ich doch oben.
Es geht mir um Erfahrungswerte von Leuten die es selbst schon länger
einsetzen.
Etwa ob die Probleme, die auf Wikipedia erwähnt sind, tatsächlich
auftreten.
Offensichtlich gibt es aber kaum jemanden der es nutzt oder es hat
keiner Lust zu schreiben.
FPGA zum Spass schrieb im Beitrag #5870882:
> Offensichtlich gibt es aber kaum jemanden der es nutzt oder es hat> keiner Lust zu schreiben.
Das wird praktisch jeder nutzen, der timing-kritische Designs hat, alle
Mittel des Synthesetools ausspielt, um ein Closure hinzubekommen und
keine "harten" Anforderungen an die Verifikation hat.
Ich, zum Beispiel. In den meisten Fällen betreffen mich die bei
Wikipedia genannten Nachteile nicht oder sind mir schlicht wurscht.
