Async. Reset braucht weniger Ressorucen als sync. Reset

[Martin K. (mkohler)]

Hallo zusammen,
Bisher war ich aufgrund diverser Beiträge hier der Ansicht, dass 
synchrone Resets "besser" seien als asynchrone. Ich bezog dies implizit 
auch darauf, dass die Designs bei synchronen Resets kleiner werden 
müssten.
Das habe ich nun ausprobiert.

Ausgangslage: ein altes Design aus meinen VHDL-Anfängen, alle Resets 
asynchron in der Form

    process(CLK,RESET)
    begin
        if INT_RESET = '1' then
            A <= '0';
        else
            if rising_edge(CLK) then
                A <= B;
            end if;
        end if;
    end process;

Neu: alle Resets synchron in der Form

    process(CLK)
    begin
        if rising_edge(CLK) then
            if INT_RESET = '1' then
                A <= '0';
            else
                A <= B;
            end if;
        end if;
    end process;

Beide Varianten habe ich mit ISE8.2.03i synthetisiert und implementiert.
Das Ergebnis hat mich nun aber etwas überrascht, weil die Variante 
"asynchron" sogar noch weniger Ressourcen verbraucht als die Variante 
"synchron"

Wie kann man sich das erklären?

Anhang: Design Summary async. Reset

Edit: Dateinamen war wohl zu lang... Bilder folgen in den nächsten 
Beiträgen.

[Martin K. (mkohler)]

async. Reset

[Martin K. (mkohler)]

sync. Reset

Edit: im obersten Beitrag müsste es heissen: ISE9.2.03i

[Matthias (Gast)]

Wird so ein sync. Reset bei Xilinx nicht mit in den Datenpfad gehängt? 
So gesehen würde es mich nicht wundern, dass du einen größeren 
LUT-Verbrauch hast.

[Michael (Gast)]

Asynchron:
Jedes FF im FPGA hat einen asynchronen Reset-Eingang. Dazu bekommt jedes 
FF den Reset-Wert (ob eine 1 oder 0 drinstehen soll) bei der Synthese 
zugewiesen. Mit der asynchronen Implementierung wird vermutlich eine 
Global-Leitung zu allen FFs im Design geführt. Schneller aber unter 
Umständen nicht definierter Start.

Synchron:
Im Prinzip steht es ja da. Du weist A nur zu synchronen Zeiten einen 
Wert zu. D.h. der Dateneingang des FlipFlops bekommt einen Wert, den er 
mit steigender Clock-Flanke übernehmen soll. Damit hier im Falle des 
Reset der richtige Wert anliegt, muss die Resetleitung an JEDEM FF über 
die LUTs mit verknüpft werden. Damit benötigst Du unter Umständer 
deutlich mehr Logik.
Da die LUTs nur 4-Bit verarbeiten können, bedeutet eine weitere logische 
Verknüpfung, dass hier die Logik über mindestens eine weitere LUT 
verknüpft werden muss.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> Jedes FF im FPGA hat einen asynchronen Reset-Eingang.
Ja, es sei denn, es it ein synchrones FF (mit Set/Reset Eingängen).
FFs können asynchrone Preset/Clear (Xilinx: FDPCE) oder synchrone 
Set/Reset Eingänge (FDRSE) haben.

> Damit hier im Falle des Reset der richtige Wert anliegt, muss die
> Resetleitung an JEDEM FF über die LUTs mit verknüpft werden.
Nicht unbedingt, denn ein synchrones FF hat (wie gesagt) synchrone 
Set/Reset Eingänge. Ob eine Beschreibung darauf effizient implementiert 
werden kann, hängt sehr stark von der Priorität der Reset-Werte ab.
Siehe auch den Beitrag "Re: Hardware mit VHDL "richtig" beschreiben."

Offenbar können die Design-Tools deine Reset-Beschreibungen nicht 
optimal auf die FFs abbilden, und deshalb wird einiges an zusätzlicher 
Logik gebraucht.

Fazit:
Lass den Reset ganz weg, wenn du ihn nicht unbedingt brauchst. Als 
zwingender Grund gilt nicht, dass du einen Reset-Knopf hast  ;-)

[Martin K. (mkohler)]

Danke für die bisherigen Antworten.

Ich habe nun als Test alle FPGA Resets entfernt mit dem Resultat, dass 
der Logikverbrauch unter den Level mit Async. Reset gesunken ist.

Interessanterweise stimmt aber die Anzahl der Slice FlipFlops nicht 
überein (1 weniger als bei Async), dafür wird ein FF als Shift Register 
verwendet.
Naja, XST wird schon wissen was es tut...

Die Synthese/Implementation ist dadurch auch einiges schneller geworden.
Die vielen zusätzlichen Warnungen kommen daher, dass mehrfach der nicht 
verwendete Reset Eingang gemeldet wird.

Der Vollständigkeit halber ist die aktuelle Design Summary ohne Reset 
angehängt.

Gruss,
Martin