Safe state machine design problem

Hi all,

I've been going through the archives trying to find a hint to the problem I am having with a state machine (it occasionaly enters illegal states and doesn't come out) and I found this post:

--------------------------------------------------------------------- From: iglam ( snipped-for-privacy@deletethispart.home.com) Subject: Re: safe state machine design problem Newsgroups: comp.lang.vhdl, comp.arch.fpga Date: 2001-06-08 08:26:41 PST

If you are using enumerated types, then your when others clause is doing nothing. You've already listed all of the elements of the state type when you built your case statement. So, the first thing is, your synthesis tool tosses that line.

Next, your synthesis engine decides to one-hot build the state machine. OK, great. Then, you screw up the state by forcing two bits high, and it goes out to lunch. Makes sense. The synthesis tool was not instructed to put in logic to avoid or get out of lockout states.

Either enumerate the Illegal states and get the synthesis tool to build a regulare state machine

or

Get the synthesis tool to put the lockout state protection in. I'm not familiar with Leonardo, so someone else will have to suggest specific solutions.

Bob

---------------------------------------------------------------------

So, I was wondering if ignoring illegal states when using enumerated types is true for XST? That would explain at least some of my problems... Can I somehow force XST to make a state machine safe without manually coding all the states?

Thanks, /Mikhail

Reply to
MM
Loading thread data ...

The most likely reason for *getting* into an illegal state is missing input synchronization.

The most likely reason for *staying* in an illegal state is not covering all the state cases in your code.

Consider binary encoding.

-- Mike Treseler

Reply to
Mike Treseler

Understood...

That's what my original question was about. I do have a statement covering all other states: when others =>

fsm_reg

Reply to
MM

No. I mean change the synthesis seting from one-hot to binary.

Synthesis does not always cover the "others" case completely for one-hot encoding.

-- Mike Treseler

Reply to
Mike Treseler

Silly question but, is your design meeting timing? (how fast is the design in question?) Have you tried over constraining?

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian
 Click to see the full signature
Reply to
Martin Euredjian

I tried gray and it didn't help. I will try binary tomorrow, but I would like to know when XST covers the "others" case and when it doesn't....

/Mikhail

Reply to
MM

The design isn't really fast, only 50 MHz. The state machines in question are not on critical path. Overconstraining doesn't work well because of a big 3rd party core, which if overconstrained doesn't meet the timing at all. I think Mike is right and my problem is related to asynchronous inputs, but I still want to know more about how XST extracts state machines...

/Mikhail

Reply to
MM

You can apply a different set of constraints (tigher) just to the logic of your state machine while other parts of the design are governed by a (presumably) looser PERIOD constraint.

What you need to do is define FROM/TO constraints to the logic related to the state machine. The easiest way to do it might be to use the constraints editor and find all the FF's related to that module. It's pretty easy from there forward. The PERIOD constraint has the lowest priority of all, so FROM/TO will override it only for the specified logic.

So, you could have a PERIOD set to 20ns while FROM/TO is specified to 10ns.

Also, I forgot to ask. Does this happen during/around any reset signals? I suffered the pain of having one-hot state machines wake up in illegal states. Ultimately it was due to not handling reset properly and having FF's cleared/set at different times.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian
 Click to see the full signature
Reply to
Martin Euredjian

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.