Difference between simulation and real test.

Altera_Forum · ‎06-19-2016

Hi all,

I am a student and I am working on a homework. Shortly, I will summary the hw's requirement. It said some thing like that: At first, when counter goes from 0->7 then led 1 on; when the counter up to 8 then led 2 on, up to 9 then led 3 on. Next, when the counter comes to 10, it depends on a switch, if switch is on, led 4 on, if switch is off led 5 on. And if led 4 on, it still to be on until counter comes to 14 then counter reset to 0 and comes back to first stage which means led 1 on. And similarly, if led 5 on, it still to be on until counter comes to 22 then counter reset to 0 and comes back to first stage which means led 1. The requirement is described by a lots of word but shortly it will be like that after I design FSM for the problem. When I finish my code, test bench runs OK but when I run on Altera DE1 board, it did not run like my expectation. When the counter comes to 8,9,10 it runs nicely but next when led 4 or led 5 on, it immediately comes back to stage 1 (led 1 on). Led 4 should be on for 4 seconds or led 5 should be on for 12 seconds before come back to stage 1. In test bench, it waiting but in the board nothing is waiting.

This is my code, hope you guys help me.

module controller(sw, clk, rst, led, y, Y); //This is top level module
 input sw, clk, rst;
 output  led;
 output reg y=0,Y=0; //y: present state; Y: next state
 parameter  fer=0, ready=1, prepare=2, transfer=3, flush=4; //define finite state machine
 reg  count=0; //counter
 
 frequency_divider C1(clk, clk_out); //divider frequency for DE1 board, I use pin L1 (50Mhz)
 
 
 
 always@(count, sw,y)
            case(y)
                        fer: if (count==8)
                                                            Y=ready;
                        ready: if (count==9)
                                                            Y=prepare;
                        prepare:  if ((count==10) & (sw==0)) 
                                                            Y=flush;
                                          else if ((count==10) & (sw==1))
                                                            Y=transfer;
                        transfer: if (count==14)
                                                            Y=fer;
                        flush: if ( count==22)
                                                            Y=fer;
                        default: Y=2'bxx;
            endcase
endcase
    
 always @(negedge rst, posedge clk_out)
        if (!rst) 
        y<=fer;
            else  
                y<=Y;
                
always @(negedge rst, posedge clk_out)
    if (!rst) 
        count = 0;
            else begin
                count = count + 1;
                if (y==transfer && count==15) //This to reset the counter
                    count=0;
                else if (y==flush && count==23)
                        count=0;
            end
            
 assign led=(y==fer); // led 0 on when the system in fermertation stage (stage 1) 
 assign led=(y==ready);
 assign led=(y==prepare);
 assign led=(y==transfer);
 assign led=(y==flush);
 
 endmodule
 
 module frequency_divider(clk_in, clk_out);
    
    input clk_in;
    output clk_out;
    reg  num=0;
    wire clk_out=num;
    always @(posedge clk_in) begin
        num <= num+ 1;
        end
endmodule
module test_controller; //test bench 
wire led;
reg sw, clk, rst;
controller C1(sw, clk, rst, led);
initial begin
sw=0;
clk=0;
rst=0;# 2rst=1;
end
always begin# 1 clk=~clk;
end
always begin# 100 sw=~sw;
end
endmodule

Altera_Forum · ‎06-19-2016

Not sure if it explains the issue, but why did you let the compiler assign default value for the y state machine ?

default: Y=2'bxx;

Altera_Forum · ‎06-22-2016

I (too) think you should be more explicit with your case statement's 'default'. Why not:default: Y=fer;

This line:if (y==transfer && count==15) //This to reset the counterstands out to me. 'y' is moved on to 'flush' when count = 14. So, I don't think this condition can ever be true.

On a more general note - use more descriptive signal/register names. I'd suggest 'y' and 'Y' are particularly poor. Use 'present_state' & 'next_state', as per your notes. Much clearer for anyone reviewing or you coming back to your code later.