Statemachine debugging with Chipscope

[Richard G.]

Hi all,

I have a very simple question. I have a statemachine, where the states
are declared as follows:

type SM_TYPE is (IDLE,WRITE0,WRITE1,READ1,ABORT0, ABORT1,ABORT2,ABORT3,
ABORT4, DONE);

signal nstate : SM_TYPE;

I would like to have now an output signal of my state machine which
encodes the state to that I can use this signal to debug the
statemachine with Chipscope. I am just wondering what kind of signal
the output port that encodes the state has to be. I think one-hot
encoding is used, and I have 10 states, so I would assume that
I could declare it like that

port (
...
dbg_state_out : out std_logic_vector(9 downto 0);
...
);

....

dbg_state_out <= nstate;

Is my approach right, or is the state encoded in something different
than a std_logic_vector.

Many thanks

 

[Fredxx]

Richard G. wrote:

Hi all,

I have a very simple question. I have a statemachine, where the states
are declared as follows:

type SM_TYPE is (IDLE,WRITE0,WRITE1,READ1,ABORT0,
ABORT1,ABORT2,ABORT3, ABORT4, DONE);

signal nstate : SM_TYPE;

I would like to have now an output signal of my state machine which
encodes the state to that I can use this signal to debug the
statemachine with Chipscope. I am just wondering what kind of signal
the output port that encodes the state has to be. I think one-hot
encoding is used, and I have 10 states, so I would assume that
I could declare it like that

port (
...
dbg_state_out : out std_logic_vector(9 downto 0);
...
);

...

dbg_state_out <= nstate;

Is my approach right, or is the state encoded in something different
than a std_logic_vector.

Many thanks

I didn't think you could cast a statemachine signal into a vector.

I've used the long hand way of putting statemachine in another process to
convert the state into a std_logic_vector

nstate_proc : process(nstate)
begin
case nstate is
when IDLE => dbg_state_out <= "000000000"
....
....
....
end case;
end process;

 

[jc]

Just to expound on what Fredxx described, I usually binary encode my
one-hot state machine bits to reduce the bits (e.g. 16 states gets
reduced to 4 bits) before reporting the state to a status reg. Just
remember to pipeline properly to isolate from the one-hot
implementation. For example, register the one-hots into another
register, then do the double-ranking into another set of regs. Also
remember to use a "capture_status" signal if multiple clock domains
are used to synchronize your binary-encoded state bits. For chipscope
purposes, simply add these binary-encoded bits into your signal
monitoring list, but remember to account for coherency between the
binary-encoded bits and other signals you may be monitoring.

 

[Martin Thompson]

"Richard G." <Richard@yahoo.com> writes:

Hi all,

I have a very simple question. I have a statemachine, where the states
are declared as follows:

type SM_TYPE is (IDLE,WRITE0,WRITE1,READ1,ABORT0, ABORT1,ABORT2,ABORT3,
ABORT4, DONE);

signal nstate : SM_TYPE;

I would like to have now an output signal of my state machine which
encodes the state to that I can use this signal to debug the
statemachine with Chipscope.

If you use the chipscope core inserter, you can just probe the state
directly. I usually put an attribute on my state machine to stop it
being one-hot encoded in these cases if I can get away with it as it
means the signal is much narrower, so less BRAMs are used.

Check the synth reports very carefully as the state mapping is
unlikely to be anything you expect it to be once the optimiser has
finished

If you are wanting to instantiate the ILA within your HDL the solution
already presented of a separate process with explicit decode works
fine, if a little verbose (and potentially error-prone if you're
changing the content of SM_TYPE a lot).

As an alternative, you could try using the "'pos method" (XST seems to
accept this, although I haven't taken it through to a bitstream):

debug_sig <= std_logic_vector(to_unsigned(nstate'pos, debug_sig'length));

This may have the side-effect of forcing state to be binary-encoded,
depending on the logic around it I think.

I am just wondering what kind of signal the output port that encodes
the state has to be. I think one-hot encoding is used, and I have 10
states, so I would assume that I could declare it like that

port (
...
dbg_state_out : out std_logic_vector(9 downto 0);
...
);

...

dbg_state_out <= nstate;

Is my approach right, or is the state encoded in something different
than a std_logic_vector.

VHDL is strongly typed, so you can't do anything like that. Within
the VHDL language, there is no concept of "state encodings". They are
just elements of an enumerated type, with no other existence - other
than the fact you can use the 'pos attribute to get a numerical
position for them.

HTH,

Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

 

[Gabor]

On Nov 8, 7:40 am, jc <jcappe...@optimal-design.com> wrote:

Just to expound on what Fredxx described, I usually binary encode my
one-hot state machine bits to reduce the bits (e.g. 16 states gets
reduced to 4 bits) before reporting the state to a status reg. Just
remember to pipeline properly to isolate from the one-hot
implementation. For example, register the one-hots into another
register, then do the double-ranking into another set of regs. Also
remember to use a "capture_status" signal if multiple clock domains
are used to synchronize your binary-encoded state bits. For chipscope
purposes, simply add these binary-encoded bits into your signal
monitoring list, but remember to account for coherency between the
binary-encoded bits and other signals you may be monitoring.

One more point, if you will be using the ChipScope inserter, you
may need to add a KEEP attribute on your encoded state vector
to prevent it from being removed from the design before the translate
phase where the inserter grabs its connections. Also I have used
the inserter to attach to state machine state variables without
encoding
them first. They tend to keep the same name as the original state
variable with a numeric suffix. However you would need to figure
out the encoding (usually reported in the synthesis report) in order
to use these directly. I found that in the case of binary encoding,
the post-translate signals have numeric suffixes 1 to N that
roughly match N-1 downto 0 of the encoded bits. This means
you probably have to reverse the bus order in the ChipScope
viewer.

regards,
Gabor

 

[Gabor]

On Nov 8, 10:44 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
[snip]

debug_sig <= std_logic_vector(to_unsigned(nstate'pos, debug_sig'length));

This may have the side-effect of forcing state to be binary-encoded,
depending on the logic around it I think.

My experience has been that no matter how you use state variables in
your
code, the encoding is based on optimization. So even if your states
are
listed in a binary fashion AND you use the state variable externally,
e.g.
in a status register, you may still have one-hot encoding if that
makes
the synthesizer happy. The state will then be re-encoded for external
use. This of course masks problems with one-hot encoding, as the
"zero hot" state usually shows up in the re-encoded binary state
as state "0" rather than no state.

Regards,
Gabor

 

[jc]

I've had success referencing variables in binary-encode construct:

CASE is pstate
WHEN idle => pstate_binencode <= X"0";
WHEN st_s1 => pstate_binencode <= X"1";
:
WHEN st_term => pstate_binencode <= X"A";
WHEN OTHERS => pstate_binencode <= X"F";
END CASE;

In this case, my binencode sequence will follow what I expect from the
way the fsm was coded, regardless of how bits were synthesized or what
new labels are used. The "pstate_binencode" signal should appear in
chipscope as a 4-bit vector that sequences from 0x0, 0x1, etc., for
normal sequence. The "OTHERS" clause even has built-in illegal state
detection in case you'd want to add some fault tolerance.

 

[glen herrmannsfeldt]

Gabor <gabor@alacron.com> wrote:
(snip)

My experience has been that no matter how you use state variables
in your code, the encoding is based on optimization.
So even if your states are listed in a binary fashion AND you
use the state variable externally, e.g. in a status register,
you may still have one-hot encoding if that makes the synthesizer
happy. The state will then be re-encoded for external
use. This of course masks problems with one-hot encoding, as the
"zero hot" state usually shows up in the re-encoded binary state
as state "0" rather than no state.

Just as long as it doesn't do what one did to me some years ago.

I had a two bit/four state machine, using the state externally.
The software recoded it as one-hot, and gave two of the bits
as the output, without re-encoding them.

-- glen

 

[Martin Thompson]

jc <jcappello@optimal-design.com> writes:

I've had success referencing variables in binary-encode construct:

CASE is pstate
WHEN idle => pstate_binencode <= X"0";
WHEN st_s1 => pstate_binencode <= X"1";
:
WHEN st_term => pstate_binencode <= X"A";
WHEN OTHERS => pstate_binencode <= X"F";
END CASE;

Is this not just a longer-winded version of pstate'pos (barring the
"others" bit...)

In this case, my binencode sequence will follow what I expect from the
way the fsm was coded, regardless of how bits were synthesized or what
new labels are used. The "pstate_binencode" signal should appear in
chipscope as a 4-bit vector that sequences from 0x0, 0x1, etc., for
normal sequence. The "OTHERS" clause even has built-in illegal state
detection in case you'd want to add some fault tolerance.

If you're using an enumerated type, and you've covered all the
elements in the "real" cases, I'd expect the "others" clause will just
be chucked away by the synth - unless you have one with special
pragma's for making safe state-machines.

Have you seen otherwise?

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

 

[Martin Thompson]

Gabor <gabor@alacron.com> writes:

On Nov 8, 10:44 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
[snip]

debug_sig <= std_logic_vector(to_unsigned(nstate'pos, debug_sig'length));

This may have the side-effect of forcing state to be binary-encoded,
depending on the logic around it I think.


My experience has been that no matter how you use state variables in
your code, the encoding is based on optimization.

Indeed - that's what I meant. [Depending on the other logic around
the SM] the synth may decide that the best encoding (now that you've
said you want a numerical representation of the states) is to keep
them binary coded.

Or it might not and produce a 1-hot SM with some 1-hot to integer
decode logic (as you pointed out later).

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

 

[jc]

On Nov 9, 8:42 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:

jc <jcappe...@optimal-design.com> writes:
I've had success referencing variables in binary-encode construct:

CASE is pstate
  WHEN idle => pstate_binencode <= X"0";
  WHEN st_s1 => pstate_binencode <= X"1";
  :
  WHEN st_term => pstate_binencode <= X"A";
  WHEN OTHERS => pstate_binencode <= X"F";
END CASE;

Is this not just a longer-winded version of pstate'pos (barring the
"others" bit...)

I suppose...

In this case, my binencode sequence will follow what I expect from the
way the fsm was coded, regardless of how bits were synthesized or what
new labels are used. The "pstate_binencode" signal should appear in
chipscope as a 4-bit vector that sequences from 0x0, 0x1, etc., for
normal sequence. The "OTHERS" clause even has built-in illegal state
detection in case you'd want to add some fault tolerance.

If you're using an enumerated type, and you've covered all the
elements in the "real" cases, I'd expect the "others" clause will just
be chucked away by the synth - unless you have one with special
pragma's for making safe state-machines.

Have you seen otherwise?

Good question Martin. I agree, we could assume synthesis tool will
discard default case if # states = 2^n. But what about when number of
elements (states) isn't multiple of 2^n? If I have, say, 11 states,
and I want to code them to binary after the fact (i.e. register those
states into separate 11-bit vector, assuming one-hot), I need 4 bits
to encode the 11 possibilities. If there's some glitch, act of God,
poorly-timed circuit, async inputs, whatever, and the result is that
more than one flop goes high in my 11-bit vector (illegal!), how can
we guarantee that the synthesis tool will go to any particular value?
In the code above, I'm forcing it to go to all 1's--I could have
encoded it to go to any value.
Regards,
John

 

[Gabor]

On Nov 9, 2:00 pm, jc <jcappe...@optimal-design.com> wrote:

On Nov 9, 8:42 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:

jc <jcappe...@optimal-design.com> writes:
I've had success referencing variables in binary-encode construct:

CASE is pstate
  WHEN idle => pstate_binencode <= X"0";
  WHEN st_s1 => pstate_binencode <= X"1";
  :
  WHEN st_term => pstate_binencode <= X"A";
  WHEN OTHERS => pstate_binencode <= X"F";
END CASE;

Is this not just a longer-winded version of pstate'pos (barring the
"others" bit...)

I suppose...

In this case, my binencode sequence will follow what I expect from the
way the fsm was coded, regardless of how bits were synthesized or what
new labels are used. The "pstate_binencode" signal should appear in
chipscope as a 4-bit vector that sequences from 0x0, 0x1, etc., for
normal sequence. The "OTHERS" clause even has built-in illegal state
detection in case you'd want to add some fault tolerance.

If you're using an enumerated type, and you've covered all the
elements in the "real" cases, I'd expect the "others" clause will just
be chucked away by the synth - unless you have one with special
pragma's for making safe state-machines.

Have you seen otherwise?

Good question Martin. I agree, we could assume synthesis tool will
discard default case if # states = 2^n. But what about when number of
elements (states) isn't multiple of 2^n? If I have, say, 11 states,
and I want to code them to binary after the fact (i.e. register those
states into separate 11-bit vector, assuming one-hot), I need 4 bits
to encode the 11 possibilities. If there's some glitch, act of God,
poorly-timed circuit, async inputs, whatever, and the result is that
more than one flop goes high in my 11-bit vector (illegal!), how can
we guarantee that the synthesis tool will go to any particular value?
In the code above, I'm forcing it to go to all 1's--I could have
encoded it to go to any value.
Regards,
John

I think the part you're missing is that the same synthesis tool will
optimize
the re-encoding of your one-hot to binary. It PRESUMES that the one-
hot
codes are, well, one hot. So it can happily ignore your default case
and
just make sure that the 11 states it knows about will generate the
proper
binary number. In Verilog parlance, it presumes a parallel_case and
full_case for the 11 known values.

The simplest way to encode this uses only OR gates, and MIGHT
give you a value outside the range of 0 to 10 if there are multiple
states hot,
however it WILL encode to zero if the machine goes zero-hot. This is
indistinguishable from state zero (idle). The only time I don't see
this behavior is
when the synthesis option to create "safe" state machine logic is
used.

regards,
Gabor

 

[KJ]

On Nov 9, 2:00 pm, jc <jcappe...@optimal-design.com> wrote:

and the result is that
more than one flop goes high in my 11-bit vector (illegal!), how can
we guarantee that the synthesis tool will go to any particular value?

1. By using a synthesis tool specific switch to generate a 'safe'
state machine
2. Add the code to handle the other cases.

Then verify that the tool is actually doing what you expect it to do.
This might involve simulating a gate level model, finding the nodes
that implements the states and forcing one or more of the bits to a
value to create an illegal state for one clock cycle and see what
happens. Verify that both binary and one hot encoded versions of the
same source code will recover (if the synthesis tool switch is set to
'safe') and that it might not (if the synthesis tool switch is not set
to 'safe').

In the code above, I'm forcing it to go to all 1's--I could have
encoded it to go to any value.

That's half of the battle...the other half is the synthesis tool
switch.

Kevin

 

[jc]

"Safe mode" will add overhead logic into the current/next state
decoding paths, which could negatively impact overall timing depending
on encoding method, # states, and recovery scheme built in by
synthesis tool (or user, if done manually). So one advantage of
registering states and doing binary conversion is that user can re-
locate any necessary detection/recovery logic from current/next state
decoding and into the binary conversion path. Assuming that an illegal
state event would be a rare and catastrophic (fsm would be dead),
recovery would occur two cycles later, perhaps with the use of a sync
"recovery" reset that configures all one-hot flops to desired recovery
state. (that is unless any illegal state cannot be tolerated for more
than one cycle, in which case the recovery logic must be built in to
the original fsm code).
In summary, registering state bits and doing binary conversion allows
benefit of shrinking one-hot state to reasonable vector for status
reporting, less intrusive chipscope monitoring, and decoupling
recovery logic from actual fsm next state decode.
John

 

[KJ]

On Nov 11, 7:58 am, jc <jcappe...@optimal-design.com> wrote:

In summary, registering state bits and doing binary conversion allows

Maybe I'm missing something here, and just need a clearer
explanation...

What is the output of the binary conversion when the input is an
illegal state value? (Example: Three bit one hot that ends up at
"111")

How do you specify the binary conversion function when the input is an
enumerate type? The t_my_type'pos(xyz) won't do it. In the previous
example it would return a number from 0 to 2. Even allowing that the
implementation of the function would compute two bits and therefore be
capable of returning 0 to 3, it does not cover the case that I
mentioned "111". The fact that there are three bits implementing the
one hot encoding means that there are 8 possibilities, most of which
can not be specified in any fashion.

Kevin

 

[Jeff Cunningham]

On 11/12/10 9:28 AM, jc wrote:

Kevin, I suspect (as others pointed out here) that using the OTHERS
clause in a case statement for the binary conversion of a non-2^n
number of states isn't enough to ensure safe mode, i.e. if more than
one one-hot flop goes high, go to recovery state. In which case it
would be up to the user to flip the safe mode switch for the original
fsm flops, or apply custom logic on the binary conversion side to
detect the condition, if this detection is desired. Otherwise, I
believe the binary conversion will 'mask' such invalid conditions. If
I get time soon, I'm going to analyze a set of gates for such a binary
conversion process to see exactly what it does for invalid
conditions.

I've tested this and verified the XST produces identical CPLD jedec
files whether or not the "when OTHERS" is present in a state machine.

Having said that, I'm confident that a binary conversion using the
CASE statement after registering the one-hot flops is a valid way to
follow the sequence of the fsm in an expected order. I've done this
many times via chipscope.
John

But doesn't this only work if the state machine doesn't go to an illegal
state? Otherwise, if it goes 2-hot for example, the binary conversion
can't indicate both states, and will be in effect a priority encoder.

I've found that providing an independent decode for each state, i.e.
make 4 registered debug bits for a 4-state enum is a pretty bullet proof
way of catching illegal states without having to delve into low level
state signal names post synthesis:

process(clk)
begin
if state = s0 then
state0_debugbit <= '1';
else
state0_debugbit <= '0';
end if;
end process;

process(clk)
begin
if state = s1 then
state1_debugbit <= '1';
else
state1_debugbit <= '0';
end if;
end process;

and so on...
So state0_debugbit will be identical (after a register delay) to the
1-hot state bit.

I think it should be possible to wrap this up in a loop like this:

type state_t is (s0,s1,s2,s3);
signal state: state_t;
signal state_debugbits(3 downto 0);

process(clk)
begin
for i in 0 to 3 loop
if state = state_t'val(i) then
state_debugbits(i) <= '1';
else
state_debugbits(i) <= '0';
end if;
end loop;
end process;

-Jeff

 

[jc]

On Nov 11, 5:29 pm, KJ <kkjenni...@sbcglobal.net> wrote:

On Nov 11, 7:58 am, jc <jcappe...@optimal-design.com> wrote:

In summary, registering state bits and doing binary conversion allows

Maybe I'm missing something here, and just need a clearer
explanation...

What is the output of the binary conversion when the input is an
illegal state value? (Example:  Three bit one hot that ends up at
"111")

How do you specify the binary conversion function when the input is an
enumerate type?  The t_my_type'pos(xyz) won't do it.  In the previous
example it would return a number from 0 to 2.  Even allowing that the
implementation of the function would compute two bits and therefore be
capable of returning 0 to 3, it does not cover the case that I
mentioned "111".  The fact that there are three bits implementing the
one hot encoding means that there are 8 possibilities, most of which
can not be specified in any fashion.

Kevin

Kevin, I suspect (as others pointed out here) that using the OTHERS
clause in a case statement for the binary conversion of a non-2^n
number of states isn't enough to ensure safe mode, i.e. if more than
one one-hot flop goes high, go to recovery state. In which case it
would be up to the user to flip the safe mode switch for the original
fsm flops, or apply custom logic on the binary conversion side to
detect the condition, if this detection is desired. Otherwise, I
believe the binary conversion will 'mask' such invalid conditions. If
I get time soon, I'm going to analyze a set of gates for such a binary
conversion process to see exactly what it does for invalid
conditions.

Having said that, I'm confident that a binary conversion using the
CASE statement after registering the one-hot flops is a valid way to
follow the sequence of the fsm in an expected order. I've done this
many times via chipscope.
John

 

[jc]

On Nov 11, 5:29 pm, KJ <kkjenni...@sbcglobal.net> wrote:

On Nov 11, 7:58 am, jc <jcappe...@optimal-design.com> wrote:

In summary, registering state bits and doing binary conversion allows

Maybe I'm missing something here, and just need a clearer
explanation...

What is the output of the binary conversion when the input is an
illegal state value? (Example:  Three bit one hot that ends up at
"111")

How do you specify the binary conversion function when the input is an
enumerate type?  The t_my_type'pos(xyz) won't do it.  In the previous
example it would return a number from 0 to 2.  Even allowing that the
implementation of the function would compute two bits and therefore be
capable of returning 0 to 3, it does not cover the case that I
mentioned "111".  The fact that there are three bits implementing the
one hot encoding means that there are 8 possibilities, most of which
can not be specified in any fashion.

Kevin

Kevin, I suspect (as others pointed out here) that using the OTHERS
clause in a case statement for the binary conversion of a non-2^n
number of states isn't enough to ensure safe mode, i.e. if more than
one one-hot flop goes high, go to recovery state. In which case it
would be up to the user to flip the safe mode switch for the original
fsm flops, or apply custom logic on the binary conversion side to
detect the condition, if this detection is desired. Otherwise, I
believe the binary conversion will 'mask' such invalid conditions. If
I get time soon, I'm going to analyze a set of gates for such a binary
conversion process to see exactly what it does for invalid
conditions.

Having said that, I'm confident that a binary conversion using the
CASE statement after registering the one-hot flops is a valid way to
follow the sequence of the fsm in an expected order. I've done this
many times via chipscope.
John

 

[jc]

On Nov 11, 5:29 pm, KJ <kkjenni...@sbcglobal.net> wrote:

On Nov 11, 7:58 am, jc <jcappe...@optimal-design.com> wrote:

In summary, registering state bits and doing binary conversion allows

Maybe I'm missing something here, and just need a clearer
explanation...

What is the output of the binary conversion when the input is an
illegal state value? (Example:  Three bit one hot that ends up at
"111")

How do you specify the binary conversion function when the input is an
enumerate type?  The t_my_type'pos(xyz) won't do it.  In the previous
example it would return a number from 0 to 2.  Even allowing that the
implementation of the function would compute two bits and therefore be
capable of returning 0 to 3, it does not cover the case that I
mentioned "111".  The fact that there are three bits implementing the
one hot encoding means that there are 8 possibilities, most of which
can not be specified in any fashion.

Kevin

Kevin, I suspect (as others pointed out here) that using the OTHERS
clause in a case statement for the binary conversion of a non-2^n
number of states isn't enough to ensure safe mode, i.e. if more than
one one-hot flop goes high, go to recovery state. In which case it
would be up to the user to flip the safe mode switch for the original
fsm flops, or apply custom logic on the binary conversion side to
detect the condition, if this detection is desired. Otherwise, I
believe the binary conversion will 'mask' such invalid conditions. If
I get time soon, I'm going to analyze a set of gates for such a binary
conversion process to see exactly what it does for invalid
conditions.

Having said that, I'm confident that a binary conversion using the
CASE statement after registering the one-hot flops is a valid way to
follow the sequence of the fsm in an expected order. I've done this
many times via chipscope.
John

 

[KJ]

On Nov 12, 9:28 am, jc <jcappe...@optimal-design.com> wrote:

Kevin, I suspect (as others pointed out here) that using the OTHERS
clause in a case statement for the binary conversion of a non-2^n
number of states isn't enough to ensure safe mode

I fully understand that "when others" does not necessarily generate
recovery logic. Altera (and I suspect other tools) require a specific
synthesis tool setting in order to enable 'safe state machines'. With
Quartus, the setting is called "Safe State Machine" and is defined as
"Tells the compiler to implement state machines that can recover
gracefully from an illegal state."

, i.e. if more than
one one-hot flop goes high, go to recovery state. In which case it
would be up to the user to flip the safe mode switch for the original
fsm flops, or apply custom logic on the binary conversion side to
detect the condition, if this detection is desired.

I agree that this logic can be manually added and also that allowing
an extra clock cycle to recover might be acceptable also but I'm not
seeing how your suggestion of a binary conversion function can be
specified in the source code. For example, the three bit 'one hot'
encoded example will have three bits and therefore 8 states (3 legal,
5 not legal). In order to 'know' that there are 5 illegal states in
the final implementation, one would have to know ahead of time that it
would be one-hot encoded. If the implementation was binary encoded
there would only be one illegal state.

Now ask yourself,
1. For a given enumeration type of 'n' values, what is the range of
the integer value that is the output of your function? Is it '0 to n
- 1'? Is it '0 to 2^n - 1'?
2. Using your answer to #1, explain why your answer is correct and why
the other suggested answer is wrong. Does the 'pos() VHDL attribute
have the same range as the answer that you think is correct?
3. Explain how you guarantee that the implementation of the final
synthesized result has the encoding that matches the assumption that
went into your answer to #1 and how the wrong answer from #2 will
never be synthesized.
4. Explain how your answer to #3 is portable across multiple tools.
Or, to view it a different way, which recognized standard provides the
basis for your guarantee on #3? Hint: Since #1 said enumerated type,
the basis for any guarantee to #3 will not be the VHDL language
standard.

In the end, there is probably no way to use an enumerated type and
make it through all of the above questions. Using Quartus, the only
way to get a safe state machine is to use a tool specific
setting...but on the other hand, the only reason that the tool
specific setting is required is because the tool also decided it was
OK to ignore the "when others" in the source code in the first place.

Having said that, I'm confident that a binary conversion using the
CASE statement after registering the one-hot flops is a valid way to
follow the sequence of the fsm in an expected order. I've done this
many times via chipscope.

Debug in chipscope may have been the OP's original question, but this
sub-topic has to do with recovery from illegal states and being able
to specify something that gets implemented.

Kevin Jennings