Forum Discussion

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

A problem of FSM

The verilog code below is a FSM I designed . I find this FSM can run correctly and jump between different states at first ,

but after running several seconds it will fall into a fixed state(state=0, state2=0 or state=7,state2=4) and never come out again.

According to the logic , the FSM can step into state 0 only once after power on reset; moreover ,any time when falling into state 0,it

should can come out and step into state 1. But the reality is that it never come out again.

Is there any problem with this FSM code ? How to deal with this problem?

Thanks!

code:

reg [2:0] state;

reg [2:0] state2;

reg [9:0] count;

always @(posedge CLK)

begin

if(RESET)//power on reset

begin

state <= 0;

state2 <= 0;

count <= 0;

end

else

begin

case (state)

0:

begin

case (state2)

0:

begin

if (count == 0)

begin

//process

count <= count + 1;

end

else if (count < 2)

begin

//process

count <= count + 1;

end

else

begin

count <= 0;

state2 <= 1;

end

[/INDENT]end

1:

begin

if (count == 0)

begin

//process

count <= count + 1;

end

else if (count < 6)

begin

//process

count <= count + 1;

end

else

begin

count <= 0;

state2 <= 2;

end

[/INDENT]end

2:

begin

if (count == 0)

begin

//process

count <= count + 1;

end

else if (count < 6)

begin

//process

count <= count + 1;

end

else

begin

count <= 0;

state2 <= 3;

end

[/INDENT]end

3:

begin

if (count == 0)

begin

//process

count <= count + 1;

end

if (count == 1)

begin

//process

count <= 0;

state2 <= 0;

state <= 1;

end

[/INDENT]end

endcase

[/INDENT][/INDENT]end

1:

begin

//process

state <= 2;

end

2:

begin

//process

state <= 3;

end

3:

begin

//process

state <= 4;

end

4:

begin

//process

state <= 5;

end

5:

begin

//process

state <= 6;

end

6:

begin

//process

state <= 1;

end

default:

begin

state <= 1;

end

endcase

[/INDENT]end

[/INDENT]end

7 Replies

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

    According to your code, there is no state 7. That would therefore be impossible. Also there is no state2 == 4. Also impossible. The only way this can be happening is if there is some input to the system not illustrated in the code that affects the state machine. That input may be an upset caused by the fact that you're not meeting timing. Are you meeting timing requirements?

    Also, are you sure you are getting a clean reset?

    May I suggest the following: 

    reg  state;
reg  state2;
reg  count;
always @(posedge CLK or posedge RESET) begin
    if(RESET) begin //power on reset
                    state <= 0;
                    state2 <= 0;
                    count <= 0;
    end else begin
        case (state)
        0:
            case (state2)
            0: begin
                    count   <= count + 1;
                if(count == 2) begin
                    state2  <= 1;
                    count   <= 0'
                end
            end
            1: begin
                    count   <= count + 1;
                if(count == 6) begin
                    state2  <= 2;
                    count   <= 0'
                end
            end
            2: begin
                    count   <= count + 1;
                if(count == 6) begin
                    state2  <= 3;
                    count   <= 0'
                end
            end
            3: begin
                    count   <= count + 1;
                if(count) begin
                    state   <= 1;
                    state2  <= 0;
                    count   <= 0;
                end
            end
            endcase
        1:          state <= 2;
        2:          state <= 3;
        3:          state <= 4;
        4:          state <= 5;
        5:          state <= 6;
        6:          state <= 1;
        default:    state <= 0;
        endcase
    end
end
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Thank you very much for your suggestions!

    Following facts may give you more information about this problem:

    1.The compilation report shows the timing is meeted.

    2.The "RESET" sigal is generated from following module:

    module SELF_RESET(// power on reset

    input CLK10,

    output reg SELF_RESET

    );

    reg [3:0] count;

    always @(posedge CLK10)

    begin

    if(count != 10)

    begin

    count <= count + 1;

    SELF_RESET <= 1'b1;

    end

    else

    SELF_RESET <= 1'b0;

    [/INDENT]end

    [/INDENT]

    endmodule

    The CLK10 is 10MHz.The CLK in FSM is a 90MHz clock generated from a PLL in the FPGA with the input of 15MHz . Both the 10MHz and 15MHz are inputs of FPGA and these two clocks are in different clock domain.

    3. Whatever signal cause the FSM jump into a state which is not exist or unwanted , the FSM should can jump out of this state according to the logic.

    For example, when the state is changed to 7, FSM should jump into the default state and then jump into state 1. When the state is changed to 0, it also can come out of state o and jump into state 1. But the fact is once the FSM fall into state 7 or state 0 after running correctly for several seconds, it

    will never come out again.

    Is my understanding about this FSM correct?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Hi tigre,

    1) It is good design practice to always provide an external reset signal to your system. This is definitly required when you are targeting an ASIC design.

    2) On an FPGA where the registers are initialized to a known state after configuration, you can of course provide a "Power Up" reset signal as you are doing.

    3) Your design is working in two different clock domains, that are unrelated. You have one external clock of 10MHz and a second unrelated clock of 90MHz generated by a PLL from a separte 15MHz signal.

    When you are resting your circuit operating at 90MHz by a reset signal that is generated from an unrelated 10MHz clock, there is no direct correlation between the arrival of the RESET signal and the 90MHz CLK clock signal. This means that your RESET signal will be "racing" with the CLK signal to arrive first at the specific registers in your design. Depending on the specific wiring configuration obtained during the Fitting of your design, it can occur that some registers get reset and other do not. So the behavior that you describe is to be expected.

    Operating among clock domains is not trivial and you can always suffer from metastability.

    You can at least improve the behavior of your FSM by "synchronizing" your RESET signal via a number of registers in a chain. This could for example be done as follows for your design: 

    reg RESET, RESET1;
wire RESET2;
always @(posedge CLK) begin
  RESET = RESET1;
  RESET1 = RESET2;
end 
SELF_RESET u1 (clock, RESET2);
    This adds two intermediate signals RESET1 and RESET2. In each flipflop the RESET signal will be "synchronized" better to the 90MHz CLK signal. The problems with metastability will be lower at least.

    Hope this helps...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    I don't see a reason for the reported behaviour in the posted code. Because no asynchronous events are processed in the FSM (which is the most likely cause for FSM erratic behaviour), PLL loss of lock should be considered.

    Although a reliable design operation can't be expected with an unstable clock, you can prevent FSM lockup in illegal states by specifying safe FSM in general synthesis options or synthesis attributes. To make safe FSM coding effective, both state machines should have default states.

    This is the respective Verilog syntax for specifying safe state machine synthesis 

    reg  state /* synthesis syn_encoding = "safe" */;
reg  state2 /* synthesis syn_encoding = "safe" */;
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    @FvM

    The code for the FSM (with the addition of the "default:" in all case statements) as suggested by jacobjones should work.

    Once started up the FSM from the "SELF_RESET" the FSM should operate without the problems mentioned by tigre.

    @tigre

    Is the behavior (after several seconds) that you describe occuring with the "SELF_RESET" that you posted before?

    1) If YES. Why do you generated the "SELF_RESET" from a 10MHz clock unrelated to the 90MHz CLK?

    2) If NO. I suppose that you are generating a RESET at several instances from an external signal in the 10MHz clock domain. If this is the case, your design can be influenced by races. (for a solution see my previous post).
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    --- Quote Start ---

    The code for the FSM (with the addition of the "default:" in all case statements) as suggested by jacobjones should work.

    --- Quote End ---

    As far as I see, no default state is yet implemented for state2. Generally, without forcing safe state machine synthesis, you shouldn't make assumptions about behaviour in illegal states. Also, as long as you don't specify an explicite FSM processing, one state hot is the default coding style for any state machine recognized by the compiler. This implies additional possible illegal states outside the expected binary state variable number range. Safe state machine or explicite state encoding is the only way to avoid this issue.

    Furthermore, I realized that the FSM code in the original post isn't representing a full design, because it hasn't any output. Thus I wonder, if any details of the real design, omitted in the post, may cause the discussed problem. To be sure about, I would like to see a full design that still reproduces the issue.

    P.S.: Regarding the RESET discussion, I agree that driving the SELF_RESET logic from a different clock basically causes an asynchronous reset, that may cause a FSM to change to an illegal state at worst case. Thus the reset should be better synchronized to the FSM CLK by usual means. But this issue can't explain a FSM failure after correct initial startup.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    @sanmao

    1)There is only one SELF_RESET instance in my project. The 10MHz clock is the main clock in the project and

    the 90MHz clock is only used in one module.

    2)I will rewrite the SELF_RESET code as you suggested.

    @FvM

    1) I have check the pll "locked" signal after the FSM problem appears, it is in high level . So ,the 90MHz

    clock is stable.

    2)/*synthesis syn_encoding = "safe"*/ added behind "state" definition can work in Quartus2? Does it have the same effect as "default" item in case statement?