Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
16 years ago

it's weird that my state machine got into a wrong state

I'm writing some verilog code to communicate with my usb controller, the simulation result is good , but it seems that my fpga hangs after running 1~2 houres. At last I display the state on LEDs, to my astonishment, when fpga hangs the leds output is not defined(no led flashes).

I'm using Quartus 9.0 for Linux, Terasic DE0 board (cyclon III EP3C16F484C6N )

Can someone give me some hints? Thanks!

My code are as follows:

localparam IDEL = 8'b00000001,

STATE1 = 8'b00000010,

STATE2 = 8'b00000100,

STATE3 = 8'b00001000,

STATE4 = 8'b00010000,

STOPTX = 8'b00100000,

STOPTX2= 8'b01000000;

always @(posedge clk or negedge reset_n)

begin

if(!reset_n)

begin

state_next<=IDEL;

...

end

else

begin

case(state_next)

idel:

begin

if(!fifo_empty)

state_next<=STATE1;

pktend_next<=1'b1;

end

state1:

begin

fifo_addr_reg<=2'b10;

state_next<=STATE2;

end

state2:

begin

if(full!=1'b0) //usb buffer not full

begin

if(!fifo_empty)//output fifo is not empty

begin

slwr_next<=1'b0;

data_next<=_fifo_[rdptr];

last_out<=_fifo_[rdptr];

state_next<=STATE3;

end

else

state_next<=IDEL;

end

else

state_next<=IDEL;

end

state3:

begin

usb_count<=usb_count+1;

slwr_next<=1'b1;//write into usb

state_next<=STATE4;

rdptr<=(rdptr+1)%FIFO_LEN;

end

state4:

begin

if(!fifo_empty)

begin

state_next<=STATE2;

end

else

state_next<=IDEL;

end

stoptx:

begin

pktend_next<=1'b0;

state_next<=STOPTX2;

end

stoptx2:

begin

pktend_next<=1'b1;

state_next<=IDEL;

end

default:

state_next<=idel;

endcase

end

end

1 Reply

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    The relation of LED outputs and states of your state machine isn't shown in your post, but I simply assume, that the state machine is caught in an illegal state. If you read the Quartus Software Handbook chapter about state machines thorougly, you'll notice, that

    default: state_next<=idel; doesn't work for illegal states. You have define safe state machine encoding to handle illegal states, e.g. by a synthesis attribute. 

    reg  state_next /* synthesis syn_encoding = "safe" */

    Generally, there are two possibly reasons, why a state machine can reach an illegal state (= an undefined bit coding of the state variable):

    1. The input clock has glitches or temporary short periods, that cause a timing violation in the state machine logic

    2. An input signal to the state machine is changing unrelated to the state machine clock and cause a timing violation. All unrelated input signals must be synchronized before being processed in the state machine.

    To understand, why unrelated input signals can cause illegal states, you should consider, that the input signal is fed through combinational logic to the state variable registers, but each bit of the state machine is treated individually. Due to a setup or hold time violation, individual bits can react inconsistently on the event (one bit "sees" the event, the other doesn't).