Guten Morgen,
Ich habe ein etwas umfangreicheres Projekt, bei dem es sich anbietet,
etwas Strom zu sparen. Das activity level ist sehr hoch, die
Stromaufnahme ebenso und der FPGA (Virtex IIP) wird leicht warm.
Nun will ich ein paar Komponenten zeitweise abschalten, per clock-gating
und operand isolation. Allerdings sind clocks mit Kombinatorik verbunden
ja nicht gerade empfehlenswert, richtig? Wie setzt man clock-gating im
FPGA praktisch um, ohne sich damit einen Haufen Probleme zu machen?
MfG
na
@ na (Gast)
>ja nicht gerade empfehlenswert, richtig? Wie setzt man clock-gating im>FPGA praktisch um, ohne sich damit einen Haufen Probleme zu machen?
Unter anderem so.
Taktung FPGA/CPLD
MFG
Falk
Danke sehr, da hatte ich noch gar nicht geschaut.
Das beschreibt ja soweit erstmal das Problem, welches ich vermeiden
will.
An das clock enable hatte ich auch schon gedacht, wollte das aber wegen
der extra notwendigen Verdrahtung zu jedem einzelnen FF nicht auf diese
Weise umsetzen.
Der derived clock wird wohl eine akzeptable Variante sein. Allerdings
nur, solange ich wirklich alle Schaltungsteile damit versorge, da es
sonst wieder zu Verschiebungen kommt, oder?
@ na (Gast)
>An das clock enable hatte ich auch schon gedacht, wollte das aber wegen>der extra notwendigen Verdrahtung zu jedem einzelnen FF nicht auf diese>Weise umsetzen.
Moderne FPGAs haben TONNENWEISE Verdrahtungsresourcen, da sollte es
wenig Problem geben. Allerdings ist die Stromeinsparung nicht ganz so
hoch wie beim echten Clock Gating, weil bei hohen Taktfrequenzen die
Taktverteilung schon ordentlich Strom zieht. Siehe hier
http://www.geocities.com/jacquesmartini/digital/pldpower/pld_power_measurement.html>Der derived clock wird wohl eine akzeptable Variante sein. Allerdings>nur, solange ich wirklich alle Schaltungsteile damit versorge, da es>sonst wieder zu Verschiebungen kommt, oder?
Jain. Du kann schon Teile deines Designs damit laufen lassen, allerdings
muss man die Übergänge zwischen den Takten mit Respekt behandeln. Am
besten man betrachtet sie als asychron und verwendet zur Kopplung
asychrone FIFOs und verwendet auch sonstige Massnahmen wie bei
asynchronen Signalen (Abtastung etc.)
MFG
Falk
na wrote:
> Danke sehr, da hatte ich noch gar nicht geschaut.>
Hm, fehlt da der Hinweias auf die glitchfreien Takt-multiplexer BUFGMUX
?
Ist der in den neuen versionen abhanden gekommen?
Damit kann man stressfrei Takte abschalten, Xilinx promotet das zum
Stromsparen.
@ Fpga Kuechle (fpgakuechle)
>Hm, fehlt da der Hinweias auf die glitchfreien Takt-multiplexer BUFGMUX>?>Ist der in den neuen versionen abhanden gekommen?
Nee, ist drin. Einfach mal CTRL-F und BUFGMUX eingeben.
MFG
Falk
Dazu passt gut eine Frage die ich schon länger habe: Im Artikel ist das
Clock Enable als If-Abfrage im synchronen Prozess. Wir haben hier ein
Design, in dem das Clock Enable in der if-Bedingung für das synchrone
Abarbeiten steht, der Prozess schaut also so aus:
if Reset = '0' then
...
elsif Clk'EVENT and Clk = '1' and CE_signal = '1' then
...
...
end if;
Macht das irgendeinen Unterschied für das Synthesetool oder ist es
äquivalent zu dem Code im Artikel?
Aber sicher macht das einen Unterschied.
> elsif Clk'EVENT and Clk = '1' and CE_signal = '1' then
genau so sollte man das nicht machen, hier wird das Clocksignal mit
"Kombinatorik" verschaltet.
Anders im Artikel, hier wird nach der Synthese der Dateneingang des oder
der FF mit dem Freigabesignal beschaltet.
>Anders im Artikel, hier wird nach der Synthese der Dateneingang des oder>der FF mit dem Freigabesignal beschaltet.
sorry, hab mich verschrieben, es sollte "CE-Eingang" statt Dateneingang
heißen.
Es ist ja auch das Ziel dieses Konstrukts, dass die CE-Eingänge der FF's
mit dem CE_signal beschalten werden. Ist das Synthesetool zu "blöd", das
daraus abzuleiten? Logisch ist es ja äquivalent, der Simulator sollte
sich auch mit beiden Varianten gleich verhalten. Warum schafft es das
Synthesetool nicht, aus so einer if-Bedingung abzuleiten, dass es das
CE_signal an die CE-Eingänge der FF's in dem Prozess legt?
"Warum?" ist eine Frage, die man bei den Synthesetools besser nicht
stellt...
Logisch sind beide Varianten natürlich gleich, zur Sicherheit würde ich
aber immer zwei getrennte Abfragen benutzen.
@ Matthias (Gast)
>mit dem CE_signal beschalten werden. Ist das Synthesetool zu "blöd", das>daraus abzuleiten?
Mehr oder weniger.
>sich auch mit beiden Varianten gleich verhalten. Warum schafft es das>Synthesetool nicht, aus so einer if-Bedingung abzuleiten, dass es das>CE_signal an die CE-Eingänge der FF's in dem Prozess legt?
Keine Ahnung. Ist am Ende aber egal. Schreibs hin wie es Das
Synthesetool haben will und gut is.
MFG
Falk
hab mich da gerade an einen anderen Thread erinnert, da hatten wir das
schon mal.
Es kommt also auch auf das jeweilige Synthese-Tool an, manche machen
das, ander wieder nicht.
Beitrag "Suche Befehl eine einzelne Flanke"
Gruß Volker
Ok, es ist also mehr ein "Auf Nummer Sicher"-gehen als dass
Synthese-Tools diesen Zusammenhang einfach nicht erkennen könnten oder
es andere Gründe gibt, die dagegen sprechen. Ich hab mir gerade im FPGA
Editor angeschaut, was xst aus diesem Code gemacht hat, der hat wie
intendiert das Signal an die CE-Eingänge geführt.
Insofern mehr eine Frage der Portabilität zwischen verschiedenen
Synthesetools. Andererseits: Wie kann ich sicher sein, dass ein
beliebiges Synthesetool die Syntax mit einer eigenen If-Abfrage für das
CE-Signal richtig macht? Im Prinzip muss ich mein Tool kennen damit ich
weiß, ob ich das gewünschte erreiche.
@ Matthias (Gast)
>Synthesetools. Andererseits: Wie kann ich sicher sein, dass ein>beliebiges Synthesetool die Syntax mit einer eigenen If-Abfrage für das>CE-Signal richtig macht?
Indem du das CE in eine eigene If Abfrage schreibst.
> Im Prinzip muss ich mein Tool kennen damit ich>weiß, ob ich das gewünschte erreiche.
Das gilt immer bei Compilern, speziell bei VHDL und wenn es darum geht,
optimale Schaltungsstrukturen für die Zieltechnologie zu erzeugen. Rein
formal und logisch ist das Ergebnis immer gleich.
MfG
Falk
