mikrocontroller.net

Forum: FPGA, VHDL & Co. Theoriefrage asynchroner Reset


Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Angenommen ich synchronisiere einen Reset der von außen kommt (Knopf 
z.b.) über 2 Flipflops ins FPGA ein.
Diesen Reset verwende ich dann im restlichen Design asynchron zum Takt 
also
if (rst ...) elsif (clock ...) end if;

Spricht man dann noch von einem asynchronen Reset und sollte das dann 
einwandfrei funktionieren?

Autor: Armin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
soweit ich weiß, bügelt der Reset alles nieder - sollte also auf jeden 
Fall funktionieren.

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Armin schrieb:
> soweit ich weiß, bügelt der Reset alles nieder - sollte also auf jeden
> Fall funktionieren.

Was ich genau meinte: Treten da auch noch Glitches auf so dass ein Teil 
der Schaltung noch im Resetzustand ist und der andere schon anläuft?

Autor: spartanne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
D. I. schrieb:
> Was ich genau meinte: Treten da auch noch Glitches auf so dass ein Teil
> der Schaltung noch im Resetzustand ist und der andere schon anläuft?

Nein, du hast ja geschrieben dass du den externen Reset 
einsynchronisiert hast. Einen "halben" Reset wird es somit nicht geben.

Hiermit:

D. I. schrieb:
> if (rst ...) elsif (clock ...) end if;

baust du Reset-Kombinatorik auf, welche sich u.U. kontraproduktiv auf 
die maximale Frequenz des Designs auswirkt.

Autor: spartanne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag: ich gehe davon aus dass in deinem Design "hoffentlich" nur ein 
Takt verwendet wird.

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja nur ein takt natürlich.

Spricht man dann in dem Fall noch von einem asynchronen Reset oder von 
einem synchronen Reset?

Autor: Armin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah ok.
Die Frage ist natürlich berechtigt und da fehlt mir die praktische 
Erfahrung, um das zu beantworten.

Aber Gegenfrage: was passiert, wenn du deinen RST nicht 
einsynchronisierst und trotzdem zufällig eine Flanke triffst beim 
Auslösen?
Sollten die Teile nicht so designt sein, dass RST und CLK einen ähnlich 
langen Weg zu den Registern haben?

Vielleicht kann man so etwas ja auch simulieren?


Warten wir mal ein bisschen - das hat bestimmt schon mal ein Praktiker 
getestet ^^


Man kann sich natürlich auch fragen, warum es notwendig ist, einen 
asyncRESET-Eingang zu verwenden, wenn man ohnehin weiß, dass das Signal 
synchron ist.


oh es gibt schon Antworten:

spartanne schrieb:
> Nein, du hast ja geschrieben dass du den externen Reset
> einsynchronisiert hast. Einen "halben" Reset wird es somit nicht geben.

Die Gefahr wird wohl eher sein, dass einige Register mit einer 
vorbeikommenden CLK-Flanke schon anlaufen, während andere noch im RST 
sind. Darauf hat sich mein Beitrag bezogen.

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Armin schrieb:

>
> Aber Gegenfrage: was passiert, wenn du deinen RST nicht
> einsynchronisierst und trotzdem zufällig eine Flanke triffst beim
> Auslösen?

Der Fall ist mir schon bewusst, da kann Gott und die Welt passieren.

Autor: spartanne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Armin schrieb:
> oh es gibt schon Antworten:
>
> spartanne schrieb:
>> Nein, du hast ja geschrieben dass du den externen Reset
>> einsynchronisiert hast. Einen "halben" Reset wird es somit nicht geben.
>
> Die Gefahr wird wohl eher sein, dass einige Register mit einer
> vorbeikommenden CLK-Flanke schon anlaufen, während andere noch im RST
> sind. Darauf hat sich mein Beitrag bezogen.

Nochmal: wenn du ein externes Signal mit dem Takt einsynchronisierst und 
dieses synchronisierte Signal verwendest wirst du nie Probleme haben 
solange zu fmax nicht verletzt. Ein FPGA ist so konstruiert, dass das 
Clock-Signal quasi zeitgleich an allen Registern anliegt. Dafür hat 
Xilinx, Altera, Lattice und Co. zu sorgen und der Anwender kann sich 
darauf verlassen.

Autor: spartanne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
D. I. schrieb:
>> Aber Gegenfrage: was passiert, wenn du deinen RST nicht
>> einsynchronisierst und trotzdem zufällig eine Flanke triffst beim
>> Auslösen?
>
> Der Fall ist mir schon bewusst, da kann Gott und die Welt passieren.

Da wird GARANTIERT etwas schiefgehen! Es gilt für alle externe Signale: 
einsynchronisieren, egal ob Reset oder sonstwas. Wer sich daran nicht 
hält ist selbst Schuld an der langwierigen Fehlersuche.

Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Armin schrieb:
> Man kann sich natürlich auch fragen, warum es notwendig ist, einen
> asyncRESET-Eingang zu verwenden, wenn man ohnehin weiß, dass das Signal
> synchron ist.

Ein asynchrones Rest zu beschreiben macht schon Sinn, denn es benötigt 
weniger Resourcen als ein synchrones Reset und man erreicht damit oft 
auch höhere Taktraten.

Das kann man auch schön sehen, wenn man sich so einen typische CLB näher 
betrachtet: Der besteht sehr vereinfacht aus einer LUT mit einem 
anschließendem FF. Der Ausgang der LUT geht an den D-Eingang des FF, 
aber dieses besitzt neben dem D-Eingang noch ein Enable und ein Reset 
(Clock natürlich auch). Wenn man z.B. ein LUT4 hat und das D-Signal aus 
4 Signalen kombinatorisch gebildet wird, dann reicht ein LUT4 dafür aus. 
Wenn man dann aber noch das Reset synchron verwendet werden aus den 4 
Singalen derer 5. Die Folge ist, dass dafür zwei LUT4 benötigt werden. 
=> Mehr Resourcen und lägere Laufzeiten. Dafür bleibt aber der 
Reset-Eingang des FF frei ;-)

Natürlich muss das Reset aber zuvor einsynchronisiert sein.

Autor: Dogbert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist und bleibt ein asynchroner Reset.

Was soll das werden?
Ich würde es gerne wissen damit ich es nicht aus versehen kaufe.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Spricht man dann in dem Fall noch von einem asynchronen Reset oder von
> einem synchronen Reset?
Es bleibt wie schon gesagt ein asynchroner Reset. Wenn das systemweit 
gemacht wird, dann wären die Whitepaper WP272 und WP275 von Xilinx mal 
einen Blick wert. Denn durch den asynchronen Reset werden z.B. bei 
Xilinx-FPGAs die FFs im FPGA in den asynchronen Modus geschaltet, der 
insbesondere die Setz-und Rücksetzeingänge beeinflusst. Das kann als 
zusätzlicher Aufwand und schlechteren Laufzeiten bemerkbar machen: 
http://www.lothar-miller.de/s9y/archives/70-Asynch...

Und etliche Möglichkeiten (wie z.B. Schieberegister in den LUTs) werden 
durch einen Reset (synchron oder asynchron) generell verhindert.

> Ein asynchrones Rest zu beschreiben macht schon Sinn, denn es benötigt
> weniger Resourcen als ein synchrones Reset und man erreicht damit oft
> auch höhere Taktraten.
Ich hatte mal ein Design bei Lattice MachXO-Bauteinen, da brachte ein 
lokaler asynchroner Reset an handverlesenen FFs tatsächlich eine 
Verbesserung...  :-o

Fazit:
Bei einer VHDL-Hardware-Beschreibung darf die dahinterliegende Hardware 
niemals ausser Acht gelassen werden, wenn ein halbwegs optimales Design 
herauskommen soll.

Autor: SuperWilly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Fazit:
>Bei einer VHDL-Hardware-Beschreibung darf die dahinterliegende Hardware
>niemals ausser Acht gelassen werden, wenn ein halbwegs optimales Design
>herauskommen soll.

Da hat sich jemand besonnen ;O)

VG,
SuperWilly

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Da hat sich jemand besonnen ;O)
Und das trotz geschlossener Wolkendecke ;-)

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und um nochmals fachliches Futter einzuwerfen, die Paper zu Reset von 
Cliff Cummings:
http://www.sunburst-design.com/papers/CummingsSNUG...
http://www.sunburst-design.com/papers/CummingsSNUG...

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Diese Aussage auf Seite 2 in CummingsSNUG2002SJ_Resets stimmt so 
unbesehen allerdings nicht:
 This coding style will generate extraneous logic as shown in Figure 1.
Es wird hier keinerlei zusätzliche Logik erzeugt (Bild_1)!
Es wird lediglich (wie ja auch im Code beschrieben) das Reset-Signal 
unnötigerweise auf den Clock-Enable-Eingang des 2. FFs aufgeschaltet.
library ieee;
use ieee.std_logic_1164.all;

entity FFstyle is
  port (
    clk   : in  std_logic;
    rst_n : in  std_logic;
    d     : in  std_logic;
    q2    : out std_logic);
end FFstyle;

architecture rtl of FFstyle is
  signal q1 : std_logic;
begin
  process (clk)
  begin
    if (clk'event and clk = '1') then
      if (rst_n = '0') then
        q1 <= '0';
      else
        q1 <= d;
        q2 <= q1; -- 1) rst_n geht auf clock-enable von q2 (Bild_1)
      end if;
      q2 <= q1;   -- 2) q2 wird nur getaktet (Bild_2)
    end if;
  end process;
end rtl;

Es ist auch keineswegs (wie in dem PDF vorgeschlagen) nötig, 2 Prozesse 
zu verwenden. Es muß nur die Zuweisung an q2 ausserhalb des Reset-Zweigs 
passieren.

Autor: ein Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Letztendlich ist der Satz, den Lothar geschrieben hat die ganze 
Wahrheit:

> Fazit:
> Bei einer VHDL-Hardware-Beschreibung darf die dahinterliegende Hardware
> niemals ausser Acht gelassen werden, wenn ein halbwegs optimales Design
> herauskommen soll.

Xilinx empfiehlt explizit synchrone Resets, siehe auch Whitepaper WP231. 
Das widerspricht zum Teil dem, was Cliff Cummings in seinen Papers 
schreibt.

Bei einem neuen Design habe ich kürzlich aus Neugierde ausprobiert, wie 
gross der Unterschied im Bezug auf Altera FPGAs ist, da es ein solch 
schönes Whitepaper bei Altera schlicht nicht zu geben scheint.

Die Ergebnisse sind eigentlich recht eindeutig (Zumindest für mein recht 
kleines Submodul):

CycloneII-C6: sync reset: 224 LUT, fmax 64,3MHz; asnyc reset: 187LUT, 
69,5MHz
(Vergleichbare Ergebnisse für CycloneIII-C7)

Dem StratixIII wiederum ist es ziemlich Wurst, da ändern sich (mit dem 
selben Design) die Syntheseergebnisse marginal.
Der Unterschied ist nur der Reset für insgesamt 73FFs.

Weiter sagt z.B. der Altera DRC zu einem asynchronen Reset folgendes:
Warning: (Medium) Rule R102: External reset signals should be 
synchronized using two cascaded registers. Found 1 node(s) related to 
this rule.
Quartus möchte also wohl einen synchronisierten Reset, der allerdings 
auf die async_reset Pins der FFs geführt wird.

Fazit:
Literaturstudium (für die Zielplattform!) und ggf. eigene Tests sind bei 
solchen Streitfragen äusserst wichtig. Das "richtig" für alle 
Plattformen gibt es nicht.

p.s. Übrigens gilt das gleiche auch für Verilog :-)

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann benutze mal ein Wörterbuch!
"extraneous" bedeutet nicht zusätzlich, sondern belanglos...

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> This coding style will generate extraneous logic as shown in Figure 1.
extraneous:
    fremd
    irrelevant
    unerheblich
    unwesentlich
    fremdländisch
    nicht relevant
    nicht zur Sache gehörig
In der Sache bleibt es gleich: es wird keine unwesentliche oder 
belanglose (oder was auch immer) Logik generiert, weil eben überhaupt 
keine Logik erzeugt wird.

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
> In der Sache bleibt es gleich: es wird keine unwesentliche oder
> belanglose (oder was auch immer) Logik generiert, weil eben überhaupt
> keine Logik erzeugt wird.

Doch, es wird unnötige Hardware generiert: Ein ladbares Flipflop!
In einem FPGA ist das egal. Dort hat man multifunktionale FFs. Aber in 
einem ASIC wird nun eine andere Zelle, nämlich eine mit lade Eingang, 
verwendet. Und ein solches ist nicht unerheblich größer.

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry für den Doppelpost.

Wie Du schon selber geschrieben hast, es kommt auf die darunter liegende 
Technologie an ;)

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Aber in einem ASIC wird nun eine andere Zelle,
> nämlich eine mit lade Eingang, verwendet.
Richtig, ich hatte überlesen, dass in den PDFs eigentlich nur von ASICs 
geschrieben wird  :-/

Autor: Fpga Kuechle (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Nochmal: wenn du ein externes Signal mit dem Takt einsynchronisierst und
>dieses synchronisierte Signal verwendest wirst du nie Probleme haben
>solange zu fmax nicht verletzt.

Genau deshalb kannst du ein Problem haben! Das Einsynchronisieren nutzt 
dir bei der Verwendung als asynchroner Reset wenig, da die statische 
Timinganalyse beim Place and route Pfade die an asynchronen Eingängen 
enden nicht erfasst. Es kann dir sehr wohl passieren, das ein Teil der 
Schaltung aus dem reset fällt, während der andere Teil sich noch im 
selben befindet. Auch bei der Verwendung des dedizierten Reset 
Netzwerkes (Xilinx:StartUp-Komponente). Deshlab rät ja Xilinx seit 
VirtexII vom asnychronen Reset insbesonders bei großen FPGA's ab.

Ein PERIOD constraint erfasst eben nicht die Pfade vom Ausgang der 
Synchronisierstufe bis zum nächsten Eingang. Das kann daher schon mal 
länger als eine Periode (oder eine halbe bei DDR -Output-FF) dauern. Bei 
Xilinx muss du dann schon ein FROM TO constraint setzen um ein 
asynchrones Erwachen zu verhindern, aber dann kannst du auch gleich 
einen synchronen Reset nutzen.


Die FF bei Altera haben beide Eingänge - asynchron und synchron - 
deshalb ist bei diesen kein Vorteil bei der Resourcenausnutzung für 
synchron feststellbar. Falls die Implementierung mit synchr. Reset 
langsamer ausfällt, hilft es das letzte Synchronisier-FF zu 
vervielfachen, also den "vorsynchronisierten" Reset sternförmig zu 
verteilen und so mehrere lokale synchrone Resetquellen zu erzeugen.

MfG,

Autor: ein Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Die FF bei Altera haben beide Eingänge - asynchron und synchron -
> deshalb ist bei diesen kein Vorteil bei der Resourcenausnutzung für
> synchron feststellbar.

Sie haben laut Handbuch eine dedizierte synchrone Load and Clear Logik. 
Den zweiten Satz kann ich jedoch nicht unterschreiben, ein praktischer 
Versuch zeigt mir jedenfalls deutliche Unterschiede zwischen asynchron:
   always @(posedge clk or negedge reset_n)
     begin
      if (!reset_n)
       phase <= 33'sd0;
      else if (enable)
       phase <= result2;
     end

und synchron:
   always @(posedge clk)
     begin
      if (!reset_n)
       phase <= 33'sd0;
      else if (enable)
       phase <= result2;
      end

Die Werte hab ich weiter oben ja schon geschrieben. Aber hier gehts ja 
um die Theorie, also bin ich mit meiner Praxis jetzt mal ruhig.

Autor: chef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
*******************************
Keine Asynchronen Resets bauen!
*******************************

Ist bei FPGAs kontraproduktiv!

Meistens braucht man nicht einmal einen globalen Reset, weil die 
Bausteine in definierte Startzustände gebracht werden können.

Das einzige, was es braucht ist ist Möglichkeit, ALLE state machines 
wieder in einen Startzustand zu bringen. Das geht am besten voll 
synchron mit ihrem jeweiligen Takt.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Meistens braucht man nicht einmal einen globalen Reset
Meistens gibt es nicht mal einen globalen Reset, denn aktuelle FPGAs 
haben kein dediziertes globales Reset-Netzwerk mehr...
Fazit: Jeder Reset muß aufwändig quer durchs ganze FPGA geroutet werden.

Jeder sollte sich die Frage stellen:
Wofür brauche ich an dieser Stelle einen Reset?
Und wenn die Antwort lautet:
Nur für den Power-Up und den Reset-Taster.
Dann hilft keine Ausrede mehr, denn:
Power-Up-Zustände für Register können als Defaultwerte angegeben werden.
Den Reset-Taster drückt ausser dem Entwickler niemals irgendjemand.
(Und falls doch, dann ist das Design noch nicht fertig.)

Autor: Der Besucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

also ich bevorzuge die Reseteinsynchronisierung in folgender Art.
Reset wird asynchron ausgelöst und mit der fallenden Clockflanke 
losgelassen.

Hier mal ein einfaches Beispiel:

signal schieberegister : std_logic_vector(1 downto 0);
...
process (ext_resetsignal, clock)
begin
 if ext_resetsignal = '1' then
  schieberegister <= "00";
 elsif falling_edge(clock) then
  schieberegister <= schieberegister(0) & '1';
 end if;
end process;

reset <= schieberegister(1);


Ansonsten (zur eigentlichen Frage): wenn der Reset mit 2 Flipflops 
einsynchronisiert wurde ist das kein asynchroner Reset mehr, da er die 
Clock benötigt um eine Auswirkung zu haben. Das ist bei der Schaltung 
hier nicht der Fall.

Zu beachten ist, dass sich die meisten hier im Forum mit FPGAs 
beschäftigen. Die Vorschläge sind manchmal recht ungeeignet für ein 
ASIC. Und gerade beim Reset scheint das ganz besonders der Fall zu sein.

Der Besucher

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Reset wird ... mit der fallenden Clockflanke losgelassen.
Verwendest du auch im restlichen Design den fallenden Takt?
Falls nein, dann hast du ja nur die halbe Zeit für das Routing dieses 
Reset-Signals zur Verfügung, um die Setupzeit tsu der angeschlossenen 
FFs nicht zu verletzen...
Denn wie gesagt: im FPGA gibt es kein Reset-Netz. Das wird alles 
handverdrahtet.

> Zu beachten ist, dass sich die meisten hier im Forum mit FPGAs be-
> schäftigen. Die Vorschläge sind manchmal recht ungeeignet für ein ASIC.
Ja, gut, das Forum heißt ja auch FPGA, VHDL & Co  ;-)
Und auch die Frage ganz zu Beginn des Freds bezog sich ziemlich 
definitiv auf ein FPGA:
>>>> synchronisiere einen Reset ... über 2 Flipflops ins FPGA ein.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Zweifel hätte ich auch den Reset auf der entgegengesetzten Taktflanke 
losgelassen. Wenn ich ihn mit der gleichen Taktflanke loslasse mit der 
auch die Register arbeiten habe ich ja viel eher ein race zwischen dem 
gerade losgelassenen Reset und dem Taktnetzwerk.

@Fpga Kuechle: Es gibt ja zb Reset Removal bei der Timing-Analyse, wird 
sowas dabei nicht berücksichtigt?

Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube an dieser Stelle muss erst noch mal geklärt werden, was genau 
ein asynchrones Reset ist! Asynchron bedeutet, dass ein Register (FF) 
unabhängig von seinem Clock in einen bestimmten Zustand wechselt. Dabei 
ist es völlig unabhängig ob das Reset zuvor einsynchronisiert wurde oder 
nicht.

Ganz gefährlich wird es wenn man dieses asynchrone Signal nicht in Bezug 
zu dem verwendeten Takt des Registers bringt. Stichwörter: 
Metastabilität, undefinierte Zustände, etc.

Damit es mit dem asynchronen Reset zu keinen Schwierigkeiten kommt, muss 
das Reset-Signal mit dem zugehörigen Takt in Verbindung gebracht werden. 
Sprich: einsynchronisiert.

Es gibt aber einige weitere wichtige Kriterien, die für die Verwendung 
eines asynchronen Resets wichtig sind:
- Es muss glitchfrei sein. Daher keine Kombinatorik sondern immer ein 
Ausgang eines Registers!
- Es muss das Timing des Resetpfades sichergestellt sein. Constraining!
- Es muss eine Mindestlänge haben. Sonst kann es zu Metastabilität 
führen.

Vor allem letzter Punkt wird oft nicht beachtet. Es schwirren dazu viele 
Codefragmente die genau diesen Punkt unberücksichtigt lassen. Folgender 
geposteter Code steht für ein solches fehlerhaftes Beispiel:
> process (ext_resetsignal, clock)
> begin
>  if ext_resetsignal = '1' then
>   schieberegister <= "00";
>  elsif falling_edge(clock) then
>   schieberegister <= schieberegister(0) & '1';
>  end if;
> end process;
reset <= schieberegister(1);
Problematisch ist daran, dass wenn das eingehende ext_resetsignal nur 
ein sehr kurzer spike (oder eine Störung) ist. Da kann es im 
schieberegister(1) am Ausgang zu einem metastabilen Zustand kommen. 
Funktionieren würde das ganze wenn das Bit schieberegister(1) nicht im 
asynchronen Resetpfad durch ext_resetsignal bedient.
Dieses Design funktioniert nur Sicher wenn das ext_resetsignal eine 
mindestlänge garantiert. Sollte aber eine Mindestlänge garantiert sein, 
dann reicht es meist auch aus das externe Reset einfach über zwei 
Register einzusynchronisieren.

Nun nochmal zur Theorie: Macht es Sinn ein Reset asynchron zu verwenden? 
Da lautet die Antwort ganz klar Ja!. Die Register bieten nun mal die 
Resourcen an, wärend man bei einer synchronen Verwendung weitere 
Resourcen verschwendet. Aber man muss da genau wissen was man tut, dass 
es zu keinen Problemen kommt. Vor allem aber stellt sich an erster 
Stelle die Frage ob ein Reset überhaupt notwendig ist. Da hat Lothar 
völlig recht.

Autor: Fpga Kuechle (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias schrieb:
> Im Zweifel hätte ich auch den Reset auf der entgegengesetzten Taktflanke
> losgelassen. Wenn ich ihn mit der gleichen Taktflanke loslasse mit der
> auch die Register arbeiten habe ich ja viel eher ein race zwischen dem
> gerade losgelassenen Reset und dem Taktnetzwerk.
>
> @Fpga Kuechle: Es gibt ja zb Reset Removal bei der Timing-Analyse, wird
> sowas dabei nicht berücksichtigt?

Was meinst du mit reset removal?

Allgemein zur Timing analyse, prinzipiell kann jeder Pfad bei der Timing 
Analyse und damit beim Place und Route berücksichtigt werden. Und jeder 
Pfad kann auch ignoriert werden. In meinem Beitrag habe ich 
herausgehoben, das beim üblichen Vorgehen (PERIOD constraint setzen, I-O 
Pfade constrainen, sonst nix), die Pfade die an den asynchronen 
Eingängen enden NICHT analysiert werden. Das bedeutet sehr 
unterschiedliche und unter Umständen sehr lange Laufzeiten. Um eine 
maximale Laufzeit in dem Netzwerk zu garantieren, muß ein anderes 
constraint gesetzt werden. (die constraint PERIOD und FROM To beziehen 
sich hier auf die Xilinx-Tools).

MfG,

Autor: Fpga Kuechle (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias G. schrieb:

> Nun nochmal zur Theorie: Macht es Sinn ein Reset asynchron zu verwenden?
> Da lautet die Antwort ganz klar Ja!. Die Register bieten nun mal die
> Resourcen an, wärend man bei einer synchronen Verwendung weitere
> Resourcen verschwendet.

Sorry, das stimmt so allgemein gesprochen nicht. Bei Xilinx kann man die 
FF entweder mit synchronen (SET/RESET) oder asynchronen (PRESET/CLEAR) 
Eingängen konfigurieren. (asynchron SET/RESET ist hier keine zusätzliche 
Resource sondern ein entweder .. oder) Werden nun wie bei einem Reset 
üblich, alle oder die meisten die FF asynchron initialisiert, muss man 
für setzen/löschen im "Normalbetrieb" Logik vor den Dateneingang D und 
das enable CE synthetisieren. Das führt insbesonders bei FSM zu 
zusätzlichen Logikleveln (mehr resourcenverbrauch) und verlangsamt das 
Design.
Hier (Xilinx) ist der asynchrone Reset eine Verschwendung an ressorucen)

Unklar bleibt die  Begründung warum ein Design mit (ausschliesslich) 
synchronen Reset/Set mehr Resourcen benötigen soll als eines mit 
asynchronen. Bitte erläutern.


MfG,

Autor: Matthias G. (mgottke)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Fpga Kuechle schrieb:
> Unklar bleibt die  Begründung warum ein Design mit (ausschliesslich)
> synchronen Reset/Set mehr Resourcen benötigen soll als eines mit
> asynchronen. Bitte erläutern.

Ich habe dazu mal ein einfaches Beispieldesign geschrieben. Das 
Einsynchronisieren des Resets habe ich mal großzügig weg gelassen.
library ieee;
use ieee.std_logic_1164.all;

entity async_sync_reset is port
(
   clk     : in  std_logic;
   rst     : in  std_logic;
   data    : in  std_logic_vector (3 downto 0);
   q_async : out std_logic;
   q_sync  : out std_logic
);
end async_sync_reset;

architecture behavior of async_sync_reset is

begin

   async_proc : process (rst, clk)
   begin
      if rst = '1' then
         q_async <= '0';
      elsif rising_edge(clk) then
         q_async <= data(0) and data(1) and data(2) and data(3);
      end if;
   end process;

   sync_proc : process (clk)
   begin
      if rising_edge(clk) then
         if rst = '1' then
            q_sync <= '0';
         else
            q_sync <= data(0) and data(1) and data(2) and data(3);
         end if;
      end if;
   end process;

end behavior;
Dabei habe ich das ganze im Cyclone 3 implementiert. Der hat (vielleicht 
im Gegensatz zu Xilinx) keinen synchronen Reseteingang am FF. Das 
Resultat des Technology Map Viewers ist im Anhang zu sehen. Dabei wird 
schnell deutlich, dass die Variante mit dem asynchronen Reset nur ein 
LUT4 benötigt und das mit dem synchronen Reset zwei. Daher Ressourcen 
verschwendet und Geschwindigkeit verschenkt. Bei anderen Technologien 
kann das aber auch anders sein.

Ich habe das ganze auch einmal testweise nur mit dem asynchronen Teil 
und einmal mit dem synchronen Teil compiliert. Einmal wird 1 "Total 
logic elements" benötigt und einmal 2.

MfG

Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uups, zwei mal das gleiche Bild Sorry. Ich wollts nur einmal hochladen.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> Ich habe dazu mal ein einfaches Beispieldesign geschrieben.
> Dabei habe ich das ganze im Cyclone 3 implementiert. Der hat
> (vielleicht im Gegensatz zu Xilinx) keinen synchronen Reseteingang am FF.
Ich habe das mal für Xilinx synthetisieren lassen. Und das Ergebnis: es 
wird einfach nur die Betriebsart des FFs umgeschaltet (siehe 
Screenshot).

Offenbar sind die Altera-FPGAs eher auf die traditionelle Schreibweise 
(wie sie in jedem Buch zu finden ist) mit asynchronem Reset ausgelegt.

Über was man sich auf jeden Fall im Klaren sein sollte:
Nicht das Eintreten in den Resetzustand ist kritisch. Spannend wird es, 
wenn der Resetzustand verlassen werden soll. Von solchen "trivialen" 
Dingen wie Spikes auf dem Reseteingang und daraus resultierend nur halb 
zurückgesetzten FPGAs mal abgesehen... :-o

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.