Synchroner Reset in Kombinatorik

EinVolvic schrieb:
> 2: Ist auch ein asynchroner Reset in einer Kombinatorik möglich? Falls
> ja, wie würder der aussehen?

Ein richtiger asynchroner Reset bekommst du nur, wenn am Ende auch 
Flip-Flops mit asynchronem Reseteingang verbaut werden. Üblicherweise 
macht das der Synthesizer genau dann, wenn du im ersten Prozess ein D-FF 
mit asynchronem Reset beschreibst.

1

process (reset, clk)

2

begin

3

  if reset = '1' then

4

    shift <= (others => '0');

5

  else clk'event and clk='1' then

6

    shift <= shift_next;

7

  end if;

8

end process;

Andere Varianten dieses Verhalten als VHDL Code zu schreiben, könnten 
vielleicht funktionieren und "lustige" Effekte produzieren wenn man mal 
die Tools wechselt.

Man könnte auf die Idee kommen, so etwas ähnliches wie einen asynchronen 
Reset zu beschreiben, dass sich nach aussen in etwa gleich verhält und 
mit Kombinatorik gelöst ist. (nicht zu hause nachmachen, dies ist KEIN 
Reset):

1

s_out <= (others => '0') when reset = '1' else shift(3);

EinVolvic schrieb:
> Gibt es denn irgendwelche Vorteile, wenn ich den Reset im zweiten
> Prozess ausführe statt im ersten Prozess? Die synthetisierte Logik wird
> ja immer dieselbe sein.

Falls du davon redest, ob es einen Unterschied macht, ob der SYNCHRONE 
Reset im ersten oder zweiten Prozess steht: Nein, das ist nur eine 
Stilfrage.

EinVolvic schrieb:
> Das Beispiel von Christoph ist interessant. Was ist der genaue Grund,
> warum man das nicht machen darf?

Überlege dir mal, was passiert, wenn reset wieder '0' ist. Bekommst du 
dann den gewünschten default Wert am Ausgang? Was passiert wenn reset = 
'1' und enable = '1'? Ist das das was du von einem Reset erwartest?


Dieses gute Paper wurde hier im Forum auch schon empfohlen zur 
generellen Diskussion über synchrone/asynchrone Resets und die viel 
wichtigere Frage, wie ein System wieder aus dem Reset herauskommt (und 
was mit einem Resetsignal, das von der bösen Aussenwelt kommt, noch zu 
beachten ist):
https://www.trilobyte.com/pdf/CummingsSNUG2003Boston_Resets_rev1_2.pdf

EinVolvic schrieb:
> Meine Frage ist nun:
> 1: Wieso genau ist der Reset im zweiten Prozess ein synchroner Reset? Da
> wird ja kein Clock vorher abefragt.
Weil du mit diesem Signal namens "reset" nur den Zustand änderst, der 
mit der nächsten Takflanke eingenommen werden soll.
Wenn dieses Signal "reset" aber tatsächlich von aussen kommt, dann wird 
es vor allem spannend, wenn der Reset deaktiviert wird. Denn wenn der 
die tsu/th der angeschlossenen Flipflops verletzt, nehmen die schon den 
neuen Wert ein oder behalten noch den alten.
Siehe dazu das:
http://www.lothar-miller.de/s9y/archives/70-Asynchroner-Reset.html
http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren

> 2: Ist auch ein asynchroner Reset in einer Kombinatorik möglich? Falls
> ja, wie würder der aussehen?
Ein asynchroner Reset, der aus einer kombinatorischen Verknüpfung kommt, 
ist besonders hässlich:

1

process (reset, clk, shift)

2

begin

3

  if reset = '1' or shift ="1010" then

4

    shift <= (others => '0');

5

  else clk'event and clk='1' then

6

    shift <= shift_next;

7

  end if;

8

end process;

Denn dann kann es durch Glitches und Laufzeitunterschiede bei der 
Auswertung passieren, dass für ein paar ps der Ausdruck erfüllt wird und 
alle oder sogar nur ein paar der Flipflops zurückgesetzt werden.


Christoph Z. schrieb:
> die viel wichtigere Frage, wie ein System wieder aus dem Reset
> herauskommt
Kurzform: ein Reset darf (wenns denn aus irgendwelchen Gründen oder 
persönlichen Befindlichkeiten unbedingt sein muss) ruhig asynchron 
kommen.
Er muss aber synchron deaktiviert werden.