One-Hot or Gray-Code State Machine? 
Author Message
 One-Hot or Gray-Code State Machine?

Recently, I heard an argument against using one-hot state machines.  A
co-worker told me they were notorious for not being able to recover from
an unknown state (the author of a well-known verilog book told me the
same thing).  Is this true?  Has anyone had a real-world, one-hot design
go "into the weeds" and never come back to a known state?  Up to now,
I've always heard that one-hot designs were the way to go for FPGA design
but now I'm confused.  Any experiences for or against would be
appreciated.

--
Jaime Villela



Sun, 19 Oct 2003 03:02:50 GMT  
 One-Hot or Gray-Code State Machine?

I think it depends upon the application, and what happens upon failure.

For standard commercial designs, I've always taken the approach that
my design should never jump from a valid to an invalid state.  I've
used one-hot at times, and didn't put in extra hardware to detect and
recover.

Despite the usual excuses (fluorescent lights, power line surges, air
conditioning cycling, the cleaning people vacuuming near the equipment
in the middle of the night, and so on), I've always found intermittent
errors to be design problems.  Once they're fixed, systems run
indefinitely.

It's true that one-hot has more invalid states (2**n - n) then an
encoded state machine, so it would be harder to detect them all and
steer the state machine to a valid state.

So what?

If you assume your flip flops are unreliable, the state machine is the
tip of the iceberg.  How do you recover from a floating  accumulator
accumulator which flips to the wrong value?

You need error detection and correction on data registers, memory, and
every other bit that could spontaneously flip.

Either design a true fault tolerant system, or use the one-hot and
make sure there aren't any timing errors, power supplies are clean,
etc.

My humble opinion.

Quote:

> Recently, I heard an argument against using one-hot state machines.  A
> co-worker told me they were notorious for not being able to recover from
> an unknown state (the author of a well-known verilog book told me the
> same thing).  Is this true?  Has anyone had a real-world, one-hot design
> go "into the weeds" and never come back to a known state?  Up to now,
> I've always heard that one-hot designs were the way to go for FPGA desig
> but now I'm confused.  Any experiences for or against would be=20
> appreciated.

> --
> Jaime Villela


--
--



Sun, 19 Oct 2003 04:22:50 GMT  
 One-Hot or Gray-Code State Machine?
Jaime,

to a one-hot state machine, it could wind up in an undefined state.  The
more states you use, the more undefined states it could wind up in.

know of.  I've had machinery/equipment running day and night with no
problems.
     I suppose if I were designing some life critical hardware or something
related to nuclear weapons, I might consider defining every state.
     What are your applications?
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL  USA


Recently, I heard an argument against using one-hot state machines.  A
co-worker told me they were notorious for not being able to recover from
an unknown state (the author of a well-known verilog book told me the
same thing).  Is this true?  Has anyone had a real-world, one-hot design
go "into the weeds" and never come back to a known state?  Up to now,
I've always heard that one-hot designs were the way to go for FPGA design
but now I'm confused.  Any experiences for or against would be
appreciated.

--
Jaime Villela



Sun, 19 Oct 2003 04:25:52 GMT  
 One-Hot or Gray-Code State Machine?

===========
Recently, I heard an argument against using one-hot state machines.  A=20
co-worker told me they were notorious for not being able to recover from=
=20
an unknown state (the author of a well-known verilog book told me the=20
same thing).  Is this true?  Has anyone had a real-world, one-hot design=
=20
go "into the weeds" and never come back to a known state?  Up to now,=20
I've always heard that one-hot designs were the way to go for FPGA desig=
n=20
but now I'm confused.  Any experiences for or against would be=20
appreciated.
============

   Well if you design the one hot correctly, only an error would get you to
the no ones state, you could put a circuit in to detect that and go to some
error or initialization state (basically a NOR of all State bits to detect
a lost 1, and a more than two detector to detect an extra 1).

Note that for regular coding, you have to put logic in to detect, invalid states
as well, then go to an error state.  Even a fully defined state machine (i.e. no
invalid states) can go south if a bit error causes an illegal transition, and
in this case you can't detect that you got to the 'valid' state incorrectly.  With
the one hot you can always detect an invalid state.

In practice, the way I've seen bit errors handled in state machines, is via
some other intelligence monitoring the behavior of the system and doing
reset to any State machine that is suspected to be locked up or not performing
properly (aside from replicated lock step SM or some other coding style used
to insure that bit errors are detected...).

Ken



Sun, 19 Oct 2003 04:02:20 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. One-Hot or Gray-Code State Machine

2. Formal verification of one-hot state machine.

3. One-hot state machines

4. Output decoding of one hot encoded state machine

5. One Hot state machine encoding with Max+plus

6. acquiring data in one phase of a state machine and saving it in another

7. C/C++ sample codes for state machine

8. Announce: state machine code generator

9. Code generation and state machines

10. Use of a Finite State Machine in testbench code

11. OO-Code for a state machine

12. state machine coding style

 

 
Powered by phpBB® Forum Software