Detailfrage Reset

[Heinrich H. (Firma: Ich.AG) (hhanff)]

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_papers/wp272.pdf ) 
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;

[Klaus (Gast)]

Heinrich H. schrieb:
> Muss ich den
> von außen kommenden Reset also erst 2 fach eintakten bevor ich ihn als
> Reset verwenden kann?

JAAAA!  ;-)

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

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.

[Aua (Gast)]

> 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):


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

[Aua (Gast)]

Gibt es eigentlich auch von Altera, Lattice und ACTEL Papers bezüglich 
Reset-Strategien?

[Heinrich H. (Firma: Ich.AG) (hhanff)]

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.

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

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-im-Prozess.html
http://www.lothar-miller.de/s9y/categories/6-Clock-Enable

[Heinrich H. (Firma: Ich.AG) (hhanff)]

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 (Gast)]

Aber so ein Reset-Button ist doch was Feines, vor allem zu Beginn einer 
Entwicklung ... ;-)

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

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

[Heinrich H. (Firma: Ich.AG) (hhanff)]

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 (Gast)]

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.

Heinze schrieb:
> Aber so ein Reset-Button ist doch was Feines, vor allem zu Beginn einer
> Entwicklung ... ;-)

Einen FPGA "resetet" man aber in diesem Falle sinnvollerweise in dem man 
ihn neu lädt.

[Heinrich H. (Firma: Ich.AG) (hhanff)]

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

[Heinze (Gast)]

>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 ;-)

[Heinrich H. (Firma: Ich.AG) (hhanff)]

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)

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

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).

[Entwickler12345 (Gast)]

Hallo,

das ein Reset immer einsynchronisiert werden muss halte ich für nicht zu 
Ende gedacht.
Was ist, wenn dein Kunde einen harten asynchronen Reset erwartet? Z.B 
weil eine Anlage bei Notaus sofort stehen muss ohne jegliche 
Verzögerungszeit?

Dafür gibt es eine Lösung die heißt: Asynchron rein, Synchron raus
--> Das einsynchronisierte Reset auf ein OR mit dem AR
Dadurch steht die Anlage sofort aber eine FSM läuft nach dem loslassen 
wieder definiert an, weil alle FFs das loslassen des Resets gleichzeitig 
sehen.

Aber prinizpiell gebe ich euch recht. Ein Reset, egal ob asynchron oder 
synchron, braucht man in den wenigsten Fällen.

Das Vorinitialisieren von Signalen mi := braucht man auch nicht immer, 
wenn man weiß, dass das Signal sonst immer den Zustan ganz links hat.
-std_logic: U
-integer -xxx
-ein definierter state_type hat den ersten state usw usw ....


Gruß

[D. I. (Gast)]

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

[Entwickler12345 (Gast)]

Eigentlich nicht, aber wenn es so gefordert ist dann muss das so.
Aber keine Ahnung ob das jemand so hart fordert

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

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... ;-)

[Entwickler12345 (Gast)]

> Sicherheitskritische Geschichten dürfen trotzdem auch mal 50ns
> dauern....
Wenns erlaubt ist... ok

> Zeig mir das mal in der Hardware. Da wird ein uninitialisierter
> std_logic gleich mal ungefragt auf '0' initialisiert...
In der Hardware natürlich nicht ;)

[berndl (Gast)]

Lothar Miller schrieb:
> 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....

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.

[Heinrich H. (Firma: Ich.AG) (hhanff)]

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...

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

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...

[P. K. (pek)]

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 (Gast)]

> 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.


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.

Also wie anfangs von mir erwähnt: Asynchron setzen, synchron lassen


VG, Aua

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

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 (Gast)]

>synchron lassen

Aua, synchron zur Ader lassen :-)

Natürlich muss es heißen: synchron loslassen

[Aua (Gast)]

>Da brauchst es ja auch keinen Reset, denn nach dem vorigen Bild folgt
>das nächste Bild, usw...

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?

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

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...

[Aua (Gast)]

>Warum sollte der Reset in so einem taktlosen Zustand jemand
>interessieren?

Vielleicht weil bspw. ein Logikteil, der mit einem permanent vorhandenem 
Takt läuft, den Teil mit Pixeltakt auswertet?


AUA

[Aua (Gast)]

>z.B. ein LCDisplay) dürfen eh' nicht (nur) an einem solchen unzuverlässigen
>Takt hängen...


Naja, es ist wie es ist ;-)

Wenn man die Bilddaten einer Grafikkarte über ein Pixelinterface ins 
FPGA
hieft, dann muss das wohl mit dem Pixeltakt laufen oder?

[Xenu (Gast)]

Hier wird schon wieder das Märchen von der Metastabilität als 
Hauptproblem bei asynchronen Signalen verbreitet.

Probleme mit asynchronen Signalen haben aber so gut wie nie was mit 
Metastabilität zu tun, sondern sind Laufzeitprobleme.

Darüber hat vor Jahren Peter Alfke, ehemaliger Chef-Appplikations-
ingeneur bei Xilinx, in der Newsgroup comp.arch.fpga ein schönes Posting 
geschrieben:

http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/c6594798db796f15/aa068f26d85cd0a7

[berndl (Gast)]

Xenu schrieb:
> Probleme mit asynchronen Signalen haben aber so gut wie nie was mit
> Metastabilität zu tun, sondern sind Laufzeitprobleme.

genau darueber reden wir doch! Es geht darum, dass deine Maschinerie 
sauber loslaeuft und nicht schon beim ersten Takt ins stolpern (evtl. 
undefinierter Zustand) kommt. Und wuerde ich mit meinen Ausgangspins 
einen Motor oder einen Herzschrittmacher ansteuern, dann sollte ich mir 
sehr genau ueberlegen, was ich wie da einbaue.

[Aua (Gast)]

>Probleme mit asynchronen Signalen haben aber so gut wie nie was mit
>Metastabilität zu tun, sondern sind Laufzeitprobleme.

Nenn es wie du willst! Der Name spielt keine Rolle, vielmehr das 
Verständnis
der Auswirkung.


AUA

[asdf (Gast)]

Heinrich H. schrieb:
> Also fasse ich zusammen:
>
> 3. Die Prozessvariante mit synchronem Reset ist vorzuziehen, da weniger
> Resourcen verbraucht werden.

Da muss ich dir teilweise widersprechen. Altera beispielsweise wünscht 
sich einen asynchronen (aber einsynchronisierten) Reset und produziert 
damit definitiv kleinere Logik als mit synchronem Reset. Wers nicht 
glaubt möge es selbst ausprobieren. Da gibt es übrigens auch 
unterschiede zwischen Cyclone und Stratix, dem Stratix isses eher egal, 
der Cyclone leidet sehr stark unter synchronen Resets.


> 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.

Falls eine Umsetzung des Designs in Asic nie passieren wird ok, sonst 
könnte ein Reset später hilfreich sein.