selbst resetender Counter

[vhdl-anfänger (Gast)]

Hallo.
Ich hab mir folgendes für einen Counter(umzusetzen in VHDL und auch auf 
ein FPGA zu bringen) überlegt:
Ich hab einen synchronen Reset Eingang. Jetzt will ich aber, das wenn 
ich den reset setze, das der counter auf 0 zurückspringt und dann, 
obwohl der reset noch auf 1 ist, ganz normal weiterzählt. Erst bei der 
nächsten steigenden Flanke vom reset soll wieder auf 0 zurückgesetzt 
werden, und nicht, das der Counter die ganze Zeit auf 0 bleibt solange 
rst = 1.
Macht man sowas? Führt das zu einer "unglücklichen"(sprich 
ineffizienten) HW?
Grüße

[Werktätiger (Gast)]

vhdl-anfänger schrieb:
> Hallo.
> Ich hab mir folgendes für einen Counter(umzusetzen in VHDL und auch auf
> ein FPGA zu bringen) überlegt:
> Ich hab einen synchronen Reset Eingang. Jetzt will ich aber, das wenn
> ich den reset setze, das der counter auf 0 zurückspringt und dann,
> obwohl der reset noch auf 1 ist, ganz normal weiterzählt. Erst bei der
> nächsten steigenden Flanke vom reset soll wieder auf 0 zurückgesetzt
> werden, und nicht, das der Counter die ganze Zeit auf 0 bleibt solange
> rst = 1.
> Macht man sowas? Führt das zu einer "unglücklichen"(sprich
> ineffizienten) HW?
> Grüße

in etwa so?

process(clk)
if rising_edge(clk) then
 reset_delayed <= reset;
 if reset = '1' and reset_delayed = '0' then
  count_q <= 0;
 else
  count_q <= count_q + 1;
 end if;
end if;
end process;

Sollte kein problem sein.

[vhdl-anfänger (Gast)]

ok. scheint zu funktionieren.^^
Danke

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

vhdl-anfänger schrieb:
> scheint zu funktionieren.^^
Das Speichern des vorigen Zustands und der Vergleich mit dem aktuellen 
zustand nennt sich "Flankenerkennung". Die braucht man öfter mal...

[vhdl-anfänger (Gast)]

ich weiß... ich wusste nur nicht wie ich das hier so formulieren kann... 
Hehe manchmal gehts nicht besser

[Joe F. (easylife)]

Werktätiger schrieb:

(1)  if rising_edge(clk) then
(2)    reset_delayed <= reset;
(3)    if reset = '1' and reset_delayed = '0' then
(4)      count_q <= 0;

Entsteht hier nicht eine Racecondition?

Die Zuweisung (2) passiert ja quasi gleichzeitig mit dem Vergleich (3), 
also würde (4) eigentlich eher selten ausgeführt.

Besser wäre glaube ich soetwas hier:

if falling_edge(clk) then
 reset_delayed <= reset;
end if;

if rising_edge(clk) then
 if reset = '1' and reset_delayed = '0' then
  count_q <= 0;
 else
  count_q <= count_q + 1;
 end if;
end if;

oder vielleicht auch so:

process(clk)
if rising_edge(clk) then
 if reset = '1' and reset_delayed = '0' then
  count_q <= 0;
  reset_delayed <= 1;
 else
  count_q <= count_q + 1;
  reset_delayed <= reset;
 end if;
end if;
end process;

[mhm (Gast)]

Joe F. schrieb:
> Werktätiger schrieb:
> (1)  if rising_edge(clk) then
> (2)    reset_delayed <= reset;
> (3)    if reset = '1' and reset_delayed = '0' then
> (4)      count_q <= 0;
>
> Entsteht hier nicht eine Racecondition?
>
> Die Zuweisung (2) passiert ja quasi gleichzeitig mit dem Vergleich (3),
> also würde (4) eigentlich eher selten ausgeführt.

Nochmal ansehen, wie sich Signale (erkennbar an <= in Zeile 2) in einem 
(synchronen) Prozess verhalten ;)

[Joe F. (easylife)]

Alright, sorry. Hab wohl zu lange mit Verilog gearbeitet und 
zugegebenermaßen keine Ahnung von VHDL.
In Verilog ist "<=" ein non-blocking assignment, würde also 
'gleichzeitig' mit dem if ausgeführt werden.

Wer es auch wie ich nicht wusste, hier mehr Infos:
http://www.gmvhdl.com/signals.htm

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

Joe F. schrieb:
> In Verilog ist "<=" ein non-blocking assignment, würde also
> 'gleichzeitig' mit dem if ausgeführt werden.
Und trotzdem wäre da weit&breit keine Gefahr, weil das Design vollkommen 
synchron ist. Du hättest schlimmstenfalls einen Takt Latency.

[Joe F. (easylife)]

Lothar M. schrieb:
> weil das Design vollkommen
> synchron ist.

Darin liegt ja genau das Problem.
'reset_delayed' würde seinen Zustand ändern,
während 'gleichzeitig' der Vergleich mit 'reset' stattfindet (in 
Verilog).
Je nachdem, wie viele ps dazwischen liegen, geht das gut, oder auch 
nicht.

Nicht, dass "asynchron" die Lösung wäre, da weiss man erst recht nicht, 
wie viel Zeit zwischen den Zustandsänderungen liegt...

> Du hättest schlimmstenfalls einen Takt Latency.

Was heisst "schlimmstenfalls"? Hat man, oder hat man nicht?
Und genau da fängt es an eklig zu werden.

Darum ist meiner Meinung nach die beste Lösung 'reset_delayed' zu einem 
definierten Zeitpunkt (eine halbe Clock vorher) seinen Zustand ändern zu 
lassen, bevor der Vergleich stattfindet.

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

Joe F. schrieb:
> 'reset_delayed' würde seinen Zustand ändern,
> während 'gleichzeitig' der Vergleich mit 'reset' stattfindet (in
> Verilog).
> Je nachdem, wie viele ps dazwischen liegen, geht das gut, oder auch
> nicht.
Weil alle Signale synchron sind (reset und reset_delayed) ändern sich 
ihre Pegel immer nur nach einer Taktflanke. Dann bricht Hektik aus, denn 
die Kombinatorik berechnet neue Zustände. Und die müssen nur rechtzeitig 
zur nächsten Taktflanke stabil sein. Und es ist klar, dass ein 
synchroner Zähler erst mit der nächsten Taktflanke auf einen Reset 
reagiert.
Das hat mit Verilog oder VHDL nichts zu tun. Hier geht es nur um die 
Hardware, und die ist beide Male die selbe.

Joe F. schrieb:
> 'reset_delayed' zu einem definierten Zeitpunkt (eine halbe Clock vorher)
> seinen Zustand ändern zu lassen, bevor der Vergleich stattfindet.
Auf diese Weise halbiert man sich die zur Verfügung stehende Zeit (bzw 
man verdoppelt die Taktfrequenz in diesem Pfad) und macht das Timing 
unnötigerwrise knapper.

Konkret ist es so, dass man durch die Verwendung des verzögerten Signals 
den Reset selbst nicht verzögert, sondern nur einen wiederholten Reset 
in nächsten Takt verhindert.

[Fpgakuechle K. (Gast)]

Ich hab mal die Logik skiziert ->  da kommt kein delay dazu. Selbst die 
Gatterlaufzeit durch das AND entschwindet wahrscheinlich in der 
LUT-Logikwolke die den nächsten Zählerstand ermittelt.


Vielleicht wird es sichtbarere wenn man logik und D-FF getrennt 
beschreibt.

--kombinatorischer process für Logik
process(counter_q,reset,reset_delayed_q)
begin
 if reset = '1' and reset_delayed_q = '0' then
   counter_next <= 0;
 else
   counter_next <= counter_q + 1;
  end if;
end process;

--getakter prozess für FF
process(clk)
begin
 if rising_edge(clk) then
  reset_delayed_q <= reset;
  counter_q       <= counter_next;
 end if;
end process;

MfG,

[Sigi (Gast)]

Fpga K. schrieb:
> Ich hab mal die Logik skiziert ->  da kommt kein delay dazu. Selbst die
> Gatterlaufzeit durch das AND entschwindet wahrscheinlich in der
> LUT-Logikwolke die den nächsten Zählerstand ermittelt.

Ja, denn selbst Uralt-FPGAs bauen auf LUT4 (16Bit LUT) auf,
für den Counter wird nur ein LUT-Eingang verwendet, bleiben
2 Eingänge für Reset und Reset-Delay. Damit hat man zum
einen nur eine LUT-Stufe (kein Baum) und zum Anderen keine
höhere Laufzeit. Nimmt man an, das Reset synchron ist,
kommt es durch Delay-Reset bei der Flankenerkennung zu
keiner Latenz.