Signale reseten

[Thomas B. (thomas1)]

Ich verwende einen Spartan 3A. (XC3S50A)
Im meiner Logik habe ich am Anfang so eine Art Power Up Reset eingebaut.
Ich habe ein Reset-Signal, und während dieses auf 1 ist, wird kein 
Prozess ausgeführt. Ein Counter zählt auf 0 hinab und wenn er auf 0 ist, 
geht das Reset-Sigal auf 0. Nun werden die Prozesse auf die Flanke des 
Clocks ausgeführt:

power_up_reset: process(s_reset, CLK_25M)
begin
   if s_reset = '1' then
      if rising_edge(CLK_25M) then
         if sv_pur_cnt > x"00000" then
            sv_pur_cnt <= sv_pur_cnt - 1;
            s_reset = '1';
         else
            s_reset = '0';
         end if;
      end if;
   end if;
end process power_up_reset;

Die anderen Prozesse fangen nun folgendermassen an:

other_process: process(s_reset, CLK_50M)
begin
   if s_reset = '1' then
      -- soll ich hier nun die Signale, die für diesen Prozess deklariert wurden, reseten/initialisieren?
   elsif rising_edge(CLK_50M) then
      --...
      --...
   end if;
end process other_process;

Wenn ich die Signale vor dem Begin der Behavioral bereits definiert und 
mit einem initialen Wert versehen habe, ist es dann noch erforderlich, 
sie z.B. während dem Power Up Reset noch extra zu initialisieren, damit 
sie 100% sicher den Wert haben, den ich will?
Oder behalten sie auf jeden Fall den Wert, der ich ihnen bei der 
Definition mitgegeben habe?

signal s_counter : STD_LOGIC_VECTOR(7 downto 0) := x"FF";

Also in diesem Fall den Wert 255?

[Hans (Gast)]

Wenn du sicherstellst, daß sie während des Resets nicht verändert werden 
können behalten sie ihren Wert auch. Dafür ist ja eine initiale 
Wertezuweisung da.

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

> signal s_counter : STD_LOGIC_VECTOR(7 downto 0) := x"FF";
Das ist für den Power-Up ausreichend.
Lies dazu mal den Beitrag "Xilinx und die Resets"

Die Tools sind zwischenzeitlich so schlau, dass sie sich die Initwerte 
aus der Resetbeschreibung herausklauben, wenn kein Initwert angegeben 
wurde.

signal sig : std_logic;              -- kein INIT-Wert
:
process(s_reset, CLK_50M)
begin
   if s_reset = '1' then
      sig <= '1';                     --> wird mit Reset-Wert initialisiert
   elsif rising_edge(CLK_50M) then
      :
   end if;
end process;

Beim Verwenden von Initwerten sieht das dann wesentlich schöner aus:

signal sig : std_logic := '1';        -- INIT-Wert
:
process(CLK_50M)
begin
   if rising_edge(CLK_50M) then
      :
   end if;
end process;

Sowas ist dann aber z.B. für einen Spartan 6 tödlich:

signal sig : std_logic := '0';        -- INIT-Wert ...
:
process(s_reset, CLK_50M)
begin
   if s_reset = '1' then
      sig <= '1';                     -- ... ungleich Reset-Wert !!!
   elsif rising_edge(CLK_50M) then
      :
   end if;
end process;

Denn der S6 verwendet (vereinfacht) die selbe Logik für Reset und Init.

Fazit: Reset nur, wo einer nötig ist.
Und nur für die Reset-Taste vom Entwickler ist kein Reset nötig.

BTW:
Eine Reset-Beschreibung wie in deinem ersten Codeausschnitt solltest du 
dir wegen der unnötigen verwirrung anderer ersparen.

[Anguel S. (anguel)]

Und keine asynchronen Resets verwenden! Auf Reset immer synchron, d.h. 
innerhalb von if rising_edge(clk) prüfen! Das Reset muss dann auch aus 
der Sensitivity-List verschwinden. Das spart Ressourcen.

Falls Du wirklich asynchrone Resets von außen hast, müssen diese dann 
einsynchronisiert werden.

[Thomas B. (thomas1)]

Den Reset hatte ich aus Hardwaregründen eingerichtet. Einfach, dass das 
FPGA mal ein wenig wartet, bevor es die Signale der Hardware anguckt.

Warum sollte man keinne asynchronen Resets verwenden? Oder besser 
gefragt, was ist genau der Unterschied auf der Logik-Ebene?

Diese Synthesetools sind einfach schon extrem verblüffend! Was die alles 
können! Vor allem die Softwareentwickler müssen ihr FPGA schon ziemlich 
im Griff haben!

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

> Warum sollte man keinne asynchronen Resets verwenden? Oder besser
> gefragt, was ist genau der Unterschied auf der Logik-Ebene?
Die Flipflops werden in den asynchronen Modus konfiguriert. Deshalb 
brauchst du zusätzliche Logik, wenn du synchron auch nochmal 
zurücksetzen willst.
Drill Deep in dem Link, den ich dir gepostet habe:
Beitrag "Re: Hardware mit VHDL "richtig" beschreiben."

> Einfach, dass das
> FPGA mal ein wenig wartet, bevor es die Signale der Hardware anguckt.
Das solltest du aber anders lösen...

[Thomas B. (thomas1)]

Wie meinst Du, dass ich es lösen sollte? Mit einem verzögerten 
einschalten des FPGAs?

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

> Mit einem verzögerten einschalten des FPGAs?
Das wäre wohl die Holzhammermethode. Du kannst übrigens das 
Neukonfigurieren des FPGAs über einen Pin starten und auch zwischendurch 
mal anhalten.

> Wie meinst Du, dass ich es lösen sollte?
Warum zappeln die Signale?
Und warum darfst/willst du nicht darauf hören?

[berndl (Gast)]

Du hattest weiter oben nach dem asynchronen Reset gefragt: Das Problem 
ist, dass deine Schaltung nach einem async. Reset nicht sicher in den 
synchronen Zustand kommen kann. Du kannst nicht garantieren, dass ein 
Teil deiner Logik mit einem Takt Versatz loslaeuft. Und das kann ueble 
Probleme bringen. Ausserdem kriegst du keine sinnvolle Angabe uebers 
Timing bei async. Reset. Also: Wenn Reset, dann sauber 
einsynchronisieren und als ganz normales Logiksignal behandeln.

Generell zum Thema Reset: Kann schon sinnvoll sein, wenn du z.B. eine 
PLL verwendest und warten willst bis die sauber eingeschwungen ist (aber 
auch da wieder: sauber einsynchronisieren sonst kann der Schuss nach 
hinten los gehen). Und falls jemand fragt: Ja, ich hatte schon SRAMs im 
Design, die sich durch eine Timing-violation beim "lesen" selber 
ueberschrieben haben. Also, Reset muss nicht, kann aber sinnvoll sein...

Gruss,
- berndl

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

> Also, Reset muss nicht, kann aber sinnvoll sein...
Wie im WP272 so schön beschrieben:

Get Smart About Reset:
Think Local, Not Global

http://www.xilinx.com/support/documentation/white_papers/wp272.pdf