Prev: 10.1 EDK - How can I create a user library in SDK?
Next: FPGA comeback
From: ee_ether on 23 Apr 2008 05:33
Hi,

A colleague and I are having a friendly debate on coding state
machines in Verilog, targeting synthesis for FPGAs. Comments are very
appreciated. I am NOT trying to start a holy war here regarding
syntax style (one process vs. two process, etc).

Crux of the matter: Do you need to define values for outputs of your
state machine in EVERY state, or do you only need to define values for
outputs in states where you want the output to update/change?

Skip to the chase: At end of message is a Verilog state machine that
does NOT define outputs in all states. Is this acceptable Verilog or
unacceptable (targeting FPGA)? If not, how would you re-write it? If
yes, what are the implications? When you write a SM in Verilog can
you "abbreviate" your output logic and let the synthesizer infer
storage registers for flags assuming you don't define output condition
for all states?

For the code below, the synthesizer (Altera Quartus II v7.1) produces
DFF with MUXes in front ; no latches synthesized. The register is fed
back its value when NOT in the states where value is updated. This is
gleaned from using RTL Viewer in Quartus II. I am curious what ISE
10x would do with this Verilog too...

Colleague: Verilog/RTL is supposed to provide a reasonable
abstraction, so if you have a state machine where you are updating a
flag (i.e. set the bit/flag in one state, clear it in some other), you
only need to define the output in those states where the bit will be
set or cleared. The synthesizer will then produce a register and only
update the value(register) in the correct state. Coding values of ALL
outputs in ALL states would be too tedious and negates advantage of
RTL.

My perspective is : You must define output in every state otherwise
the synthesizer will produce a latch, or some other kind of unwanted
feedback vs. decoding the output based off state registers (and
possibly any other asynchronous inputs). When I wrote VHDL I would
always define output of SM (mealy or moore) and it would result in
unpleasant to read RTL but synthesized to what I want. FWIW, I prefer
to combine output statements and next-state logic in one process since
I can follow the logic more easily; if I want a set/clear type flag
then I define SET_FLAG and CLEAR_FLAG signals and they are driven in
every state; a clocked process is used to check SET and CLEAR to
synchronously toggle output (flag).


cpu_lw_*, ackb are all outputs and outputs are not always defined in
all states (hence the debate).

-----------------------------------------------------------------------------------------------------------------------------------------------

//State Machine
always @ (posedge CLK or negedge negreset)
begin
if(!negreset)
begin
ackb <= 1'b1;
cpu_lw_read <= 1'b0;
cpu_hw_read <= 1'b0;
cpu_lw_write <= 1'b0;
cpu_hw_write <= 1'b0;
state <= 0;
end

else
begin
case (state)
0:
begin
if (!csb)
begin
case (rd_wr_sel)
2'b00: state <= 2;
2'b01: state <= 3;
2'b10:
begin
cpu_lw_read <= 1'b1;
dataout_sel <= 1'b1;
state <= 4;
end
2'b11:
begin
cpu_hw_read <= 1'b1;
dataout_sel <= 1'b1;
state <= 4;
end
endcase
end
else
state <= 0;
end

2:
begin
if(!dsb)
begin
cpu_lw_write <= 1'b1;
state <= 4;
end
else
begin
state <= 2;
end
end

3:
begin
if(!dsb)
begin
cpu_hw_write <= 1'b1;
state <= 4;
end
else
begin
state <= 3;
end
end

4:
begin
if(ready)
begin
ackb <= 1'b0;
state <= 5;
end

else if (csb)
begin
cpu_lw_read <= 1'b0;
cpu_hw_read <= 1'b0;
cpu_lw_write <= 1'b0;
cpu_hw_write <= 1'b0;
state <= 0;
end

else
begin
state <= 4;
end

end

5:
begin
if(csb)
begin
ackb <= 1'b1;
cpu_lw_read <= 1'b0;
cpu_hw_read <= 1'b0;
cpu_lw_write <= 1'b0;
cpu_hw_write <= 1'b0;
state <= 0;
end
else
begin
state <= 5;
end
end
endcase
end
From: Andreas Ehliar on 23 Apr 2008 04:31
On 2008-04-23, ee_ether <xjjzdv402(a)sneakemail.com> wrote:
> Hi,
>
> A colleague and I are having a friendly debate on coding state
> machines in Verilog, targeting synthesis for FPGAs. Comments are very
> appreciated. I am NOT trying to start a holy war here regarding
> syntax style (one process vs. two process, etc).
>
> Crux of the matter: Do you need to define values for outputs of your
> state machine in EVERY state, or do you only need to define values for
> outputs in states where you want the output to update/change?


In a process activated by a clock edge it is not necessary to specify
the output value in every branch. It is possible to create synchronous
logic anyway. The following example will show a flip-flop with a load
enable for example.

always @(posedge clk) begin
if (ce) q <= d; // Flip flop with enable signal
//else q <= q; // This is automatically implied
end

However, if you have a combinational circuit I guess you could see
the construction like this:

always @* begin
if (ce) q = d;
// else q = q; // This is also automatically implied
end

The problem is that q = q would build a combinational loop and the
synthesizer will probably implement this as a latch.



(In reality I guess there might be some simulation issues. I guess
that a simulator is not even going to update q with the value of q
if the else case is not present. Actually, I'm not sure that it will
update q anyway, even if the else case is present as it is just going
to be updated with the same value. A quick experiment indicates that
at least ModelSim doesn't update the variable in this case at least.)

/Andreas
From: KJ on 23 Apr 2008 08:52
On Apr 23, 5:33 am, ee_ether <xjjzdv...(a)sneakemail.com> wrote:
> Hi,
>
> Crux of the matter:  Do you need to define values for outputs of your
> state machine in EVERY state, or do you only need to define values for
> outputs in states where you want the output to update/change?
>

It doesn't matter. The same synthesized output can result from more
than one source code representation.

> Skip to the chase:  At end of message is a Verilog state machine that
> does NOT define outputs in all states.  Is this acceptable Verilog or
> unacceptable (targeting FPGA)?

If it implements the required function than it is acceptable.

> If not, how would you re-write it?  

If it's not broken, don't fix it.

> If
> yes, what are the implications?  When you write a SM in Verilog can
> you "abbreviate" your output logic and let the synthesizer infer
> storage registers for flags assuming you don't define output condition
> for all states?
>

If you get paid by the line of code then you might want to set those
outputs in every state.

> For the code below, the synthesizer (Altera Quartus II v7.1) produces
> DFF with MUXes in front ; no latches synthesized.  The register is fed
> back its value when NOT in the states where value is updated.  This is
> gleaned from using RTL Viewer in Quartus II.  I am curious what ISE
> 10x would do with this Verilog too...
>

Why the curiousity? Run it through and satisfy your curiousity,
that's the best teacher.

> Colleague:  Verilog/RTL is supposed to provide a reasonable
> abstraction, so if you have a state machine where you are updating a
> flag (i.e. set the bit/flag in one state, clear it in some other), you
> only need to define the output in those states where the bit will be
> set or cleared.  The synthesizer will then produce a register and only
> update the value(register) in the correct state.  Coding values of ALL
> outputs in ALL states would be too tedious and negates advantage of
> RTL.
>

Whether one *should* code outputs in every state or not can depend on
how many different paths there can be through the state machine. One
that is fairly simple (like a simple loop) it is likely just as clear
to the reader to only explicitly set the outputs when they need to
change. Another more complicated one where there is all sorts of
branching dependent on various conditions might benefit from coding
the output values in more (or all) of the states.

The other thing that influences the decision (possibly even more) is
whether or not you, from a design perspective, inherently 'know' what
the output should be while you're in a particular state. Many state
machines might not care what the value of output 'xyz' should be while
they're in state 'state_abc'. Those types of state machines will be
more clearly written in the style of specifying output changes rather
than explicitly setting them.

The example that the colleague mentioned sounds to me like a case
where coding only the changes (as he suggests) would be best because
it more clearly captures the intent.

> My perspective is : You must define output in every state otherwise
> the synthesizer will produce a latch, or some other kind of unwanted
> feedback vs. decoding the output based off state registers (and
> possibly any other asynchronous inputs).  

Not true at all...state machines are synchronous things clocked by a
clock, there will be no latches ever produced. You're getting
confused with the 'two process' style where this can happen (which is
why the 'two process' style is considered inferior by most skilled
designers).

> When I wrote VHDL I would
> always define output of SM (mealy or moore) and it would result in
> unpleasant to read RTL but synthesized to what I want.  FWIW, I prefer
> to combine output statements and next-state logic in one process since
> I can follow the logic more easily; if I want a set/clear type flag
> then I define SET_FLAG and CLEAR_FLAG signals and they are driven in
> every state; a clocked process is used to check SET and CLEAR to
> synchronously toggle output (flag).
>

And there is the main criteria you should use....how easy is it to
read and understand the resulting code because that is what one will
need to maintain down the road. Clarity of intent in the source code
is second only to correct function in my book.

Kevin Jennings
From: Muzaffer Kal on 23 Apr 2008 11:25
On Wed, 23 Apr 2008 02:33:32 -0700 (PDT), ee_ether
<xjjzdv402(a)sneakemail.com> wrote:

>Hi,
>
>A colleague and I are having a friendly debate on coding state
>machines in Verilog, targeting synthesis for FPGAs. Comments are very
>appreciated. I am NOT trying to start a holy war here regarding
>syntax style (one process vs. two process, etc).
>
>Crux of the matter: Do you need to define values for outputs of your
>state machine in EVERY state, or do you only need to define values for
>outputs in states where you want the output to update/change?

In either one process or two process designs, you only need to write
to the next state when you need to change it. In one process, the
registers by definition remember their state so there is no chance of
getting a latch. In two states, you assign the next state to the
current state at the top of the process so if they don't get written
again later, they keep their current state so no latches either.
From: Muzaffer Kal on 23 Apr 2008 11:34
On Wed, 23 Apr 2008 15:25:33 GMT, Muzaffer Kal <kal(a)dspia.com> wrote:

>On Wed, 23 Apr 2008 02:33:32 -0700 (PDT), ee_ether
><xjjzdv402(a)sneakemail.com> wrote:
>
>>Hi,
>>
>>A colleague and I are having a friendly debate on coding state
>>machines in Verilog, targeting synthesis for FPGAs. Comments are very
>>appreciated. I am NOT trying to start a holy war here regarding
>>syntax style (one process vs. two process, etc).
>>
>>Crux of the matter: Do you need to define values for outputs of your
>>state machine in EVERY state, or do you only need to define values for
>>outputs in states where you want the output to update/change?
>
>In either one process or two process designs, you only need to write
>to the next state when you need to change it. In one process, the
>registers by definition remember their state so there is no chance of
>getting a latch. In two states, you assign the next state to the

this should say "in two process implementation..." of course

>current state at the top of the process so if they don't get written
>again later, they keep their current state so no latches either.

here are some example for my points:

always@(posedge clk)
if (enable)
count <= count+1;

in this case there is no need for
else
count <= count;

because if not enable counter registers remember their state so in a
state machine, there is no reason to write to states/outputs which
don't need changing.

In two process design, you say
always @(*)
begin
next_state = state;
case (state)
foo: next_state = bar;
bar: output_x = 6; // no state change
...
end

in this case the first line always assigns next_state so if later not
reassigned it remembers that value so there is no latch for
next_state, strictly combinational of off state.
 |  Next  |  Last
Pages: 1 2
Prev: 10.1 EDK - How can I create a user library in SDK?
Next: FPGA comeback