Coding rules?

[Peter]

I thougth I was a rather experienced VHDL designer until recently....
A very simple mistake - I forgot to initialize the state vector at
reset in a state machine - caused a difference between simulation and
reality. Because the state type was an enumerated type, the state
vector was initialized to its leftmost value at simulation start and
that value was the idle state. That behaviour masked the fact that the
state vector was never reset in the hardware. What do you gentlemen do
to avoid such simple but fatal errors?

Coding rules of some kind?
Code inspection?
Better discipline?
Declaring the idle state as the the rightmost value?
Gate level simulation?

Regards, Peter

 

[Martin Thompson]

Peter <peter.hermansson@sts.saab.se> writes:

I thougth I was a rather experienced VHDL designer until recently....
A very simple mistake - I forgot to initialize the state vector at
reset in a state machine - caused a difference between simulation and
reality. Because the state type was an enumerated type, the state
vector was initialized to its leftmost value at simulation start and
that value was the idle state. That behaviour masked the fact that the
state vector was never reset in the hardware. What do you gentlemen do
to avoid such simple but fatal errors?

Coding rules of some kind?
Code inspection?
Better discipline?
Declaring the idle state as the the rightmost value?
Gate level simulation?

Something I've done in the past is to always make the left-most state an
unused state, then if you forget to reset the state variable, your
state machine will fall to the "when others" clause, which I then put
an assert in. Or you can do an explicit "when rubbish_state =>"

But you do have to remember to do this to your state machines each
time. [hmmm - must get around to writing that emacs macro...]

Other people looking at your code is always good too!

Cheers
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

 

[Mike Treseler]

Peter wrote:

I forgot to initialize the state vector at
reset in a state machine - caused a difference between simulation and
reality.

Coding rules of some kind?
Explicit reset of all registers is one good one.

Code inspection?
Yes, for reset, I compare my variable declarations

to the external reset assignments
to make sure there is no mismatch.

Better discipline?
The discipline is to collect design rules and verify them

before each release.

Declaring the idle state as the the rightmost value?
My rule is to use an enumerated type,

cover all the cases and make no assumptions
about the physical state assignments.
If the other rules are followed, reordering
the type declaration should have no effect.

Gate level simulation?
A good final test, but not sufficient

to cover any rule completely.
Synchronous design, functional testing
and static timing are much more important.

-- Mike Treseler

 

[Reuven]

On May 14, 12:11 am, Peter <peter.hermans...@sts.saab.se> wrote:

I thougth I was a rather experienced VHDL designer until recently....
A very simple mistake - I forgot to initialize the state vector at
reset in a state machine - caused a difference between simulation and
reality. Because the state type was an enumerated type, the state
vector was initialized to its leftmost value at simulation start and
that value was the idle state. That behaviour masked the fact that the
state vector was never reset in the hardware. What do you gentlemen do
to avoid such simple but fatal errors?

Coding rules of some kind?
Code inspection?
Better discipline?
Declaring the idle state as the the rightmost value?
Gate level simulation?

Regards, Peter

If you have the budget, a formal verification tool

( not a netlist checker ) will check for resets.

 

[Peter]

If the other rules are followed, reordering
the type declaration should have no effect.

Thanks for all suggestions.
But reordering the type declaration do have the effect that initial
value (in simulation) of the state vector, does not coincide with the
value expected after a real hardware reset.

Regards, Peter

 

[Mike Treseler]

Peter wrote:

If the other rules are followed, reordering
the type declaration should have no effect.


Thanks for all suggestions.
But reordering the type declaration do have the effect that initial
value (in simulation) of the state vector, does not coincide with the
value expected after a real hardware reset.

If the testbench does the reset first,
there is only a tick or two of difference in simulation,
and no difference at all on the bench.
(assuming the state variable is reset)

-- Mike Treseler