Hallo!

Synchroner <-> asynchroner Reset wurde ja schon sehr oft behandelt.
Trotzdem habe ich eine Frage die ich mit Google und diesem Forum nicht 
eindeutig klären konnte.

Im Xilinx WP272 ( 
http://www.xilinx.com/support/documentation/white_... ) 
wird allgemein von der Verwendung eines asynchronen Resets abgeraten.

1. Wenn ich einen Prozess wie folgt aufbaue (allgemein als "synchronoer 
Reset" bekannt):

  sync_p : process (clk_i) is
  begin  -- process sync_p
    if rising_edge(clk_i) then          -- rising clock edge
      -- rst_i ist der direkt von außen kommende Reset
      if rst_i = '1' then               -- synchronous reset (active high)
      -- [...]
      end if;
  end if;
end process async_p;

verletze ich die goldene Regel, dass externe Signale erst 2 mal 
registert werden müssen um Metastabilitäten zu vermeiden. Muss ich den 
von außen kommenden Reset also erst 2 fach eintakten bevor ich ihn als 
Reset verwenden kann?

2. Würde abgesehen vom möglichen höheren Resourcenverbrauch noch etwas 
gegen die Verwendung eines asynchronen Resets sprechen wenn ich den von 
außen kommenden Reset 2 fach eintakte und den Prozess dann so aufbaue 
(allgemein als "asynchronoer Reset" bekannt):

async_p: process (clk_i, rst_s) is
begin  -- process async_p
  -- rst_s wird in einem anderen Prozess 2 fach eingetaktet!
  if rst_s = '1' then                   -- asynchronous reset (active high)
    
  elsif rising_edge(clk_i) then         -- rising clock edge
      -- [...]
  end if;
end process async_p;

Heinrich H. schrieb:
> Muss ich den von außen kommenden Reset also erst 2 fach eintakten bevor
> ich ihn als Reset verwenden kann?
Ja. Das asynchronste Signal schlechthin ist der Reset. Und asynchrone 
Signale müssen eingetaktet werden.

> 2. Würde abgesehen vom möglichen höheren Resourcenverbrauch noch etwas
> gegen die Verwendung eines asynchronen Resets sprechen
Richtig, die Flipflops werden bei Xilinx in einen anderen Modus 
geschaltet. Das führt zum erhöhten Ressourcenverbrauch.
Und der Reset muss wie jedes x-beliebige andere Signal manuell 
durchverdrahtet werden. Er nimmt also nicht nur ein wenig was weg, 
sondern ganz hübsch viel. Insbesondere Routing-Ressourcen...

> 2. Würde abgesehen vom möglichen höheren Resourcenverbrauch noch etwas
> gegen die Verwendung eines asynchronen Resets sprechen
Was spricht denn für einen Reset?

> Im Xilinx WP272  wird allgemein von der Verwendung eines
> asynchronen Resets abgeraten.
Es wird darin viel grundlegender gefragt, ob ein "globaler" Reset 
(Resetpin/Resettaster) überhaupt nötig ist. Und i.A. lautet die Antwort 
darauf: nein.

Lothar Miller schrieb:
>> Im Xilinx WP272  wird allgemein von der Verwendung eines
>> asynchronen Resets abgeraten.
> Es wird darin viel grundlegender gefragt, ob ein "globaler" Reset
> (Resetpin/Resettaster) überhaupt nötig ist. Und i.A. lautet die Antwort
> darauf: nein.
Richtig. Man kann benötigte Default Werte auch über das := Konstrukt 
übergeben und so komplett auf den globalen Reset verzichten.
Z.B.:

signal lm73_s           : std_logic := '0';

Im Moment streube ich mich noch davor, weil ich nicht weiß ob das := 
Konstrukt nur von Xilinx unterstützt wird und man sich so evtl. den 
Umstieg auch einen anderen Hersteller verbaut. Ich habe sogar noch 
gelernt, dass die Synthese das := vollkommen ignoriert.

Aua schrieb:
> Gibt es eigentlich auch von Altera, Lattice und ACTEL Papers bezüglich
> Reset-Strategien?
Ja, aber besser versteckt...  ;-)

Heinrich H. schrieb:
> Im Moment streube ich mich noch davor, weil ich nicht weiß ob das :=
> Konstrukt nur von Xilinx unterstützt wird und man sich so evtl. den
> Umstieg auch einen anderen Hersteller verbaut.
Lattice (Synplify) kanns auf jeden Fall auch.

> Ich habe sogar noch
> gelernt, dass die Synthese das := vollkommen ignoriert.
Das lernen manche heute noch...  :-o
Aber die Synthese kann schon so einiges:
http://www.lothar-miller.de/s9y/archives/47-wait-i...
http://www.lothar-miller.de/s9y/categories/6-Clock-Enable

Aua schrieb:
> Kannst du mal den Code zeigen, der den "von außen kommenden Reset 2 fach
> eintaktet" ?
>
> In diesem Zusammenhang ist nämlich zu bemerken, dass das Loslassen des
> Resets synchronisiert sein muss. Es ist aber durchaus vorstellbar, den
> Reset asynchron zu setzen (und nur das Wegnehmen sychron zu machen).
>
> Gegen deine (if Reset='1' elsif rising_edge(Clk)) spricht aus meiner
> Sicht dann nichts.
>
> Aua

Ich hatte so etwas im Kopf:

-- purpose: Taktet den Reset 2 fach ein
-- type   : sequential
-- inputs : clk_s
-- outputs: 
rst_p: process (clk_s) is
begin  -- process rst_p

  if rising_edge(clk_s) then         -- rising clock edge
    rst_q1 <= rst_i;
    rst_s <= rst_q1;
  end if;
end process rst_p;

Heinze schrieb:
> Aber so ein Reset-Button ist doch was Feines, vor allem zu Beginn einer
> Entwicklung ... ;-)
Ja, wie der "Lampentest" an einer SPS...   ;-)

Also fasse ich zusammen:

1. Der Reset muss immer 2 fach eingetaktet werden
2. Wenn der Reset 2 fach eingetaktet wurde kann ich die Prozessvariante 
mit asynchroner Resetabfrage verwenden. Metastabilitäten entstehen dann 
nicht mehr
3. Die Prozessvariante mit synchronem Reset ist vorzuziehen, da weniger 
Resourcen verbraucht werden.
4. Wenn möglich ganz auf den Reset verzichten. Hier muss geklärt werden, 
ob der Hersteller des verwendeten Synthesetools eine Initialisierung des 
Signals via := unterstützt.

Gruß,

    Hendrik

Lattice User schrieb:
> Lothar Miller schrieb:
>> Ja, wie der "Lampentest" an einer SPS...   ;-)
Meint Ihr SPS oder SMPS???

Heinze schrieb:
>>Einen FPGA "resetet" man aber in diesem Falle sinnvollerweise in dem man
>>ihn neu lädt.
>
> Das ist aber ganz schön lästig, Kabel abziehen, wieder anstecken! Wenn
> man
> das ein paar mal macht, tun die Finger weh, und die Spannungsbuchse
> leidet auch ;-)

Alternativ das Netzteil ausschalten oder alternativ das FPGA neu flashen 
(nicht das PROM weil dauert zu lange)

Lattice User schrieb:
> Lothar Miller schrieb:
>> Ja, wie der "Lampentest" an einer SPS...   ;-)
> Wobei der Lampentest zu Zeiten in denen das noch Glühbirnchen waren
> durchaus seinen Sinn hatte.
Das schon, und man konnte damit auch gleich die Hälfte aller 
Schrittketten zurücksetzen...  :-o

Heinrich H. schrieb:
> Heinze schrieb:
>>>Einen FPGA "resetet" man aber in diesem Falle sinnvollerweise in dem man
>>>ihn neu lädt.
>> Das ist aber ganz schön lästig, Kabel abziehen, wieder anstecken! Wenn
>> man das ein paar mal macht, tun die Finger weh, und die Spannungsbuchse
>> leidet auch ;-)
> Alternativ das Netzteil ausschalten oder alternativ das FPGA neu flashen
> (nicht das PROM weil dauert zu lange)
Oder mal kurz am Ladepin zupfen (wenn die Konfiguration schon im Prom 
steckt).

nun gut ob man das "sofort" im Submikrobereich noch merkt?

Entwickler12345 schrieb:
> Was ist, wenn dein Kunde einen harten asynchronen Reset erwartet? Z.B
> weil eine Anlage bei Notaus sofort stehen muss ohne jegliche
> Verzögerungszeit?
Sicherheitskritische Geschichten dürfen trotzdem auch mal 50ns 
dauern....

Entwickler12345 schrieb:
> wenn man weiß, dass das Signal sonst immer den Zustan ganz links hat.
> -std_logic: U
Zeig mir das mal in der Hardware. Da wird ein uninitialisierter 
std_logic gleich mal ungefragt auf '0' initialisiert...

Entwickler12345 schrieb:
> Ein Reset ... braucht man in den wenigsten Fällen.
Das möchte ich mit Nachdruck unterstützen, man kann es gar nicht oft 
genug sagen... ;-)

berndl schrieb:
> es geht bei diesem harten Reset aber darum, dass der auch noch
> funktioniert wenn deine Clock ausgefallen ist! Stell dir vor deine Logik
> liefert EIN/AUS fuer eine fette Leistungselektronik...
> Deshalb async aktivieren und sync wegnehmen.

Das ist ein gutes Argument finde ich...

berndl schrieb:
> Stell dir vor deine Logik
> liefert EIN/AUS fuer eine fette Leistungselektronik...
Na gut, so weit korrekt, man findet immer was...  ;-)

Aber in so einem Fall darf der sicherheitsrelevante Not-Aus gar nicht 
einfach nur auf ein einziges Bauteil gehen. In dem Fall würde also der 
zweite Pfad greifen.
Und es reicht vermutlich auch nicht, so weit vorn in die "Nahrungskette" 
einzugreifen. Da muss dann schon die Leistung (oder wenigstens die 
Treiber der Endstufen) vom Verbraucher direkt geschaltet werden.

> Deshalb async aktivieren und sync wegnehmen.
Aber nur im Fall, dass da wirklich was Sicherheitskritisches hintendran 
hängt. Und auch nicht gleich das ganze Design, sondern nur die 
"letzte" Stufe vor den IO-Pins. Denn wie gesagt: der Reset wird über 
"normale" Routingressourcen händisch verdrahtet...

Lattice User schrieb:
> Einen FPGA "resetet" man aber in diesem Falle sinnvollerweise in dem man
> ihn neu lädt.

Naja, ich finde den Reset-Taster bisweilen ganz praktisch, wenn ich den 
SignalTap (Altera Quatus II) in einer Start-Sequenz einsetzen will.
Wenn ich nämllich das FPGA neu laden und dann noch rechtzeitig den "Run 
Analyzer" Button drücken will müsste ganz schön schnell sein...

Aua schrieb:
> Noch ein Beispiel: Grafik-Quelle mit Pixeltakt
> Kabel wird abgezogen, somit ist der Pixeltakt weg.
> Ein mit dem Pixeltakt synchronisierter Reset greift u.U. nicht mehr.
Da brauchst es ja auch keinen Reset, denn nach dem vorigen Bild folgt 
das nächste Bild, usw...

> Also wie anfangs von mir erwähnt: Asynchron setzen, synchron loslassen
Nur: es bleibt dabei (und das sollte man sich merken) dass Xilinx-FFs 
mit einem asynchronen Reset im "falschen" Modus betrieben werden...

Aua schrieb:
> Na das stimmt so nicht. Wenn ich einen Resetcontroller auf der Platine
> habe und dieser gerade einen Reset erzeugt bei nicht laufendem Pixeltakt
> (Kabel abgezogen), was passiert dann?
Nichts? Warum sollte der Reset in so einem taktlosen Zustand jemand 
interessieren? Irgendwelche relevante und timingkritische Sachen (z.B. 
ein LCDisplay) dürfen eh' nicht (nur) an einem solchen unzuverlässigen 
Takt hängen...