Fehler durch Signalabgreifen

[Flachmann (Gast)]

Hallo,
ich habe folgendes Problem.
Um diverse Messungen durchzuführen brauche ich 2 Zählschleifen. Die eine 
zählt mir die Anzahl der Loops und die andere die Anzahl an clk_cycles 
in jedem Loop. Die Werte beider Counter müssen abgegriffen werden um 
diverse Switches zu setzen. Nun habe ich das folgende Problem.
Der Gesamtaufbau läuft einwandfrei und hört immer genau passend nach 
"set_n_samples" (dieser wert wird über twi gesetzt) auf.
Sobald ich nun aber die Werte der Counter abgreife "verzählt" sich 
alles.
setze ich n_samples höher als 65535 so stoppt alles immer nach einer 
bestimmten zeit, wobei mir unergründlich ist warum ausgerechnet an 
diesem zeitpunkt. manchmal hört der aufbau auch ganricht auf zu zählen.
ich habe ein paar tests vorgenommen und im folgenden ist dies 
rausgekommen("-" steht für "hält nicht an):
5->-
6->3
7->4
8->-
9->-
10->7
11->8
12->-
13->-
14->7
Ich habe absolut keine Ahnung wodran das liegt und hoffe ich kann hier 
Hilfe bekommen. Das ganzemuss bis Ende der Woche fertig sein.

Würde es vll. helfen die Counterwerte vorher noch extra in Latches zu 
legen? Ich bin mittlerweile echt ratlos. Der angehängte Code ist auch 
nur einer mehrerer Auswüchse um dem Problem Herr zu werden

Mit freundlichen Grüßen

Das ist der Code nur mit Counter:

    --start/stop pulsing      
    -- convert start signal
    process(reset, start)--, help_2)
    begin
      if reset='0' then
        start_signal<='0';
      elsif rising_edge(start) then
        if start_signal = '0' then
          start_signal<='1';
        end if;
      end if;
      if help_2='1' then
        start_signal<='0';
      end if;
    end process;


    ---- count_clks ----
    process(global_clk, reset) --, start_signal, reset)
    begin
      if reset = '0' then
        counter<=0;
      elsif start_signal='0' then
        counter<=1999;
      elsif start_signal='1' then
        if counter=0 then
          counter<=1999;
        elsif rising_edge(global_clk) and counter>0 then
          counter<=counter-1;  
        end if;
      end if;
    end process;
    
    --help counter/stopper
    process(global_clk, reset)
    begin
      if reset='0' then
        help<='0';
        help_2<='0';
      else
        if (counter = 0) then
          help<='1';
        else
          help<='0';
        end if;
        
        if (stopper = 0) then
          help_2<='1';
        elsif start_signal='0' then 
          help_2<='0';
        end if;
      end if;
    end process;
    
    ---- samples counter ----
    process(help, reset) --,counter, start_signal)
    begin
      if reset = '0' then
        stopper<=-1;
      elsif start_signal='0' then
        stopper<=-1;
      elsif start_signal='1' then
        if stopper=(-1) then
          stopper<=set_n_samples;
        elsif rising_edge(help) then
          stopper<=stopper-1;
        end if;
      end if;
    end process;

Hier der Teil der die Counter auswertet:

    -- generate pulses
    -- events
--    process(counter, reset)
--    begin
--      if reset='0' then
--        event_1<='0';
--      else 
--        if counter < 1600 then
--          event_1<='1';
--        else
--          event_1<='0';
--        end if;
--        if counter < (1600 - set_pw) then
--          event_2<='1';
--        else
--          event_2<='0';
--        end if;
--        if counter < (1600 - set_delay) then
--          event_3<='1';
--        else
--          event_3<='0';
--        end if;
--        if counter < (1600 - set_pw  - set_delay) then
--          event_4<='1';
--        else
--          event_4<='0';
--        end if;
--        if counter <(1000 + (set_pw/2)) then
--          event_5<='1';
--        else
--          event_5<='0';
--        end if;
--        if counter <(1000 - (set_pw/2)) then
--          event_6<='1';
--        else
--          event_6<='0';
--        end if;
--      end if;
--    end process;
    
    --convert events to pulses
--    process(event_1,event_2,event_3,event_4,event_5,event_6, reset, start_signal)
--    begin
--      if reset='0' or start_signal='0' then
--        TX_22<='0';
--        TX_35<='0';
--        TX_TR_22<='0';
--        TX_TR_35<='0';
--        LO_22<='0';
--        LO_35<='0';
--        RX_TR_22<='0';
--        RX_TR_35<='0';
--        ADC_Trigger<='1';      
--      else
--        case set_mode is
--          when "001" => -- copolar
--            TX_22<=event_1 and not(event_2);
--            TX_35<=event_1 and not(event_2);
--            TX_TR_22<=event_1 and not(event_2);
--            TX_TR_35<=event_1 and not(event_2);
--          
--            LO_22<=event_3 and not(event_4);
--            LO_35<=event_3 and not(event_4);
--            RX_TR_22<=event_3 and not(event_4);
--            RX_TR_35<=event_3 and not(event_4);
--            ADC_Trigger<=not(event_3 and not(event_4));
--                
--          when "010" => -- crosspolar
--            TX_22<=event_1 and not(event_2);
--            TX_35<=event_1 and not(event_2);
--            TX_TR_22<=event_1 and not(event_2);
--            TX_TR_35<=event_1 and not(event_2);
--          
--            LO_22<=event_3 and not(event_4);
--            LO_35<=event_3 and not(event_4);
--            RX_TR_22<=event_3 and not(event_4);
--            RX_TR_35<=event_3 and not(event_4);
--            ADC_Trigger<=not(event_3 and not(event_4));
--        
--          when "011" => -- calibrate
--            TX_22<=event_1 and not(event_2);
--            TX_35<=event_1 and not(event_2);
--            LO_22<=event_1 and not(event_2);
--            LO_35<=event_1 and not(event_2);
--            ADC_Trigger<=not(event_1 and not(event_2));
--        
--          when "100" => -- radiometer
--            LO_22<=event_5 and not(event_6);
--            LO_35<=event_5 and not(event_6);
--            RX_TR_22<=event_5 and not(event_6);
--            RX_TR_35<=event_5 and not(event_6);
--            ADC_Trigger<=not(event_5 and not(event_6));
--          
--          when others =>
--          
--        end case;
--      end if;
--    end process;
--  
--    -- set hv switch
--    process(reset, stopper, start_signal, modulator, event_2)
--    begin
--      if reset='0' or start_signal='0' then
--        POL_22<='0';
--        POL_35<='0';
--      else
--        case set_mode is
--          when "001" => -- copolar
--            if stopper mod 2 = 1 then
--              POL_22<='1';
--              POL_35<='1';
--            else
--              POL_22<='0';
--              POL_35<='0';
--            end if;
--                          
--          when "010" => -- crosspolar
--            if (event_2='1' and modulator='1') or (event_2='0' and modulator='0') then
--              POL_22<='1';
--              POL_35<='1';
--            else
--              POL_22<='0';
--              POL_35<='0';
--            end if;
--          
--          when "011" => -- calibrate
--            POL_22<='0';
--            POL_35<='0';
--          
--          when "100" => -- radiometer
--            if stopper mod 2 = 1 then
--              POL_22<='1';
--              POL_35<='1';
--            else
--              POL_22<='0';
--              POL_35<='0';
--            end if;
--          
--          when others =>
--        
--        end case;
--      end if;        
--    end process;

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

     elsif rising_edge(start) then
     :
        elsif rising_edge(global_clk) and counter>0 then
     :
        elsif rising_edge(help) then

Böse, böse: viele verschiedene Takte.
Genauso böse: Takt aus Kombinatorik abgeleitet (help).

      if reset = '0' then
        counter<=0;
      elsif start_signal='0' then
        counter<=1999;
      elsif start_signal='1' then
        if counter=0 then
          counter<=1999;
        elsif rising_edge(global_clk) and counter>0 then

Noch böser: kombinatorischer Reset.

Siehe dort:
http://www.lothar-miller.de/s9y/categories/34-Getakteter-Prozess
http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren

Dein Design ist durch diese Verknotungen zwar noch Verhaltensimulierbar 
(weil dort keine Laufzeiten und Timingverletzungen auftreten können), 
aber es wird niemals zuverlässig auf Hardware laufen. Mein Postulat:
Ein Design (insbesondere ein Anfängerdesign) hat genau 1 Takt, der immer 
auf dieselbe Flanke aktiv ist. Es gibt keinen (und schon gar keinen 
asynchronen) Reset. Wenn du das einhältst, dann geht es.

BTW:
Das Design wird nicht mal richtig simuliert werden, denn hier ist die 
Sensitivliste falsch:

    process(global_clk, reset)
    begin
      if reset='0' then
        help<='0';
        help_2<='0';
      else
        if (counter = 0) then
        :
        end if;
        
        if (stopper = 0) then
        :
        end if;
      end if;
    end process;

Der global_clk wird im Prozess gar nicht verwendet, dafür fehlen 
counter und stopper. Dieser Prozess wird in der Simulation aussehen 
wie wenn er getaktet wäre, weil er ja mit einer Änderung von 
global_clk neu berechnet wird. Dieses Verhalten ist aber falsch.

[Klaus Falser (Gast)]

Handelt es sich bei Dir um ein Problem mit der Simulation oder mit der 
Hardwae?
Mich wundert es nämlich, ob das folgende wirklich synthetisierbar ist:

    process(global_clk, reset) --, start_signal, reset)
    begin
      if reset = '0' then
        counter<=0;
      elsif start_signal='0' then
        counter<=1999;
      elsif start_signal='1' then
        if counter=0 then
          counter<=1999;
        elsif rising_edge(global_clk) and counter>0 then
          counter<=counter-1;  
        end if;
      end if;
    end process;

Normalerweise sollte das so aussehen :

    process(clk, reset)
    begin
      if reset = '0' then
        counter<=0;
      elsif rising_edge(global_clk) then
        if start_signal='0' then
           counter<=1999;
        elsif counter > 0 then  
          counter<=counter-1;
        else 
           counter<=1999;
        end if;  
      end if;
    end process;

Ich würde Dir stark empfehlen, den Reset-Zweig zu überarbeiten, sodass 
das
das ganze Rücksetzen des Zählers synchron zum Takt arbeitet.

[Flachmann (Gast)]

Klaus Falser schrieb:
> Normalerweise sollte das so aussehen :    process(clk, reset)
>     begin
>       if reset = '0' then
>         counter<=0;
>       elsif rising_edge(global_clk) then
>         if start_signal='0' then
>            counter<=1999;
>         elsif counter > 0 then
>           counter<=counter-1;
>         else
>            counter<=1999;
>         end if;
>       end if;
>     end process;

so sah es anfangs aus. da es nicht funktioniert hat habe ich es halt 
umgeschrieben.

vielen dank für die antworten. wo die möglichkeit bestand habe ich die 
tipps umgesetzt bzw teile neugeschrieben.

aber es ist immernoch so, dass richtig gezählt wird wenn ich die werte 
nicht abgreife. implementiere ich nur das erste event, dann funktioniert 
es noch.
aber sobald alle laufen herrscht wieder großes chaos.

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

Wieviele Takte hast du?
Mehr als 1?

[Flachmann (Gast)]

es gibt 2 takte. der eine hat 100MHz , global_clk und ist nur zur 
pulserzeugung da. das muss halt auf 10 ns genau sein.
der takt wird auf 1MHz runtergetaktet. dieser takt ist nur für die 
datenverarbeitung zuständig.
aus dem "datensegment" kommt dann auch der kurze startpuls, der 
umgeformt wird in ein sagen wir start_enable. die counter laufen während 
dieser high ist. wenn die n_samples abgelaufen sind muss das enable 
zurück gesetzt werden.

jetzt habe ich gerade einw enig ausprobiert und mir ist aufgefallen, 
dass ich den counter mit maximal 2 abfragen belasten darf. durch 
schreiben des counterwertes in ein latch kann ich dann auch 3 abfragen 
erreichen.
dummerweise komme ich nicht unter den angegebenen 6 davon.

sobald ich auf 4 abfragen gehe ist irgendetwas nicht mehr koscher.

[Klaus F. (kfalser)]

Flachmann schrieb:
> jetzt habe ich gerade einw enig ausprobiert und mir ist aufgefallen,
> dass ich den counter mit maximal 2 abfragen belasten darf. durch
> schreiben des counterwertes in ein latch kann ich dann auch 3 abfragen
> erreichen.
> dummerweise komme ich nicht unter den angegebenen 6 davon.

Jetzt erzähle uns doch bitte einmal wie Du darauf kommst:
- Simulation oder Hardware, aber diese VHDL Files sollte man so 
eigentlich nicht ohne Warnungen oder Fehler durch die Synthese bekommen.
- Welcher Simulator
- Welche Hardware

Gerade beim Simulieren kann man viele Sachen sehen, dann schaut man sich 
den Zeitpunkt an bis wohin es stimmt und dann versucht man zu verstehen 
was an dieser Stelle falsch läuft.

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

> es gibt 2 takte.
D.h. die ganzen andern abfragen auf rising_edge sind jetzt raus? 
Alles, was mit rising_egde oder falling_edge oder 'event abgefragt wird, 
ist ein Takt.

> der eine hat 100MHz , global_clk und ist nur zur
> pulserzeugung da. das muss halt auf 10 ns genau sein.
> der takt wird auf 1MHz runtergetaktet.
Dann ändere dein Design so, dass aus dem 1 MHz Takt ein 1 MHz 
Clock-Enable wird. Erst dann ist das Design richtig synchron und 
handhabbar.

> jetzt habe ich gerade einw enig ausprobiert und mir ist aufgefallen,
> dass ich den counter mit maximal 2 abfragen belasten darf.
Innerhalb des FPGAs ist der Fan-Out wesentlich höher (min. 50) und falls 
nötig werden von der Toolchain die Signale einfach dupliziert. Mit 
asynchronen Abfragen auf den Counter und daraus resultierenden Resets 
wirst du aber garantiert Probleme mit Glitches bekommen...
Und genauso sieht deine Fehlerbeschreibung aus  :-o

[Flachmann (Gast)]

Die Simulation funktioniert ja einwandfrei.
Ich benutze ModelSim 6.4b.
Das ganze läuft auf einem XC2C512-PQ208.

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

> Die Simulation funktioniert ja einwandfrei.
Mit dem obigen Code? Dann wundert mich nichts, denn die Simulation ist 
falsch. Siehe meine Anmerkungen oben:
>>> Dieser Prozess wird in der Simulation aussehen wie wenn er getaktet wäre
 :-o

[Flachmann (Gast)]

Lothar Miller schrieb:
> Mit
> asynchronen Abfragen auf den Counter und daraus resultierenden Resets
> wirst du aber garantiert Probleme mit Glitches bekommen...

Der vorzufindende reset wird extern von einem µC erzeugt. Er dient nur 
dazu das Ganze hart zu reseten. aus den abfragen heraus werden keine 
resets generiert. wenn doch, dann erklär mit bitte wie das passiert.

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

> wenn doch, dann erklär mit bitte wie das passiert.
Das ist ein asynchroner kombinatorischer Reset:

      if reset = '0' then
        counter<=0;
      elsif start_signal='0' then
        counter<=1999;
      elsif start_signal='1' then
        if counter=0 then
          counter<=1999;
        elsif rising_edge(global_clk) and counter>0 then
          counter<=counter-1;  
        end if;
      end if;

Bestehend aus dem counter und dem startsignal.

Der Knackpunkt in der Hardware ist aber hier:

        if counter=0 then
          counter<=1999;
        elsif rising_edge(global_clk) and counter>0 then
          counter<=counter-1;  
        end if;

Denn wenn der Counter z.B. von binär 0001111 nach 0010000 zählt und nur 
kurz einen Glitch mit 00000000 erzeugt, was passiert dann? Ratzdifatz: 
der Counter ist für ein paar ps lang 0 und er wird auf 1999 gesetzt 
(oder wenigstens ein paar FFs des Counters.

[Flachmann (Gast)]

ja das seh ich auch ein. aber warum treten dann die glitches nur auf 
wenn ich die abfragen für die anderen signale ala if counter<1600 
then...
auf den counter lege? bei bis zu 2 abfragen scheinen ja keine glitches 
aufzutreten. warum aber bei mehreren abfragen?

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

> warum aber bei mehreren abfragen?
Weil dann die Signale intern anders oder mehr belastet werden. Das Ganze 
ist z.B. auch temperaturabhängig und spannungsabhängig. Kurz: unsauber.

Es könnte schon reichen, dass du irgendwas änderst und deshalb das 
Design ein klein wenig anders platziert und gerouted wird und dann nicht 
mehr zuverlässig läuft. Und voila: du suchst den Fehler an der falschen 
Stelle, weil du meinst "vor der letzten Änderung ist es noch 
gegangen...".

[Flachmann (Gast)]

ah ja gut. ich dachte nicht, dass die belastung direkt mit den races zu 
tun hat und auch nich, dass die races an besagten stellen auftreten. ich 
hoffe das löst das problem. dankeschön!

[Flachmann (Gast)]

so,das problem ist immernoch das gleiche. der code sieht mittlerweile 
folgendermaßen aus. jemand eine idee?

  --start/stop pulsing      
    -- convert start signal
    process(reset, global_clk)-- help_2,stop)
    begin
      if reset='0' then
        start_signal<='0';
      elsif rising_edge(global_clk) then
        if start_signal = '0' and start='1' then
          start_signal<='1';
        elsif stop_event='1' then
          start_signal<='0';  
        end if;
      end if;
    end process;
    
    --generate stop_signal
    process(reset, global_clk)
    begin
      if reset='0' then
        stop_event<='0';
      elsif rising_edge(global_clk) then
        if stopper >= set_n_samples then
          stop_event<='1';
        else
          stop_event<='0';
        end if;
      end if;
    end process;
    
    ---- count_clks ----
    process(global_clk, reset)
    begin
      if reset='0' then
        counter <= 1999;
      elsif rising_edge(global_clk) then
        if start_signal='0' then
          counter<=1999;
        elsif start_signal = '1' then
          if counter = 0 then
            counter <= 1999;
          elsif counter>0 then
            counter <= counter-1;
          end if;
        end if;
      end if;  
    end process;
    
    ---- samples counter ----
    process(global_clk, reset)
    begin
      if reset = '0' then
        stopper<=0;
      elsif rising_edge(global_clk) then
        if start_signal = '0' then
          stopper<=0;
        elsif counter = 0 then
          stopper<=stopper+1;
        end if;
      end if;
    end process;
    
    -- generate pulses
    -- events
    process(global_clk, reset)
    begin
      if reset='0' then
        event_1<='0';
        event_2<='0';
        event_3<='0';
        event_4<='0';
        event_5<='0';
        event_6<='0';
      elsif rising_edge(global_clk) then
        if counter < 1600 then
          event_1<='1';
        else
          event_1<='0';
        end if;
        if counter < (1600 - set_pw) then
          event_2<='1';
        else
          event_2<='0';
        end if;
--        if counter < (1600 - set_delay) then
--          event_3<='1';
--        else
--          event_3<='0';
--        end if;
--        if counter_2 < (1600 - set_pw  - set_delay) then
--          event_4<='1';
--        else
--          event_4<='0';
--        end if;
--        if event_gen <(1000 + (set_pw/2)) then
--          event_5<='1';
--        else
--          event_5<='0';
--        end if;
--        if event_gen <(1000 - (set_pw/2)) then
--          event_6<='1';
--        else
--          event_6<='0';
--        end if;
      end if;
    end process;
    
    --convert events to pulses
    process(global_clk, reset, start_signal)
    begin
      if reset='0' or start_signal='0' then
        TX_22<='0';
        TX_35<='0';
        TX_TR_22<='0';
        TX_TR_35<='0';
        LO_22<='0';
        LO_35<='0';
        RX_TR_22<='0';
        RX_TR_35<='0';
        ADC_Trigger<='1';      
      elsif(rising_edge(global_clk)) then
        case set_mode is
          when "001" => -- copolar
            TX_22<=event_1 and not(event_2);
            TX_35<=event_1 and not(event_2);
            TX_TR_22<=event_1 and not(event_2);
            TX_TR_35<=event_1 and not(event_2);
          
            LO_22<=event_3 and not(event_4);
            LO_35<=event_3 and not(event_4);
            RX_TR_22<=event_3 and not(event_4);
            RX_TR_35<=event_3 and not(event_4);
            ADC_Trigger<=not(event_3 and not(event_4));
                
          when "010" => -- crosspolar
            TX_22<=event_1 and not(event_2);
            TX_35<=event_1 and not(event_2);
            TX_TR_22<=event_1 and not(event_2);
            TX_TR_35<=event_1 and not(event_2);
          
            LO_22<=event_3 and not(event_4);
            LO_35<=event_3 and not(event_4);
            RX_TR_22<=event_3 and not(event_4);
            RX_TR_35<=event_3 and not(event_4);
            ADC_Trigger<=not(event_3 and not(event_4));
        
          when "011" => -- calibrate
            TX_22<=event_1 and not(event_2);
            TX_35<=event_1 and not(event_2);
            LO_22<=event_1 and not(event_2);
            LO_35<=event_1 and not(event_2);
            ADC_Trigger<=not(event_1 and not(event_2));
        
          when "100" => -- radiometer
            LO_22<=event_5 and not(event_6);
            LO_35<=event_5 and not(event_6);
            RX_TR_22<=event_5 and not(event_6);
            RX_TR_35<=event_5 and not(event_6);
            ADC_Trigger<=not(event_5 and not(event_6));
          
          when others =>
          
        end case;
      end if;
    end process;
  
    -- set hv switch
    process(reset, global_clk, start_signal, modulator, event_2)
    begin
      if reset='0' or start_signal='0' then
        POL_22<='0';
        POL_35<='0';
      elsif rising_edge(global_clk) then
        case set_mode is
          when "001" => -- copolar
            if modulator = '1' then
              POL_22<='1';
              POL_35<='1';
            else
              POL_22<='0';
              POL_35<='0';
            end if;
                          
          when "010" => -- crosspolar
            if (event_2='1' and modulator='1') or (event_2='0' and modulator='0') then
              POL_22<='1';
              POL_35<='1';
            else
              POL_22<='0';
              POL_35<='0';
            end if;
          
          when "011" => -- calibrate
            POL_22<='0';
            POL_35<='0';
          
          when "100" => -- radiometer
            if modulator = '1' then
              POL_22<='1';
              POL_35<='1';
            else
              POL_22<='0';
              POL_35<='0';
            end if;
          
          when others =>
      
        end case;
      end if;        
    end process;
  
    process(global_clk)
    begin
      if rising_edge(global_clk) then
        if stopper mod 2 = 1 then
          modulator <= '1';
        else
          modulator <= '0';
        end if;
      end if;
    end process;

[Duke Scarring (Gast)]

Flachmann schrieb:
> jemand eine idee?

Hast Du auch eine Testbench dazu?

Duke

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

Hmhmmmm:
      if reset='0' or start_signal='0' then

Aber weil start_signal synchron gesetzt wird, können schon mal keine 
Glitches mehr auftreten. Spannend könnte es allerdings werden, wenn 
start_signal auf '1' geht, dann wird ziemlich zeitgleich mit dem Takt 
der Reset weggenommen...

Was sagt denn die Synthese zum Thema "Maximalfrequenz des Designs"?

[Flachmann (Gast)]

das dürfte doch egal sein. es passiert ja kein reset während 
start_signal auf 1 geht. zur maximalen freuenz hab ich in xilinx' ise 
jetzt leider ncihts gefunden. wo sollte das denn stehen? im 
synthetisierungsbericht stand nix drin..

[Björn C. (bjoernc)]

im summary sollte es stehen, zumindest aber in der Konsole der ISE (das 
fenster ganz unten)

[Klaus F. (kfalser)]

Flachmann schrieb:
> das dürfte doch egal sein. es passiert ja kein reset während
> start_signal auf 1 geht.

Doch, start_signal = 0 steht im Reset-Pfad der FFs, die davon 
betroffenen FFs werden asynchron mit start_signal = 0 zurückgesetzt.
Erst wenn start_signal auf '1' geht, werden die FF's für den Takt 
global_clk freigegeben.

[Flachmann (Gast)]

aber die flipflops die durch start_signal gesteuert werden haben 
keinerlei rückwirkung auf die ganze zähleinheit. welche auswirkung kann 
das darauf haben, dass das signal stop_signal nicht mehr auf 1 gesetzt 
wird, weil die anzahl samples nicht mehr erreicht wird?

[SuperWilly (Gast)]

Das wäre die bessere Variante:

if reset='0' then                      -- asynchroner reset
        
elsif rising_edge(global_clk) then

     if start_signal = '0' then        -- synchroner reset

     else

     end if;
end if;

Gruß,
SuperWilly

[Michael S. (Firma: www.das-labor.org) (laborsauron)]

Hast du denn überhaupt deinen 100 Mhz Takt mit einer Period Constraint 
definiert. ?

Wenn ISE nicht weiss, wie schnell der Takt ist, dann gibt sich die 
Toolchain auch keine mühe beim Placen.

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

> Das wäre die bessere Variante:
Am besten wäre es, auf einen generellen (insbesondere asnychronen) Reset 
komplett zu verzichten. Dazu die Whitepapers WP272 und WP272 von Xilinx 
und hier im Beitrag "Theoriefrage asynchroner Reset"