Is my code good?

[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.

 

[Paul Uiterlinden]

bxbxb3 wrote:

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.

 

[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

 

[Eric Smith]

Paul Uiterlinden <no@spam.nl> writes:

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

 

[Thomas Stanka]

Eric Smith wrote:

Paul Uiterlinden <no@spam.nl> writes:
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.

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

--
Emailantworten bitte an thomas[at]obige_domain.
Usenet_10 ist für Viren und Spam reserviert

 

[Eric Smith]

I wrote:

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 <usenet_10@stanka-web.de> writes:

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.

 

[Paul Uiterlinden]

Peter Hermansson wrote:

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.