About styles of writing FSM

Question

Hi,  I find many people on their blog suggest coding FSM as follow. 
always @ (posedge clk or negedge rst_n)
if(!rst_n)
    current_state &lt;= IDLE;
else
    current_state &lt;= next_state;
 
always @ (*)    
   begin
     next_state = x;   
     case(current_state)
     S1: if(...)
        next_state = S2;   
     ...
     endcase
end
always @ (posedge clk or negedge rst_n)
case(next_state)
S1:if(...)
    out1 &lt;= 1'b1;
   else
    out1 &lt;= 1'b0;
default:...    
endcase
end
  Here is my style. 
always @ (posedge clk or negedge rst_n)
if(!rst_n)
    current_state &lt;= IDLE;
else 
    case(current_state)
     S1: if(...)
        current_state &lt;= S2;   
     ...
     endcase
 
always @ (posedge clk or negedge rst_n)
case(current_state)
S1:if(...)
    out1 &lt;= 1'b1;
   else
    out1 &lt;= 1'b0;
default:...    
endcase
end
   My problem is that I cannot tell the advantages and disadvantages between them.   Thank you in advance.

altera_forum · Answer

According to Cliff from Sunburst:  6.  one always block fsm style (avoid this style!) one of the most common fsm coding styles in use today is the one sequential always block fsm coding style. this coding style is very similar to coding styles that were popularized by pld programming languages of the mid-1980s, such as abel. for most fsm designs, the one always block fsm coding style is more verbose, more confusing and more error prone than a comparable two always block coding style.  Reference :http://www.sunburst-design.com/papers/cummingsicu2002_fsmfundamentals.pdf  At then end of the day, it is still depending on your personal preference.

altera_forum · Answer

This is down to personal preference. It's highly unlikely that the final implementation will differ as a result of using the different styles. You might argue that a more verbose coding style is more explicit and therefore helps the tools digest your code - there may be some particular inferences that cause the tools difficulty. I don't personally subscribe to this point of view. More relevant (I think) is the comment made regarding a more verbose style - it's more prone to error.

So, in short the "advantages and disadvantages between them" are down to your own subjective take on the two styles. I suggest you use the one that comes more naturally to you.

Cheers,

Alex

altera_forum · Answer

--- Quote Start ---

This is down to personal preference. It's highly unlikely that the final implementation will differ as a result of using the different styles. You might argue that a more verbose coding style is more explicit and therefore helps the tools digest your code - there may be some particular inferences that cause the tools difficulty. I don't personally subscribe to this point of view. More relevant (I think) is the comment made regarding a more verbose style - it's more prone to error.

--- Quote End ---

It is more a style comment. But while the 1 always style may be more prone to functional error, the 2 always style, with unregistered outputs, is prone to latches which wont be picked up in a functional simulation, and will only appear as synthesis warnings that many people ignore. This will then probably manifest as timing issues in the design which wont prove obvious to an inexperienced engineer.

stick to the 1 always style - then you know you're always getting registered output.

altera_forum · Answer

--- Quote Start ---  This is down to personal preference. It's highly unlikely that the final implementation will differ as a result of using the different styles. You might argue that a more verbose coding style is more explicit and therefore helps the tools digest your code - there may be some particular inferences that cause the tools difficulty. I don't personally subscribe to this point of view. More relevant (I think) is the comment made regarding a more verbose style - it's more prone to error.  So, in short the "advantages and disadvantages between them" are down to your own subjective take on the two styles. I suggest you use the one that comes more naturally to you.  Cheers, Alex  --- Quote End ---    As I concerned, I really agreed with you. In these two styles, we can put the state based signals in there own full case always@(posedge or negedge) block to make sure they are right registered. I think the differences between them is the way of designing the state machine. In the case of knowing where I am and the signals to step to next state, I prone to use the 2nd style because of the registered signal values should be changed to based on them right away. However, if I have make whole state machine designed,  I prone to use the 1st style, because  of the registered signal values should be changed to based on the state will changed to, next_state.  In a word, I consider the only significant difference between them is the red word in the follow code base on different styles of designing state machine(which may also leads to different styles of comments). 
always@(posedge clock)
case(state)
...:signal &lt;= ...;
default:...
endcase
always@(posedge clock)
case(next_state)
...:signal &lt;= ...;
default:...
endcase
  One more questions, advantages and disadvantages between code the state machine directly or indirectly. 
localparam IDLE 0;
case(state)
IDLE:...
...
endcase
case(state)
0:...
...
endcase

altera_forum · Answer

Altera recommends using localparams (or in system verilog use an enumerated type) because it makes the code easier to read. The synth tool can still extract the state machine from either style and will auto assign state values for you based on your synthesis settings (1 hot, grey code, counter)

Forum Discussion

About styles of writing FSM

7 Replies

Recent Discussions

Quartus messages web search goes to Intel

Is Quartus Prime Pro 22.4 Compatible with Stratix 10 NX Series Device 1SN21CEU2F55E2VG?

Unable to download Quartus

Installer cannot establish connection with SSL error

Duplicate_hierarchy_depth / duplicate_register