Coding rules?

P

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
 
M

Martin Thompson

Peter said:
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
 
M

Mike Treseler

Peter said:
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
 
R

Reuven

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

HT-Lab

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.

Indeed a formal tool like Averant's SolidAC will check your reset and will
tell you which FF's are not being reset. However, some high-end synthesis
tools like Mentor's Precision will analyse your statemachines and in
addition to the reset state will also tell you if you have equivalent states
and/or unreachable states.

circuit : http://www.ht-lab.com/misc/fsm.html

******************************************
* Extracted FSM Analysis
* Module: fsmb_fsm_0
* State Vector: current_state
******************************************
* States : 5
* Asynch. Reset States : (s0)
* Synch. Reset States : <none>
* Equivalent States : (s1, s4)
* Unreachable States : <none>
******************************************

Hans
www.ht-lab.com
 
P

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
 
M

Mike Treseler

Peter said:
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
 

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

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top