Safe state machine design problem

M

MM

Guest
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 (rluking@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
 
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)
Click to expand...
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" <mike.treseler@flukenetworks.com> wrote in message
news:3F7C88A2.7040200@flukenetworks.com...
The most likely reason for *getting* into an illegal state
is missing input synchronization.
Click to expand...
Understood...

The most likely reason for *staying* in an illegal state
is not covering all the state cases in your code.
Click to expand...
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.
Click to expand...
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?
Click to expand...
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:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"




"MM" <mbmsv@yahoo.com> wrote in message
news:blhqhd$cijqt$1@ID-204311.news.uni-berlin.de...
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 (rluking@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
Click to expand...
 
"Mike Treseler" <mike.treseler@flukenetworks.com> wrote in message
news:3F7C9A79.8090106@flukenetworks.com...
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.
Click to expand...
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" <0_0_0_0_@pacbell.net> wrote in message
news:pi5fb.8964$5P7.7307@newssvr27.news.prodigy.com...
Silly question but, is your design meeting timing? (how fast is the design
in question?)
Have you tried over constraining?
Click to expand...
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:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"



"MM" <mbmsv@yahoo.com> wrote in message
news:blivi5$ckn15$1@ID-204311.news.uni-berlin.de...
"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
news:pi5fb.8964$5P7.7307@newssvr27.news.prodigy.com...
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
Click to expand...
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top