Verstehe Verhalten eines Zählers im FPGA nicht

[A.G. (Gast)]

Hallo,

mein Zähler, ein 8bit großes Register namens "write_counter" verhält 
sich total seltsam, ich kann das einfach nicht nachvollziehen.

reg [7:0] write_counter;


always@ (posedge clk)
begin


  if(SW[0])
  begin
  
  case(write_counter)
      
      0:  begin
            sdram_res <= 1'b1;
            write_counter <= write_counter + 8'd1;
          end
          
     100: begin
            sdram_res <= 1'b0;
            sdram_length <= 8'd1;
            write_counter <= write_counter + 8'd1;
          end
          
     105: begin
            sdram_res <= 1'b1;
            write_counter <= write_counter + 8'd1;
          end
          
     120: begin
            sdram_wr <= 1'b1;
            write_counter <= write_counter + 8'd1;
          end
          
     128: begin
            write_counter <= write_counter + 8'd1;
          end
          
     129: begin
            if(sdram_done)
            begin
            sdram_wr <= 1'b0;
              write_counter <= 8'd110;
              sdram_address <= sdram_address + 23'd1;
            end
          end
          
     default:  
            write_counter <= write_counter + 8'd1;
  endcase
  
  end
  

end

[A.G. (Gast)]

Ups, bin aus Versehen schon auf "Absenden" gekommen.
Anbei noch ein SignalTap-Trace, den ich erstellt habe.

Das Problem ist, dass der Counter plötzlich von 111 auf 116 springt, 
obwohl noch einige Schritte dazwischen kämen.


Der Code von oben ist alt, wollte eigentlich den posten:

// Controls the SDRAM and writes data from fat32 module
always@ (posedge sdram_clk)
begin

  case(write_counter)
      
      0:  begin
            topsdram_res <= 1'b1;
            sdram_wr <= 1'b0;
            topsdram_address <= 31'd0;
            topsdram_length <= 8'd1;
            write_counter <= 8'd1;
          end
          
     100:  begin
            topsdram_res <= 1'b0;
            write_counter <= write_counter + 1'b1;
           end
          
     110:  begin
            topsdram_res <= 1'b1;
            step <= 1'b1;
            write_counter <= write_counter + 1'b1;
           end
          
     111:  begin
            step <= 1'b1;
            if(o_val)
            begin
              sdram_datain[15:8] <= data;
              write_counter <= write_counter + 1'b1;
            end
           end
          
     112:  begin
            step <= 1'b1;
            if(!o_val)
              write_counter <= write_counter + 1'b1;
           end
          
     114:  begin
            if(o_val)
            begin
              sdram_datain[7:0] <= data;
              //topsdram_res <= 1'b1;
              sdram_wr <= 1'b1;
              step <= 1'b0;
              write_counter <= write_counter + 1'b1;
            end
           end
          
          
     115:  begin
            step <= 1'b0;
            
            if(sdram_done)
            begin
              sdram_wr <= 1'b0;
              topsdram_address <= topsdram_address + 31'd2;
              write_counter <= 8'd2;
            end
            
            if(!o_val)
              write_counter <= write_counter + 1'b1;
          end
          
          
     116:  begin
            
            if(sdram_done)
            begin
              //if(done)
              //  write_counter <= write_counter + 1'b1;
              //else
              //begin
                //topsdram_res <= 1'b0;
                sdram_wr <= 1'b0;
                topsdram_address <= topsdram_address + 31'd1;
                write_counter <= 8'd110;
              //end
            end
            
           end
          
          
          
     default:  
         write_counter <= write_counter + 1'b1;
  endcase
  
end

[bko (Gast)]

Wo findet man die Zeitskala auf dem "SignalTap-Trace"?
oder wie lang ist "der Counter  111" auf dem Bild?

[Georg A. (georga)]

Bin jetzt nicht so fit in Verilog (br, schaut das Gestottere greislig 
aus), aber entweder hat der Simulator einen Bug oder du hast nicht den 
vollständigen Code gepostet.

[Lattice User (Gast)]

Zur Info:
SignalTap == ChipsScope == Reveal  (Altera,Xilinx,Lattice)

Da sind entweder asynchrone Signal im Design oder Timing wurde nicht 
erfüllt.

[A.G. (Gast)]

bko schrieb:
> Wo findet man die Zeitskala auf dem "SignalTap-Trace"?
> oder wie lang ist "der Counter  111" auf dem Bild?

Entschuldige, ich hatte keine Zeitskala eingefügt und deswegen beim 
Bearbeiten der Grafik einfach abgeschnitten.
Der Counter ist 5 Takte einer 50MHz clock lang im Zustand 8'd111.


Georg A. schrieb:
> Bin jetzt nicht so fit in Verilog (br, schaut das Gestottere greislig
> aus), aber entweder hat der Simulator einen Bug oder du hast nicht den
> vollständigen Code gepostet.

Der vollständige Code wäre zu lang. Aber was den counter betrifft, so 
wird er nur innerhalb dieses Codes verändert.


Lattice User schrieb:
> Zur Info:
> SignalTap == ChipsScope == Reveal  (Altera,Xilinx,Lattice)
> Da sind entweder asynchrone Signal im Design oder Timing wurde nicht
> erfüllt.

Welche Signale meinst denn genau bei diesem Code, sodass dieser Fehler 
auftritt?


Übrigens scheint es nicht nur ein paar Schritte zu überspringen. 
Manchmal, setzt es gar nicht die Signale, wie es im Code steht!
Beispiel: Im Code oben steht beim Schritt 114, dass ein Register high 
werden soll (sdram_wr <= 1'b1;), jedoch scheint es manchmal zufällig das 
einfach zu "vergessen". Es befindet sich zwar mehrere Takte lang im 
State 114, aber sdram_wr wird nicht high!

[bko (Gast)]

Nun aber ohne mehr Information wird das nichts, denn am gezeigten Code 
liegts eigentlich nicht.
Wo kommen z.B.  >sdram_done< und >o_val< denn her und
sind das syncrone Signale (also syncron zu sdram_clk)?
Und was sagt die Simulation?

[A.G. (Gast)]

bko schrieb:
> Nun aber ohne mehr Information wird das nichts, denn am gezeigten Code
> liegts eigentlich nicht.
> Wo kommen z.B.  >sdram_done< und >o_val< denn her und
> sind das syncrone Signale (also syncron zu sdram_clk)?
> Und was sagt die Simulation?

Die Signale waren tatsächlich asynchron, Fehler gefunden!
Aber ich hätte nicht gedacht, dass das solche Auswirkungen hat. Das kann 
ich mir eigentlich auch nicht erklären, schließlich sind die Signale 
o_val und sdram_done viel länger high, als ein clock-cycle.
Definitiv keine stablile Logik, das hätte ich selber erkennen sollen.
Ich danke euch für eure Hilfe und Gelduld!

[Johannes E. (cpt_nemo)]

A.G. schrieb:
> Das kann
> ich mir eigentlich auch nicht erklären, schließlich sind die Signale
> o_val und sdram_done viel länger high, als ein clock-cycle.

Es ist nicht wichtig, wie lange die "high" sind, sondern zu welchem 
Zeitpunkt die Signale ihren Pegel ändern.

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

Zum Hintergrund des Problems:
http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html
Ein Zähler ist die einfachste Form einer FSM...