--- 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
Honored Contributor
