Countdown Zähler mit Abbruchbedingung, Initialisierungsproblem

[Marten V. (Gast)]

Tach auch,

ich habe für ein Projekt einen Countdown-Timer mit Abbruchbedingung 
geschrieben, der noch eine kleine Macke hat. Jedesmal wenn der Counter 
eingeschaltet (EN='1') bzw. (RST_N='0') zurückgesetzt wird, gibt er 
zunächst ein RDY-Signal aus und fängt dann mit dem zählen an. Das 
RDY-Signal soll jedoch erst auf '1' gesetzt werden, wenn der Zähler auch 
wirklich bis 0000...0 heruntergezählt hat. Ich muss also irgendwie die 
Reset-Bedingungen umschreiben...
Hat jemand ne Idee wie ich das Problem lösen kann ? Ich habe gerade nen 
Brett vorm Kopf...

Hier mein Code:

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
use ieee.std_logic_arith.all;

 
entity counter is
 generic( TAPS : integer := 11 );
 port(
  RST_N : in std_logic;
  EN  : in std_logic;
  CLK : in std_logic;
  D  : in std_logic_vector(TAPS downto 0);
  RDY  : out std_logic);
end entity counter;

architecture beh of counter is

signal d_int : std_logic_vector(TAPS downto 0);

begin
 
-- Counter  
  counter_p : process (CLK,RST_N,EN,D)
  variable zeros : std_logic_vector(TAPS downto 0) := (others => '0');
  begin
  if RST_N = '0' then
  d_int <= (others => '0');
  RDY <= '0';
  elsif (CLK='1' and CLK'event) then
  d_int <= D;-- Latch ?
  if (EN = '1') then 
    if ( d_int = zeros) then
      RDY <= '1';
    else
      d_int <= d_int -1;
      RDY <= '0';
    end if;
  elsif (EN ='0') then
    RDY <= '0';
    d_int <= (others => '0');
  end if;
  end if;
  end process;
  
 end architecture;

Viele Grüße
Marten

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

Herzlichen Glückwunsch!
Du hast das entdeckt, was sich "Latency" nennt.
Sowas passiert gern mal mit Signalen... :-o

Konkret:
Wenn RST_N = 0 war, dann ist d_int = 0.
Wenn jetzt RST_N = '1' inaktiv wird, ist d_int immer noch 0.
Wenn jetzt ein Takt kommt, ist für den gesamten Prozess d_int
immer noch 0.
Erst am Ende des Prozesses wird die letzte Zuweisung an d_int
tatsächlich an d_int zugewiesen.

  if RST_N = '0' then
    d_int <= (others => '0');
    RDY <= '0';
  elsif (CLK='1' and CLK'event) then
    d_int <= D;-- Latch ?
    if (EN = '1') then 
      if ( d_int = zeros) then   -- beim ersten Takt nach reset ist hier d_int = 0 !!!
        RDY <= '1';              -- --> RDY wird gesetzt.
      else
        d_int <= d_int -1;
        RDY <= '0';
      end if;
    elsif (EN ='0') then
      RDY <= '0';
      d_int <= (others => '0');
    end if;
  end if;

Marten V. schrieb:
> Hat jemand ne Idee wie ich das Problem lösen kann ?
Probier mal das:

  if RST_N = '0' then
    d_int <= D;
  :
  :

> d_int <= D;-- Latch ?
Nein, weil getaktet.

BTW:
Zum Sinn und Unsinn von asynchronen Resets wurde hier schon einiges 
geschrieben. Benutz mal die Suche hier im Forum zum Thema "Xilinx und 
die Resets" als Denkanstoss.

[Sym (Gast)]

Ein Signal ist keine Variable! Egal wo du in einem synchronen Prozess 
dem Signal einen Wert zuweist, du kannst ihn erst im nächsten Taktzyklus 
lesen.

Beachte außerdem: In der sensitivity list eines synchronen processes 
steht nur clock und reset, sonst GAR NICHTS. Dein VHDL Stil ist sehr 
gewöhnungsbedürftig. Verwende für Konstanten constant nicht variable. 
Mein Tipp: Ein ordentlicher Editor a la Xemacs.

[Marten V. (Gast)]

Guten Morgen,

und vielen Dank für eure nette Hilfe. Ich bin momentan dabei VHDL zu 
lernen, deswegen bin ich über jeder Kritik an meinem Code dankbar ;-) 
Xemacs habe ich mir angeschaut, fühle mich aber son bisschen vom 
Funktionsumfang erschlagen. Es hat aber deutlich mehr auf dem Kasten als 
Notepad++, blöd sind nur die ganzen neuen Shortcuts die man lernen muss. 
Und man muss sich das STRG+C, STRG+V abgewöhnen ;-) Ansonsten echt 
mächtig der Editor.
Mein Design funktioniert nun so wie ich es mir wünsche, besten Dank 
nochmal ;-)

Gruß
Marten

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

Marten V. schrieb:
> Mein Design funktioniert nun so wie ich es mir wünsche, besten Dank
> nochmal ;-)
Schön wäre, wenn du jetzt noch sagen würdest, was du gemacht hast. Das 
würde dann evtl. anderen helfen, die so ein Problem haben...

[Marten V. (Gast)]

Hi,
Hier meine Lösung, die jedoch noch nicht entgültig richtig ist.
Ich bin bei der Simulation noch auf ein Problem gestoßen, zu beginn des 
Prozesses sind die Daten am Eingang noch nicht gültig und werden erst zu 
einem späteren Zeitpunkt angelegt. Daraus ergibt sich, dass wenn ich im 
Reset die anliegenden Daten übernehme, mein Design Daten vom Typ 'U' 
übernimmt.

Hier mein Code:

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
use ieee.std_logic_arith.all;
-- numeric std für counter wert verwenden ???
-- 
-- 

entity counter is
  generic(TAPS : integer := 11);
  port(
    RST_N : in  std_logic;
    EN    : in  std_logic;
    CLK   : in  std_logic;
    D     : in  std_logic_vector(TAPS downto 0);
    RDY   : out std_logic);
end entity counter;

architecture beh of counter is

  signal d_int : std_logic_vector(TAPS downto 0);

begin

-- Counter  
  counter_p : process (CLK, D, RST_N)
    constant zeros : std_logic_vector(TAPS downto 0) := (others => '0');
  begin
    if RST_N = '0' then
      d_int <= D;
      RDY   <= '0';
    elsif (CLK = '1' and CLK'event) then
      d_int <= D;
      if (EN = '1') then
        if (d_int = zeros) then
          RDY <= '1';
        else
          d_int <= d_int -1;
          RDY   <= '0';
        end if;
      elsif (EN = '0') then
        RDY <= '0';
        d_int <= D;
      end if;
    end if;
  end process;
  
end architecture;

Im Anhang ein paar Waveforms aus der Simulation.

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

Marten V. schrieb:
> Ich bin bei der Simulation noch auf ein Problem gestoßen, zu beginn des
> Prozesses sind die Daten am Eingang noch nicht gültig und werden erst zu
> einem späteren Zeitpunkt angelegt. Daraus ergibt sich, dass wenn ich im
> Reset die anliegenden Daten übernehme, mein Design Daten vom Typ 'U'
> übernimmt.
Dieses D kommt aus deiner TB.
Dort sind offenbar bis zum ersten en='1' die Daten undefiniert.
Und dann wird natürlich auf einem undefinierten Zähler herumgezählt...
Zeig mal die TB.
Dort sollten für D einfach ein paar Defaultwerte angegeben werden.


Zum zeitlichen Ablauf:
es wäre besser, das en nicht genau mit dem Takt anzusteuern, denn sonst 
mußt du dich immer fragen: hat er jetzt bei der steigenden Taktflanke 
en='1' oder en='0' gesehen?
(Die Antwort daruf ist klar: er nimmt den vorhergehenden Wert, aber es 
sieht eben seltsam aus)

      d_int <= D;        
      if (EN = '1') then
        if (d_int = zeros) then
          RDY <= '1';    
        else
          d_int <= d_int -1;
          RDY   <= '0';  
        end if;
      elsif (EN = '0') then  -- *****
        RDY <= '0';
        d_int <= D;      
      end if;
    end if;

***** hier reicht ein einfache else, denn sonst bastelst du dir für die 
Simulation ein sehr seltsames Verhalten, wenn der 9-wertige std_logic EN 
mal nicht den Wert '0' oder '1' hat... :-o

Ich würde diese Zeilen so schreiben:

      d_int <= D;   -- Defaultzuweisungen
      RDY   <= '0'; -- werden später bei Bedarf überschrieben
      if (EN = '1') then
        if (d_int = zeros) then
          RDY <= '1';
        else
          d_int <= d_int -1;
        end if;
      end if;
    end if;

[Marten V. (marten-v)]

Ich habe das in der Testbench absichtlich so vorgesehen, denn der 
Counter soll in einem größeren Projekt eingebunden werden. Der Zähler 
enthält von einer anderen Einheit die Daten, die er herunterzählen soll. 
Wann die Daten anliegen ist daher unbekannt. Deswegen hatte ich gedacht, 
nach einem initialen Reset die Daten im Register des Counters auf 
"000...0" zu setzen. Da beißt sich dann aber wieder die Katze in den 
Schwanz, denn dann wird ein RDY Signal ausgegeben...

Hier meine TB:

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;

entity counter_tb is
  generic(TAPS : integer := 11);
end entity counter_tb;

architecture rtl of counter_tb is

  component counter is
    generic(TAPS : integer := 11);
    port(
      RST_N : in  std_logic;
      EN    : in  std_logic;
      CLK   : in  std_logic;
      D     : in  std_logic_vector(TAPS downto 0);
      RDY   : out std_logic);
  end component counter;

  signal d_tb       : std_logic_vector(TAPS downto 0);
  signal clk_tb     : std_logic;
  signal en_tb      : std_logic;
  signal reset_n_tb : std_logic;

begin

-- Counter  
  dut_counter : counter
    port map(
      RST_N => reset_n_tb,
      EN    => en_tb,
      CLK   => clk_tb,
      D     => d_tb);

  clk_p : process
  begin
    clk_tb <= '1';
    wait for 50 ns;
    clk_tb <= '0';
    wait for 50 ns;
  end process;

  en_p : process
  begin
    en_tb      <= '0';
    reset_n_tb <= '0';
    wait for 100 ns;
    reset_n_tb <= '1';
    wait for 100 ns;
    reset_n_tb <= '0';
    wait for 100 ns;
    reset_n_tb <= '1';
    wait for 100 ns;
    en_tb      <= '1';
    d_tb       <= "000000001000";
    wait for 1600 ns;
    en_tb      <= '0';
    wait for 1400 ns;
    reset_n_tb <= '0';
    wait for 200 ns;
    reset_n_tb <= '1';
--      wait for 200 ns;
    en_tb      <= '1';
    wait for 400 ns;
    d_tb       <= "000001000000";
    wait for 500 ns;

    wait;
  end process;
  
end architecture;

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

Marten Vohrmann schrieb:
> Wann die Daten anliegen ist daher unbekannt.
Auf jeden Fall sollten sie aber (einen Takt) vor dem Enable anliegen, 
denn sonst ist es ja schnurzegal, was da heruntergezählt werden soll...

Wenn die Daten zusammen mit dem Enable kommen, dann kannst du sie nicht 
mehr übernehmen, denn der Enable ist ja für den Zählvorgang 
verantwortlich.

[Marten V. (marten-v)]

Ja du hast recht, ich sollte das in der FSM der anderen Einheit 
berücksichtigen.
Wenn ich das enable jeweils immer einen Takt nach neuen Daten anlege, 
klappt alles wunderbar.
Gibt es dennoch eine Möglichkeit, den Counter so zu designen, dass Daten 
und EN-Signal gleichzeitig angelegt werden können ?
Mir fällt da momentan nichts besseres ein...
Vielen Dank für deine tolle Hilfe Lothar! :-)

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

Marten V. schrieb:
> Gibt es dennoch eine Möglichkeit, den Counter so zu designen, dass Daten
> und EN-Signal gleichzeitig angelegt werden können ?
Jein.
Du könntest sagen: wenn vorher en='0' war, und jetzt en='1' ist, dann 
soll nicht gezählt, sondern die Daten übernommen werden. Also eine 
Flankenerkennung basteln:

  signal last_en : std_logic;
:
:
  counter_p : process (CLK, D, RST_N)
    constant zeros : std_logic_vector(TAPS downto 0) := (others => '0');
  begin
    if RST_N = '0' then
      d_int <= D;    -- unnötig, denn erst bei Flanke von en werden die Daten validiert
      RDY   <= '0';
    elsif (CLK = '1' and CLK'event) then
      last_en <= EN; -- Merker
      d_int <= D;    -- unnötig, denn erst bei Flanke von en werden die Daten validiert
      RDY   <= '0';  
      if (EN = '1') then
        if (last_en='0') then -- steignede Flanke am en
          d_int <= D;         -- --> Daten übernehmen
        elsif (d_int = zeros) then
          RDY <= '1';
        else
          d_int <= d_int -1;
        end if;
      end if;
    end if;
  end process;

Aber ich würde das eher als eine Designschwäche ansehen denn du zählst 
dann eigentlich einen Takt falsch, weil der erste Takt ja für die 
Datenübernahme verwendet wird.

Es sei denn, du mogelst dich so raus:

      :
      if (EN = '1') then
        if (last_en='0') then
          d_int <= D-1;   
        elsif (d_int = zeros) then
        :

Aber Achtung: was machst du, wenn D = 0 ist?

> Vielen Dank für deine tolle Hilfe Lothar! :-)
De Nada... ;-)

[Marten V. (marten-v)]

Du hast mal wieder recht, ganz so rosig ist das mit der Flankenerkennung 
nicht. Ich denke ich bleibe bei meinem Design und beachte bei der 
Verwendung einfach die Tatsache, dass die Daten einen Takt vor dem 
EN-Signal anliegen müssen.
Hier meine Lösung für einen Count-Down Zähler mit generischer 
Bit-Breite:

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
use ieee.std_logic_arith.all;

entity counter is
  generic(TAPS : integer := 11);
  port(
    RST_N : in  std_logic;
    EN    : in  std_logic;
    CLK   : in  std_logic;
    D     : in  std_logic_vector(TAPS downto 0);
    RDY   : out std_logic);
end entity counter;

architecture beh of counter is

  signal d_int : std_logic_vector(TAPS downto 0);

begin

--Counter
  counter_p : process (CLK, D, RST_N)
    constant zeros : std_logic_vector(TAPS downto 0) := (others => '0');
  begin
    if RST_N = '0' then
      d_int <= (others => '0');
      RDY   <= '0';
    elsif (CLK = '1' and CLK'event) then
      d_int <= D;
      RDY <='0';
      if (EN = '1') then
        if (d_int = zeros) then
          RDY <= '1';
        else
          d_int <= d_int -1;
        end if;
      end if;
    end if;
  end process;

end architecture;

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

Und hier mein Konter-Vorschlag mit der numeric_std, synchronem Reset 
(wenn schon) und einem integer-Zähler... ;-)

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity counter is
  generic(TAPS : integer := 11);
  port(
    RST_N : in  std_logic;
    EN    : in  std_logic;
    CLK   : in  std_logic;
    D     : in  std_logic_vector(TAPS downto 0);
    RDY   : out std_logic);
end entity counter;

architecture beh of counter is
  signal d_int : integer range 0 to 2**TAPS-1 := 0;
begin
--Counter
  process begin
    wait until rising_edge(CLK);
    d_int <= to_integer(unsigned(D));
    RDY <='0';
    if (EN = '1') then
      if (d_int = 0) then
        RDY <= '1';
      else
        d_int <= d_int -1;
      end if;
    end if;
    if RST_N = '0' then
      d_int <= 0;
      RDY   <= '0';
    end if;
  end process;
end architecture;

[Marten V. (marten-v)]

Hmm auch gut :-)
Kannst du mir vielleicht kurz erklären warum du Integer-Werte genommen 
hast? Wenn man sich die Hardware anschaut, was ändert sich durch die 
Verwendung von Integerwerten?

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

Marten V. schrieb:
> Kannst du mir vielleicht kurz erklären warum du Integer-Werte genommen
> hast?
Weil dann Vergleich und Zuweisungen einfach im Klartext gemacht werden 
können. Oder vergleich mal du deinen std_logic_vector und unsigned 
Zähler auf den Wert 12345.

> Wenn man sich die Hardware anschaut, was ändert sich durch die
> Verwendung von Integerwerten?
Wenn der richtige Range angegeben ist: Nichts.

[Marten V. (marten-v)]

So, ich habe meinen Code nochmal überarbeitet. Die Daten sollen einfach 
übergeben werden und erst beim setzen des enable-Signals "en=1" soll der 
Zählvorgang beginnen.
In meiner letzten Beschreibung hatte ich eine Mischung aus 
kombinatorischen und sequentiellen Processen verwendet, die sich u.U. 
nicht auf einen FPGA abbilden lassen.
Über Feedback zu der neuen Beschreibung wäre ich euch dankbar :-)

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
use ieee.std_logic_arith.all;

entity counter is
  generic(TAPS : integer := 11);
  port(
    RST_N : in  std_logic;
    EN    : in  std_logic;
    CLK   : in  std_logic;
    D     : in  std_logic_vector(TAPS downto 0);
    RDY   : out std_logic);
end entity counter;

architecture beh of counter is

  signal   d_int      : std_logic_vector(TAPS downto 0);
  signal   next_d_int : std_logic_vector(TAPS downto 0);
  constant zeros      : std_logic_vector(TAPS downto 0) := (others => '0');

begin

  RDY <= '1' when d_int = zeros else '0';
  
  -- Kombinatorik für Zähler
  counter_comb_p : process(D, EN, d_int)
  begin  -- process counter_comb_p
    if (EN = '1') and d_int /= 0 then
      next_d_int <= d_int-1;
    else
      next_d_int <= D;
    end if;
  end process counter_comb_p;

  --Zähler Register
  counter_reg : process (CLK, RST_N)
  begin
    if RST_N = '0' then
      d_int <= D;
    elsif (CLK = '1' and CLK'event) then
      d_int <= next_d_int;
    end if;
  end process;

end architecture;

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

Ja, gut, wird schon tun...

Aber warum nimmst du zum Zählen nicht einen Integer?

Sieh dir mal an, wie man das auch machen könnte:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity counter is
  generic(TAPS : integer := 11);
  port(
    RST_N : in  std_logic;
    EN    : in  std_logic;
    CLK   : in  std_logic;
    D     : in  std_logic_vector(TAPS downto 0);
    RDY   : out std_logic);
end entity counter;

architecture beh of counter is
  signal   cnt      : integer range 0 to 2**TAPS-1 := 0;
begin

  RDY <= '1' when cnt=0 else '0';
  
  process begin
     wait until rising_edge(clk);
     if (cnt/=0 and EN='1') then
        cnt <= cnt-1; 
     end if;               
     if (RST_N='0' or EN='0' or (EN='1' and cnt=0)) then 
        cnt <= to_integer(unsigned(D));
     end if;
  end process;

end architecture;

Marten V. schrieb:
> Die Daten sollen einfach übergeben werden und erst
> beim setzen des enable-Signals "en=1" soll der Zählvorgang beginnen.
Wenn das EN weiter gesetzt bleibt, wird dann aber auch sofort 
weitergezählt...

BTW: wozu eigentlich ein Reset?

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

Aber könnte man das nicht noch ein wenig abkürzen?

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity counter is
  generic(TAPS : integer := 11);
  port(
    EN    : in  std_logic;
    CLK   : in  std_logic;
    D     : in  std_logic_vector(TAPS downto 0);
    RDY   : out std_logic);
end entity counter;

architecture beh of counter is
  signal   cnt      : integer range 0 to 2**TAPS-1 := 0;
begin
  RDY <= ready;

  process begin
     wait until rising_edge(clk);
     if (EN='0') then
        cnt <= to_integer(unsigned(D));
        RDY <= '0';
     elsif (cnt/=0) then
        cnt <= cnt-1; 
     else
        RDY <= '1';
     end if;               
  end process;

end architecture;

Allerdings mußt du hier ein wenig mit Latency aufpassen: das 
READY-Signal kommt einen Takt später...

[Marten V. (marten-v)]

Ich dachte ich verwende lieber std_logic da ich, was die Simulation und 
die Synthese angeht, auf der sicheren Seite bin. Std_logic hat ja die 
Zustände 'X', 'U', usw.

Ein Reset-Signal scheint nun wirklich überflüssig zu sein, da mein 
enable-Signal ja schon für ein Rücksetzen des Zählers sorgt.

Das Enable-Signal kommt aus einer FSM in einer höheren Hierarchie-Ebene. 
Die FSM wertet das RDY-Signal aus und setzt entsprechend nach einer 
positiven Flanke des RDY-Signals den Enable-Eingang auf 0 und setzt 
damit den Counter zurück.

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

Marten V. schrieb:
> Ich dachte ich verwende lieber std_logic da ich, was die Simulation und
> die Synthese angeht, auf der sicheren Seite bin.
Der Synthese ist das egal. Die Simulation liefe mit std_ulogic schneller 
ab (so heißt es), weil keine Auflösungstabellen (u=unresolved) 
durchforstet werden müssen...
Aber in der Praxis hat sich der std_logic durchgesetzt.