Event Counter funktioniert nur in der Simulation

[Markus (Gast)]

Hallo,

ich möchte einen Impulszähler konstruieren. Die Rahmenbedingungen sind:

- systemtakt 20MHz
- Impulse (>= 1us) sollen gezählt werden
- periodisch (z.Zt. 100ms) soll das Ergebnis gepuffert, der Zähler 
zurückgesetzt,neu gestartet werden und weiterlaufen während dann das 
gepufferte Ergebnis seriell übertragen wird

Die serielle Übertragung kommt später, wenn der Zähler mal läuft. 
Aktuell funktioniert die Zählung in der Pre-Synth Simulation.
Der Synthesizer meint allerdings die Signale "Count" und "timebase" 
wären ungenutzt (Toplevel.srr Zeile 141ff). Ausserdem werden noch 
diverse Register rausoptimiert, was ich noch nicht einordnen kann.
Ich denke mal da habe ich was nicht synthetisierbares konstruiert.

der Counter:

entity Counter is
port (
    --<port_name> : <direction> <type>;
  clk : IN  std_logic;
    reset : IN std_logic;
  Count : IN  std_logic; 
    timebase : IN std_logic;
    
    rd : IN std_logic;
    busif : OUT std_logic_vector(15 downto 0) 
);
end Counter;

architecture architecture_Counter of Counter is
  signal cnt : integer range 0 to 65535 ; --16 bit
    signal count_processed : std_logic ;
    signal outputbuffer : std_logic_vector(15 downto 0); 
    signal buffer_filled : std_logic ;

begin
   -- architecture body
  event_counter : process (clk, reset, Count, count_processed, outputbuffer, timebase, buffer_filled)
  begin
    if reset='0' then 
      cnt <= 0;
      count_processed <= '0';
      buffer_filled <= '0';
      outputbuffer <= (others => '0');
    else
      if clk = '1' and clk'event then
          --increment counter
          if timebase = '1' then
            if Count='1' then
              if count_processed='0' then
                cnt <= cnt +1;
                count_processed <= '1';
              end if;
            else
              count_processed <= '0';
            end if; -- Count=1
            buffer_filled <='0' ;
          else    -- timebase=0
            if buffer_filled='0' then
              outputbuffer <= std_logic_vector(to_unsigned(cnt, 16));
              buffer_filled <='1' ;
            end if;
          end if; -- timebase=0
      end if; --clk
      
      if clk = '0' and clk'event then
        if buffer_filled='1' then
          cnt <= 0;
        end if; 
      end if;
    end if; --reset
  end process;


  readout : process (clk, rd, busif, outputbuffer, reset)
  begin
    if reset='0' then 
      busif <= (others => 'Z');
    else
      if clk = '1' and clk'event then
        if rd='1' then
          busif <= outputbuffer ;
        else
          busif <= (others => 'Z'); 
        end if;      
      end if;
    end if;
  end process;

end architecture_Counter;

Timebase:

entity Timebase is
generic ( TEILFAKTOR : natural := 2000000); -- Berechnung: gewuenschte Zeitbasis furch Periodendauer der Haupttaktes
                                             -- also z.B.: 100ms bei 20MHz -->  0.1/0.00000005 bzw. 100/0.00005 ->  2000000

port (
    --<port_name> : <direction> <type>;
  clk : IN  std_logic; 
  timebase : OUT  std_logic
);
end Timebase;

architecture architecture_Timebase of Timebase is
  signal timer :integer range 0 to 20000000; -- bis 20 MHz
begin
   -- architecture body
   tb : process (clk)
   begin
     if clk='1' and clk'event then
        if timer < TEILFAKTOR then
          timer <= timer +1;
          timebase <= '1';
        else
          timebase <= '0';
--          if timer < (TEILFAKTOR+1) then
--            timer <= timer +1;
--          else  
            timer <= 0;
--          end if;
        end if;
     end if;
   end process;

end architecture_Timebase;

Wer kann mir den entscheidenen Tipp geben?

Vielen Dank,
Markus

[Blick mit Krausen (Gast)]

Vermischte Taktflanken.

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

use IEEE.std_logic_unsigned.all;
use IEEE.NUMERIC_STD.all;

Never ever!

Die numeric_std kann alles, was du brauchst.

process (clk, rd, busif, outputbuffer, reset)

Da gehören nur clk und reset rein. Und reset ist im Grunde nicht nötig.

      if clk = '1' and clk'event then
        ..... 
                cnt <= cnt +1;

      
      if clk = '0' and clk'event then
       ..... 
          cnt <= 0;

cnt sind 16 Flipflops. Und du möchtest da getne Flipflops haben, die mit 
beiden Flanken getriggert werden können. Hat dein FPGA sowas?

Mein Tipp: im gesamten Design nur 1 Takt und nur überall die selbe 
Flanke.

Markus schrieb:
> Impulse (>= 1us) sollen gezählt werden
Das heißt, wenn das Eingangssignal mindestens für 1us high ist? 
Vermutlich also zur Unterdrückung von Störungen...

Was soll aber passieren, wenn das Eingangssignal 10us high, dann 500ns 
liw, dann wieder 10us high ist? Ist das dann 1 gestörter Impuls, oder 
sind es 2 Impulse?

BTW: irgendwie habe ich den Eindruck, du machst das unnötig kompliziert 
mit den ganzen Enable Signalen...

Ich würde das entkoppeln und erst mal sicher stellen, dass ich nur 
gültige Impulse erkenne und verarbeite. Und das hat was mit "Entprellen" 
zu tun: erst, wenn das Signal 1us stabil ist, ist es ein valides Signal.

Wo ich das schreibe sehe ich gerade, dass du das vermutlich asynchrone 
Eingangssignal es ohne jegliche Einsynchronisierung verwendest. Das geht 
sicher schief.

[Markus (Gast)]

Lothar M. schrieb:
> Das heißt, wenn das Eingangssignal mindestens für 1us high ist?

Nicht zwingend. In der Praxis reicht es aber aus, nur diese Impulse zu 
berücksichtigen.

> Was soll aber passieren, wenn das Eingangssignal 10us high, dann 500ns
> liw, dann wieder 10us high ist? Ist das dann 1 gestörter Impuls, oder
> sind es 2 Impulse?

Das sind dann 2 Impulse. Eine Ausfilterung von Störungen ist (erstmal) 
nicht notwendig.
Bisher wird der Eventcounter eines Mikrocontrollers genutzt. Es gibt 
überlegungen auch weiterhin uC zu nutzen, allerdings wird das bei ~20 
Kanälen eher unsauber.

>
> BTW: irgendwie habe ich den Eindruck, du machst das unnötig kompliziert
> mit den ganzen Enable Signalen...

Kann sein. Es soll letztendlich festgestellt werden, wiviele Impulse in 
einer definierten Zeit angekommen sind.

Ich werde mal anfangen, die asynchronen Signale einzutakten und dann den 
Zähler neu konstruieren.

[Markus (Gast)]

Ich habe den Counter jetzt in einer Statemachine realisiert. In der 
Pre-Synth Simulation funktioniert das wie gewünscht. In der Post-Synth 
Simulation habe ich bei der funften clk-Flanke einen undefinierten 
Zustand.

Wo kann der Mist wieder herkommen?

entity Counter is
port (
    --<port_name> : <direction> <type>;
  clk : IN  std_logic;
    reset : IN std_logic;
  Count : IN  std_logic; 
    timebase : IN std_logic;
    
    rd : IN std_logic;
    busif : OUT std_logic_vector(15 downto 0) 
);
end Counter;

architecture architecture_Counter of Counter is

--    signal count_processed : std_logic ;
--    signal buffer_filled : std_logic ;


    signal count_0_int : std_logic ;
    signal count_int : std_logic ;

  signal cnt : integer range 0 to 65535 ; --16 bit
    signal outputbuffer : std_logic_vector(15 downto 0); 

    type states is(wait_for_count, count_recognized, door_closed, buffer_uptodate);
    signal state : states ;

begin

  sync : process (clk)
  begin
    if clk = '1' and clk'event then
      count_0_int <= Count;
      count_int <= count_0_int;  
    end if;
  end process;  


   -- architecture body
  event_counter : process (clk, reset)
  begin
    if reset='0' then 
      cnt <= 0;
      outputbuffer <= (others => '0');
      state <= wait_for_count ;
    else
      if clk = '1' and clk'event then

        case state is
          when wait_for_count => if timebase ='0' then
                                   state <= door_closed ;
                                 else
                                   if count_int = '1' then
                                     state <= count_recognized ;
                                     cnt <= cnt +1; 
                                   end if;    
                                 end if;
          when count_recognized => if timebase ='0' then
                                     state <= door_closed ;
                                   else
                                     if count_int = '0' then
                                       state <= wait_for_count ;
                                     end if;
                                   end if;
          when door_closed =>   outputbuffer <= std_logic_vector(to_unsigned(cnt, 16));
                                state <= buffer_uptodate ;
          when buffer_uptodate => cnt <= 0;
                                  if timebase ='1' then
                                    if count_int = '1' then
                                      state <= count_recognized ; -- Impulse beim uebergang ignorieren
                                    else
                                      state <= wait_for_count ;
                                    end if;
                                  end if;
                                                      
--          when others => state <= wait_for_count ;
        end case;

      end if; -- rising edge
    end if; --reset
  end process;


  readout : process (clk, rd, busif, outputbuffer, reset)
  begin
    if reset='0' then 
      busif <= (others => 'Z');
    else
      if clk = '1' and clk'event then
        if rd='1' then
          busif <= outputbuffer ;
        else
          busif <= (others => 'Z'); 
        end if;      
      end if;
    end if;
  end process;

end architecture_Counter;

Markus

[Markus (Gast)]

Habs gefunden. Das Problem war, daß "timebase" bei reset nicht 
initialisiert wurde:

architecture architecture_Timebase of Timebase is
  signal timer :integer range 0 to 20000000; -- bis 20 MHz
begin
   -- architecture body
   tb : process (clk, reset)
   begin
     if reset = '0' then
       timer <= 0;
       timebase <= '0' ; --  <- das hier fehlte
     else
       if clk='1' and clk'event then
          if timer < TEILFAKTOR then
            timer <= timer +1;
            timebase <= '1';
          else
            timebase <= '0';
--            if timer < (TEILFAKTOR+1) then
--              timer <= timer +1;
--            else  
              timer <= 0;
--            end if;
          end if;
       end if;
     end if;
   end process;

end architecture_Timebase;

Das Problem ist damit gelöst.

BTW: warum funktioniert die vhdl Formatierung nicht? Mache ich was 
falsch?

Markus

[Achim S. (Gast)]

Markus schrieb:
> BTW: warum funktioniert die vhdl Formatierung nicht? Mache ich was
> falsch?

[\vhdl]  statt [/vhdl]

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

Markus schrieb:
> BTW: warum funktioniert die vhdl Formatierung nicht? Mache ich was
> falsch?
Nimm den / statt des \

[Duke Scarring (Gast)]

Das nächste Mal bitte gleich die Testbench mitliefern, damit sich ein 
Problem leichter nachvollziehen lässt.

Duke

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

Markus schrieb:
> Das Problem war, daß "timebase" bei reset nicht initialisiert wurde
1. Du kannst einen Initialwert bei der Deklaration des Signals angeben, 
dann ist
2. im ganzen Design kein Reset nötig. Denn was ist dieser "Reset"? Ein 
Knopf, wo jemand draufdrückt?

[Markus (Gast)]

Lothar M. schrieb:
> 1. Du kannst einen Initialwert bei der Deklaration des Signals angeben,
> dann ist

Nein, das ist nicht möglich. Hast du selbst mal festgestellt:
Beitrag "Re: Modelsim: Zählerausgang funktioniert nicht"


> 2. im ganzen Design kein Reset nötig. Denn was ist dieser "Reset"? Ein
> Knopf, wo jemand draufdrückt?

Das wird ein Reset-Baustein.

Markus

[Blick mit Krausen (Gast)]

Markus schrieb:
> Lothar M. schrieb:
>> 1. Du kannst einen Initialwert bei der Deklaration des Signals angeben,
>> dann ist
>
> Nein, das ist nicht möglich.

Klar ist das möglich, weil das LRM das so fordert (für die Simulation). 
Für manche FPGA-Architekturen kann das auch die Synthese: 
https://docs.xilinx.com/v/u/en-US/wp272

[Markus (Gast)]

Blick mit Krausen schrieb:
> Klar ist das möglich, weil das LRM das so fordert (für die Simulation).

Da ich aber die Simulation möglichst nahe an der Realität haben möchte 
und meine FPGA-Architekturen das nicht hergibt bleibe ich beim Reset.

Markus

[Blick mit Krausen (Gast)]

Markus schrieb:
> Blick mit Krausen schrieb:
>> Klar ist das möglich, weil das LRM das so fordert (für die Simulation).
>
> Da ich aber die Simulation möglichst nahe an der Realität haben möchte

Naja, man kann unterschiedliche Nähe zur Realität simulieren, jenachdem 
wielange man auf das Ergebniss warten will. Nah an der Realität ist man 
mit einer post-P&R aka timing simu - da wartet man aber ewig ....
Und eine Simulation bleibt eine Simulation, der Realität ist das 
wurscht, die macht ohnehin was real ist.

> und meine FPGA-Architekturen das nicht hergibt bleibe ich beim Reset.
Statt (klassisch, externen) PowerUp-Reset, könnte man auch eine (µC 
gesteuerte) Initphase vorsehen.

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

Markus schrieb:
> Nein, das ist nicht möglich. Hast du selbst mal festgestellt Flash-FPGAs von 
Microsemi... Pech...

Markus schrieb:
> Da ich aber die Simulation möglichst nahe an der Realität haben möchte
Warum hat dann nicht jeder getaktete Prozess einen Reset-Pfad?

Die Sensitivliste dort ist noch zu lang:

readout : process (clk, rd, busif, outputbuffer, reset)

Das würde reichen:

readout : process (clk, reset)

Aber prinzipiell ist dieser Prozess eh seltsam, denn wenn das rd ein 
Steuersignal von außen ist, dann muss der externe Datenbus sofort 
reagieren und nicht erst beim nächsten Takt. Der ganze Prozess kann also 
auf diese Kombinatorik abgebildet werden:

busif <= outputbuffer when rd *'1' else (others => 'Z');

Wenn das aber ein Bus innerhalb des FPGAs ist, dann muss er sowieso in 
einen Multiplexer aufgelöst werden, denn im FPGA gibt es kein 'Z'.

[Markus (Gast)]

Wie bekommt man das hin, dass in Modelsim die states im Klartext 
angezeigt werden?

Markus

[Pat A. (patamat)]

Indem man für das Signal als Datentyp eine Enumeration aller States 
nimmt:

type  states (init, wait_for_count, count, done);
signal state: states;

Dann zeigt der Simulator die States im 'Klartext' an.

[Duke Scarring (Gast)]

Markus schrieb:
> Wie bekommt man das hin, dass in Modelsim die states im Klartext
> angezeigt werden?
Das geht bei 'enumeration types' automatisch.
Bei einer 'post-synthesis' oder 'post-implementation' wird natürlich 
alles std_logic bzw. std_logic_vector gemappt und die Zuordnung geht 
verloren.
Aber in 99,5% der Fälle ist eine 'post-$$$'-Simulation nicht nötig.

Duke

[Kai K. (Gast)]

Ohne das jetzt genau gelesen zu haben: Ich würde das Signal auf dem die 
Pulse passieren können per Schieberegister einsynchronisieren und dann 
aus dem seriellen Stream die Pulse rauslesen (evtl. per state machine: 
puls beginnt, puls endet). Und dann zählst Du halt wie oft die state 
machine durchgelaufen ist.

[Carsten S. (Gast)]

Immer einsynchronisieren, auch wenn dir dabei Takte verloren gehen. Das 
kann sonst ganz komische Effekte geben wie: Funktioniert mal und nach 5 
Minuten wieder nicht. Das hat mir zum Beispiel bei den Xilinx Spartans 
schon Tage an Fehlersuche gekostet.