RTL state machine design help

[analog_fever]

rtl state machine

Hi all, It has been more than 5yrs since I did RTL design/synthesis. So I am a little confused.

I am doing a state machine. I have an always block --

always@(posedge clk or negedge reset_l)
if(!reset_l)
state <= A;
......
else
state <= X;
....

end

I used non-blocking statements in the above block and I think this will be synthesized as as seq logic.

Now the problem is with the next always block ---

reg store_var;

always@* begin

case(state)

B: store_var = some_parameter;
C: If I do not drive store_var here, it is being reset to 0.
end

In this always block I define different signals, store values in latches based on the "state" in a case statement.

If I use non-blocking statements LEDA tool complains about using non-blocking statemtns. If am using blocking statements, some of the latches I defined in it are not holding their values.

Is the second always block synthesized as combinational logic or seq logic?

I am using Synopsys design compiler.

 

[digitaldesigner]

rtl state machines

If you use blocking, compiler will tend to create combinational circuit and will eliminate latches as much as possible.

Please provide full code for second always block for us to see and we can make detailed comments.

 

[ljxpjpjljx]

case statement vs state machine

which synthesis tool you use?

 

[shitansh]

machine design

HI,

Normally while using case statement we used to define default condition (either by default state or assign all outputs to some value before case statement) and due to this while state is C your output (store_var) takes default value.

One more thing you need to take care about synchronous or asyncronous state machine coding.

HTH,
--
Shitansh Vaghela

 

[analog_fever]

rtl implementation of state machine

HI,

Normally while using case statement we used to define default condition (either by default state or assign all outputs to some value before case statement) and due to this while state is C your output (store_var) takes default value.

One more thing you need to take care about synchronous or asyncronous state machine coding.

HTH,
--
Shitansh Vaghela

I am not sure if you know what you are talking about. If store_var is declared as a reg variable is it not supposed to hold its previous value, if it is not defined in the present "case" state? Why would it take the default value when there is actually a valid case state.

 

[shelby]

rtl case statement

I am not sure if you know what you are talking about. If store_var is declared as a reg variable is it not supposed to hold its previous value, if it is not defined in the present "case" state? Why would it take the default value when there is actually a valid case state.

Reg variables are not always mapped into sequential logic. If your always block has a clock in the sensativity list, they will become a flip-flop and store the value. In a non-clocked always block they can be combinational if given values in all cases (or given a default case) OR they can become latches (not FFs) if not given values in all cases.

In your case, it looks like store_var should be inferring a latch, but this is normally not good practice. It's best to keep your unclocked always blocks as combinational and assign nets default values as mentioned above to avoid latched. For the store_var reg you can put it in a separate clocked always block.

always @(posedge clk or negedge rst) begin
if (!rst)
store_var <= 1'b0;
else if (state == B)
store_var <= some_parameter;
end

An even better approach would be to define a combinational net (store_var_next) and assign it values for every case (or give it a default) in your combinational always block. Something like this ...

always@* begin
store_var_next = store_var;
case(state)
B: store_var_next = some_parameter;
C: assign store_var_next again here or let it use default above case statement
........
end

always @(posedge clk or negedge rst) begin
if (!rst)
store_var <= 1'b0;
else
store_var <= store_var_next;
end