Xilinx CPLD - FSM - one hot - lost token...

Hello,

i am using a FSM in my CPLD design (XC95108). It is written in ABL. It is
working fine so far, beside some curious behaviour. On some special
condition it seems, my FSM stops working. Something like the token gets lost
??? I have seen it when a lot of "traffic" is on a lot of lines, sometimes
already at start up (i still have the xilinx boot adapter connected all the
time, when i then do a verify of my written program it is running again,
verify succeeded of course). I have not used any global inputs (they are
N.C.), for the state machine i have a initial state inside my abel sources.
I jump everytime from one state to another, can't see any state which gets
lost.

Can you give me a tip for this how to solve it ? Can i use something like a
"default" case to come back even i such a case ? I read that one hot state
machines are not the best things for CPLD. When i convert it, will it solve
my problem ? Is there an easy way of converting it ?

Regards,

         Martin

Martin Maurer wrote:
> Hello,
> 
> i am using a FSM in my CPLD design (XC95108). It is written in ABL. It is
> working fine so far, beside some curious behaviour. On some special
> condition it seems, my FSM stops working. Something like the token gets lost
> ??? I have seen it when a lot of "traffic" is on a lot of lines, sometimes
> already at start up (i still have the xilinx boot adapter connected all the
> time, when i then do a verify of my written program it is running again,
> verify succeeded of course). I have not used any global inputs (they are
> N.C.), for the state machine i have a initial state inside my abel sources.
> I jump everytime from one state to another, can't see any state which gets
> lost.
> 
> Can you give me a tip for this how to solve it ? Can i use something like a
> "default" case to come back even i such a case ? I read that one hot state
> machines are not the best things for CPLD. When i convert it, will it solve
> my problem ? Is there an easy way of converting it ?

  Look in the .RPT file, to see the state-nodes, and the conditions for
a next-state. If a One-Hot ends up with zero, or >=two bits hi, it may
or may not recover. If you have a spare pin, decode those options to it,
and verify if that is your failure mode.
  Causes can be aperture effects, where an external signal is not stable
on the clock edge. Look carefully at async signals that cause state 
changes.
  recovering from all Zero is simple enough, and could be already done
in your code.

-jg

Jim Granville wrote:

> Martin Maurer wrote:
> > Hello,
> >
> > i am using a FSM in my CPLD design (XC95108). It is written in ABL. It is
> > working fine so far, beside some curious behaviour. On some special
> > condition it seems, my FSM stops working. Something like the token gets lost
> > ??? I have seen it when a lot of "traffic" is on a lot of lines, sometimes
> > already at start up (i still have the xilinx boot adapter connected all the
> > time, when i then do a verify of my written program it is running again,
> > verify succeeded of course). I have not used any global inputs (they are
> > N.C.), for the state machine i have a initial state inside my abel sources.
> > I jump everytime from one state to another, can't see any state which gets
> > lost.
> >
> > Can you give me a tip for this how to solve it ? Can i use something like a
> > "default" case to come back even i such a case ? I read that one hot state
> > machines are not the best things for CPLD. When i convert it, will it solve
> > my problem ? Is there an easy way of converting it ?
>
>   Look in the .RPT file, to see the state-nodes, and the conditions for
> a next-state. If a One-Hot ends up with zero, or >=two bits hi, it may
> or may not recover. If you have a spare pin, decode those options to it,
> and verify if that is your failure mode.
>   Causes can be aperture effects, where an external signal is not stable
> on the clock edge. Look carefully at async signals that cause state
> changes.
>   recovering from all Zero is simple enough, and could be already done
> in your code.
>
> -jg

I concur, looking at the equations in the fitter report file is the place to
start. A couple of other notes:
1. In general, a one-hot encoding is not the way to go in CPLDs. It obviously uses
more registers to hold the state bits than, say, a gray encoding. For an Abel
symbolic FSM, you can specify the state-encoding using the Process Properties for
the "Compile Design" step in iSE 6.x. Alternatively, you can put a property
statement in the Abel source. Something like:

XILINX PROPERTY 'ENUM_ENCODING myFSM=gray';

where myFSM is declared in the Abel source to be a STATE_REGISTER.

2. Be aware that the default behavior of Abel FSMs for unspecified cases is
different than VHDL/Verilog. Time has dimmed my memory, but I recall that for a
FSM coded in VHDL or Verilog, if you fail to specify the next state for a certain
condition, the FSM will simply hold state. Abel FSMs (I think this mainly applies
to non-symbolic FSMs) will go to the "all 0's" state, which would not be good for
a one-hot (this assumes that the FSM is implemented using D flops). This behavior
was very clearly documented in the old Abel Reference Manual, but I haven't looked
lately to see how clearly documented it is today.

If you need further info, I would suggest contacting the Xilinx Hotline.

-Dennis McCrohan
Speaking for myself, not for Xilinx.