FPGA Central

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 ([email protected])
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

MM wrote:

> 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)

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

"Mike Treseler" <[email protected]> wrote in message
news:[email protected]..
> The most likely reason for *getting* into an illegal state
> is missing input synchronization.

Understood...

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

That's what my original question was about. I do have a statement covering
all other states:
when others =>
fsm_reg <= idle;
however it doesn't seem to do anything...

> Consider binary encoding.

You mean manual?

Thanks,
/Mikhail

MM wrote:

> That's what my original question was about. I do have a statement covering
> all other states:
> when others =>
> fsm_reg <= idle;
> however it doesn't seem to do anything...
>
>>Consider binary encoding.
>
> You mean manual?

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

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


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
[email protected]
where
"0_0_0_0_" = "martineu"




"MM" <[email protected]> wrote in message
news:blhqhd$cijqt$[email protected]..
> 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 ([email protected])
> 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
>
>

"Mike Treseler" <[email protected]> wrote in message
news:[email protected]..
> 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.

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

"Martin Euredjian" <[email protected]> wrote in message
newsi5fb.8964$[email protected] m...
> Silly question but, is your design meeting timing? (how fast is the design
> in question?)
> Have you tried over constraining?

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

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

To send private email:
[email protected]
where
"0_0_0_0_" = "martineu"



"MM" <[email protected]> wrote in message
news:blivi5$ckn15$[email protected]..
> "Martin Euredjian" <[email protected]> wrote in message
> newsi5fb.8964$[email protected] m...
> > Silly question but, is your design meeting timing? (how fast is the
design
> > in question?)
> > Have you tried over constraining?
>
> 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
>
>