Is my code good?

B

bxbxb3

Hi,
I have a doubt whether the following coding style is a good one or not.

process(clock)
begin
if(clock'event and clock='1') then
case state is
when START_RD=>

when NEXT1=>

when FINAL=>
o_Frame_SaComapact1_Rt <= i_myMacAddress;
end case;
end if;
end process;


Two of the case statements have nothing to do in that state. Will this
infer a latch? Is it better to use a "if" statement instead?
Thanks in advance.
 
P

Paul Uiterlinden

bxbxb3 said:
Hi,
I have a doubt whether the following coding style is a good one or not.

process(clock)
begin
if(clock'event and clock='1') then
case state is
when START_RD=>

when NEXT1=>

when FINAL=>
o_Frame_SaComapact1_Rt <= i_myMacAddress;
end case;
end if;
end process;


Two of the case statements have nothing to do in that state. Will this
infer a latch?

No, it will infer a flip-flop because that's what you describe in your
process ("if(clock'event and clock='1')").
Is it better to use a "if" statement instead?

Depends whether this is the only decoding you do with 'state'. In
general, I do like to use case statements with enumeration types.

If the code is not going to be synthesized, I _never_ use a "when
others" choice. Reason: if you later expand (add members) to you
enumeration type and you forget to modify your case statement, the code
will fail already at compilation time, because case choices must be
complete.

For synthesis this is different: the state variable/signal will be
mapped to a vector, giving 2**n possible states. So here you _must_ use
a "when others" choice, to prevent hang-up situations if the state
vector ever gets one of those unused states.

Paul.
 
P

Peter Hermansson

For synthesis this is different: the state variable/signal will be
mapped to a vector, giving 2**n possible states. So here you _must_ use
a "when others" choice, to prevent hang-up situations if the state
vector ever gets one of those unused states.

Paul.

Hi,

I am not convinced that synthesis programs generate fail-safe FSMs
only because of the "when others" clause. Please refer to the
application note "Designing Safe VHDL State Machines with Synplify".

/Peter
 
E

Eric Smith

Paul Uiterlinden said:
For synthesis this is different: the state variable/signal will be
mapped to a vector, giving 2**n possible states. So here you _must_
use a "when others" choice, to prevent hang-up situations if the state
vector ever gets one of those unused states.

Note that VHDL semantics only define "when others" to affect the other
legal values of the type. For instance, if you have an enumeration with
three values, FOO, BAR, and BAZ, which will synthesize to a two bit
vector, a "when others" clause does not cover the fourth possible state
of the vector.

A synthesis tool may choose to expand the meaning to encompass the
illegal values, but the VHDL LRM does not guarantee this, so you have to
determine it for the specific synthesis tool.

Eric
 
T

Thomas Stanka

Eric said:
Note that VHDL semantics only define "when others" to affect the other
legal values of the type. For instance, if you have an enumeration with
three values, FOO, BAR, and BAZ, which will synthesize to a two bit
vector, a "when others" clause does not cover the fourth possible state
of the vector.

You should allways expand your enumerations to 2**n states (foo, bar, baz,
unused) to avoid this problem.
BTW when using synplify, you should replace each enumeration type with
constant declarations, if you like to have a determistic result, that
didn't mess up you equivalence check.

bye Thomas
 
P

Paul Uiterlinden

Peter said:
I am not convinced that synthesis programs generate fail-safe FSMs
only because of the "when others" clause. Please refer to the
application note "Designing Safe VHDL State Machines with Synplify".

Thanks for the pointer. Interesting stuff.

When I wrote my message, I had Synopsys design_compiler in mind. There
the "when others" does work.

Paul.
 
E

Eric Smith

I said:
Note that VHDL semantics only define "when others" to affect the other
legal values of the type. For instance, if you have an enumeration with
three values, FOO, BAR, and BAZ, which will synthesize to a two bit
vector, a "when others" clause does not cover the fourth possible state
of the vector.

Thomas Stanka said:
You should allways expand your enumerations to 2**n states (foo, bar, baz,
unused) to avoid this problem.

Agreed, this is the best approach to avoid dependence on characteristics
of a specific synthesizer. Then the "when others" clause can be used
with predictable results.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,776
Messages
2,569,603
Members
45,189
Latest member
CryptoTaxSoftware

Latest Threads

Top