Signale reseten

OP #1780207
Lesenswert?

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:
1
power_up_reset: process(s_reset, CLK_25M)
2
begin
3
   if s_reset = '1' then
4
      if rising_edge(CLK_25M) then
5
         if sv_pur_cnt > x"00000" then
6
            sv_pur_cnt <= sv_pur_cnt - 1;
7
            s_reset = '1';
8
         else
9
            s_reset = '0';
10
         end if;
11
      end if;
12
   end if;
13
end process power_up_reset;
Die anderen Prozesse fangen nun folgendermassen an:
1
other_process: process(s_reset, CLK_50M)
2
begin
3
   if s_reset = '1' then
4
      -- soll ich hier nun die Signale, die für diesen Prozess deklariert wurden, reseten/initialisieren?
5
   elsif rising_edge(CLK_50M) then
6
      --...
7
      --...
8
   end if;
9
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?
1
signal s_counter : STD_LOGIC_VECTOR(7 downto 0) := x"FF";
Also in diesem Fall den Wert 255?
Moderator (Firma: Titel) Persönliche Seite #1780236
Lesenswert?

> 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.
1
signal sig : std_logic;              -- kein INIT-Wert
2
:
3
process(s_reset, CLK_50M)
4
begin
5
   if s_reset = '1' then
6
      sig <= '1';                     --> wird mit Reset-Wert initialisiert
7
   elsif rising_edge(CLK_50M) then
8
      :
9
   end if;
10
end process;

Beim Verwenden von Initwerten sieht das dann wesentlich schöner aus:
1
signal sig : std_logic := '1';        -- INIT-Wert
2
:
3
process(CLK_50M)
4
begin
5
   if rising_edge(CLK_50M) then
6
      :
7
   end if;
8
end process;

Sowas ist dann aber z.B. für einen Spartan 6 tödlich:
1
signal sig : std_logic := '0';        -- INIT-Wert ...
2
:
3
process(s_reset, CLK_50M)
4
begin
5
   if s_reset = '1' then
6
      sig <= '1';                     -- ... ungleich Reset-Wert !!!
7
   elsif rising_edge(CLK_50M) then
8
      :
9
   end if;
10
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.
#1780264
Lesenswert?

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.
OP #1780281
Lesenswert?

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!
Moderator (Firma: Titel) Persönliche Seite #1780289
Lesenswert?

> 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...
Gast #1780493
Lesenswert?

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

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren