Synchroner Reset in Kombinatorik

[EinVolvic (Gast)]

Hallo liebe Community,

ich hätte ein paar Fragen zu einem synchronen Reset im 
Kombinatorik-Prozess eines bestehenden VHDL-Codes. Hier mal die 
Architecture:

architecture beh of a2 is
   signal shift, shift_next : std_logic_vector(3 downto 0);
begin
   process (clk)
   begin
      if clk'event and clk='1' then
         shift <= shift_next;
      end if;
   end process;

   process (shift, reset, load, data, enable)
   begin
      if reset ='1' then
         shift_next <= (others => '0');
      elsif load = '1' then
         shift_next <= data;
      elsif enable = '1' then
         shift_next <= std_logic_vector(SHIFT_LEFT(unsigned(shift), 1));
      else
         shift_next <= shift;
      end if;
   end process;
s_out <= shift(3);
end beh;

Ich hatte mir vorher diesen Artikel durchgelesen: 
https://www.mikrocontroller.net/articles/Reset_f%C3%BCr_FPGA/CPLD

Aber dort ist dieser Fall leider nicht beschrieben.

Meine Frage ist nun:
1: Wieso genau ist der Reset im zweiten Prozess ein synchroner Reset? Da 
wird ja kein Clock vorher abefragt.
2: Ist auch ein asynchroner Reset in einer Kombinatorik möglich? Falls 
ja, wie würder der aussehen?

Vielen Dank und liebe Grüße
EInVolvic

[Blechbieger (Gast)]

Dein Reset ist weder ein synchroner, noch asynchroner Reset sondern ein 
x-beliebiges Signal das zufällig Reset heißt. Zum Reset wird es erst 
wenn es das Register shift im ersten Prozess beschreibt. Entweder vor 
dem Clock Event (asynchron) oder im Clock-Event (synchron).

[Christoph Z. (christophz)]

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.

process (reset, clk)
begin
  if reset = '1' then
    shift <= (others => '0');
  else clk'event and clk='1' then
    shift <= shift_next;
  end if;
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):

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

[EinVolvic (Gast)]

Ich danke euch zwei :) Dieses kleine Input hat mir noch zum Verständnis 
gefehlt.

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.

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

[Duke Scarring (Gast)]

Asynchrone Resets funktionieren auch dann, wenn der Takt stehen 
geblieben ist...

Duke

[Christoph Z. (christophz)]

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

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

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:

process (reset, clk, shift)
begin
  if reset = '1' or shift ="1010" then
    shift <= (others => '0');
  else clk'event and clk='1' then
    shift <= shift_next;
  end if;
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.

[EinVolvic (Gast)]

Danke für die vielen Anregungen, ich hab sie mir runtergeladen und lese 
sie gerade :)

Schönen Abend noch!