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 <= IDLE;
else
current_state <= 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 <= 1'b1;
else
out1 <= 1'b0;
default:...
endcase
end
Here is my style.
always @ (posedge clk or negedge rst_n)
if(!rst_n)
current_state <= IDLE;
else
case(current_state)
S1: if(...)
current_state <= S2;
...
endcase
always @ (posedge clk or negedge rst_n)
case(current_state)
S1:if(...)
out1 <= 1'b1;
else
out1 <= 1'b0;
default:...
endcase
end
My problem is that I cannot tell the advantages and disadvantages between them. Thank you in advance.
連結已複製
7 回應
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.
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 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.
--- 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 <= ...;
default:...
endcase
always@(posedge clock)
case(next_state)
...:signal <= ...;
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 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)
--- Quote Start --- 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) --- Quote End --- Thank you for your advisement. What I wonder is if there are hundreds of states how I can define them quickly such as using system verilog enum. Do I have to type all the code as follow.
localparam IDLE 0;
localparam SYSEN 1;
...
...
...
localparam KILLSLEF 299;
If what I interested in is just give them each a meaningful name, is system verilog my better choice?
