FSM in illegal state

[rickman]

"Jerker Hammarberg (DST)" wrote:

Hi Jim!

Do LOOK at the resultant output of your tools, and HOW it actually
built the FSM. It can use .D or .T registers, with .D the most common.

Well, the output netlist isn't exactly human-readable, although I guess
I could write a simple FSM, synthesize it and study it. But actually I
already know how XST has encoded my machine. My options are essentially
One-Hot, Compact (binary), Sequential, Gray, and Johnson, all presumably
on D flip-flops. I get One-Hot encoded machines unless i ask for
something else.

However, correct me if I'm wrong, the state encoding itself doesn't
change anything in the machine's ability to recover from illegal states
- it takes some logic that detects these illegal states and forces the
state vector back to normal, and that logic obviously isn't there. Many
synthesis tools provide an extra option "safe FSMs" which will add such
logic, but XST doesn't. So my question is XST-specific - how do I add
illegal state recovery logic with XST?

One other thing you can do is to add the logic manually. If you are
using an enumerated data type, you can get the encoded value. Write
your own logic on this state value and detect the illegal combinations.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Jerker Hammarberg (DST)]

Hi Philip, and thank you for your enlightening and extensive reply!

From reading your various postings, I believe the summary is:

You have a state machine.
It gets into illegal states.
It does it about 1 out of 10 times on startup.
You do not have an async reset to the FSM.
Your async inputs to the state machine go through a single flipflop.
You are investigating ways of detecting illegal states and want to get
back to a valid state.
You specify initial values (in VHDL).
Your static timing analysis indicates no problems.
Your clock frequency is 20MHz.

Right, I should say that this design with 20MHz and 1 out of 10 failure
rate is just one of several designs that I have problems with. I don't
only want to solve the problem for that particular one design; I want to
learn as much as possible about this issue, so that I can solve the
problem for all my designs and avoid it in the future.

For that 20MHz design, I could add that it doesn't seem to happen when
the board's power supply is less loaded. Considering that it almost
always happens on startup, when components all over the board need a lot
of current, I suspect it might have something to do with voltage dips.
But I don't see why that would only result in a state machine hanging; I
would expect to see more diverse errors. Whatsoever I will examine the
voltage curve on powerup.

If you want to learn more about metastability, this is my favorite
URL:
http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm

Even though your problem is not metastability, once your current
problem is fixed, the much rarer problem of metastability may cause
problems. A double synchronizer on all your async inputs is cheap
insurance.

I actually read the faq before posting, like a good newsgroup poster
should do! I will add a second synchronizer, but it hurts a little,
because one of the inputs is an SPI clock and the FPGA is supposed to
react as fast as possible on its edges.

You wrote: "I doubt that it's about static timing in my case since my
clock is 20 MHz, and XST's post-layout static timing analysis doesn't
complain."

Your assertion that static timing analysis indicates that there are no
problems is insufficient. I have seen far too many designs by engineer
that proudly show the static timing report showing that there are no
errors, but they have not generated the "unconstrained paths" report.
The static timing analyzer tells you that of the paths you have
constrained, these all meet timing, but the delay on the unconstrained
paths is unbounded. You need to identify all unconstrained paths and
either be able to explain why they dont need a timing constraint (such
as a push button input), or add constraints so that the paths are
covered.

I have to admit I haven't cared much about static timing, since I
believed that if I specify a clock period constraint, all FF to FF paths
would be constrained by this time, and that's all I need in a completely
synchronous design. Is that wrong? Anyway, I realize that I need to
learn more about timing... or finally tell my boss I shouldn't be doing
FPGA design without proper education.

I will check the unconstrained paths, but I expect to find only input to
FF and FF to output paths. I don't care about output delay since they
are only connected to leds and SPI units working at a considerably
slower rate. In particular, these paths can't affect my state machines.
And the inputs can arrive anytime anyway. Would you agree that given
this, I could rule out timing issues (apart from the following)?

Phil Hays' quote above is almost certainly identifying your problem,
and gives a fine solution. Let me expand on it. The problem is that
when the chip goes active, you have logic signals that go into the
state machine that cause it to transition to a next state immediately.
Since the going active is asynchronous to the 20MHz clock, you may
have anywhere from 50 to 0 ns to do this. This represents a race
condition (not a metastability), and in 10% of your startups, you lose
the race. As others have described, not all parts of the state machine
have enough time (when the available time is less than 50 ns) to
transition to the next valid state. Phil's (and Philip's) solution is
to hold off the first transitions of the state machine until a few
cycles after the chip goes active. Phil's solution suggests 15 cycles,
probably anything over 4 would be rock solid. As an example, I usually
use a 4 bit shift register to do this. Either way, it works like this:

This was totally new to me. I take it ALL state machines that may
transition on the first clock pulse need this kind of protection.

Thanks again, Philip (and Phil)!

/Jerker

 

[Jerker Hammarberg (DST)]

One other thing you can do is to add the logic manually. If you are
using an enumerated data type, you can get the encoded value. Write
your own logic on this state value and detect the illegal
combinations.

I'm not so sure... again, XST finds all unreachable states and takes
away the logic for them, even states that are legal and have their own
"when" clause. I've even seen in another thread on comp.lang.vhdl the
suggestion to connect an input pin to ground, then add code to the state
machine like

if ground_signal = '1' then
state <= UNREACHABLE_STATE;
end if;

just to prevent XST from taking away the logic for UNREACHABLE_STATE.
But I was hoping there were better solutions...

/Jerker

 

[Jerker Hammarberg (DST)]

That depends entirely on your timing specs. If you have none, then
they are not likely to be wrong XST will be trying to make every
path meet single clock timing.

Sure! I have specified a clock period constraint, which I thought would
be enough. See further my reply to Philip.

As others have suggested, if it fails on startup, it could easily be
the async reset vs. clock. I think you made two bad assumptions from
the way you describe your initial state. You indicated you used
"initial values by declarations". I don't think synthesis tools use
initial values as reset values. I have never asked if XST does this
or not since I don't depend on this. Accepted style is to put it
explicitly in your hdl code like this...

But this is a well documented feature in XST, see XST User guide,
Chapter 6, Initial Values. It says "When you give a register an initial
value in a declaration, XST sets this value on the output of the
register at global reset, or at power up.". So if the feature is there,
it must be OK to use it, and to skip explicit resets?

/Jerker

 

[Jerker Hammarberg (DST)]

Or maybe you mean I should add separate logic outside of the state
machine? That could work... I'll try that.

/Jerker

 

[Jim Granville]

Jerker Hammarberg (DST) wrote:

Each valid state will have a number of hold-until-next-move-true terms,
but states not covered will have NO .D terms, and so their NEXT state is
Q0.D = 0;
Q1.D = 0;
or to the 00 state.

If you code
IF State=11 THEN immediate_next = 00, then no more logic is generated,
as that is implicit.


All right, NOW I see your point! But it seems to me you're assuming that the
synthesis tool always generates the transition logic such that illegal
states always transition to the state vector of all zeroes, and I'm not yet
convinced that this is the case. I would have believed that the transition
function would map all illegal states to "Don't care", allowing the tool to
minimize the transition logic. As a consequence, the illegal states could
transition to anyting, including the same illegal state, which means it's
stuck. But I will try to investigate how XST generates the transition logic.
If you're right, you definitely answered my question no 2.

/Jerker
paste
I'm not so sure... again, XST finds all unreachable states and takes away the logic for them, even states that are legal and have their own "when" clause. I've even seen in another thread on comp.lang.vhdl the suggestion to connect an input pin to ground, then add code to the state machine like

if ground_signal = '1' then
state <= UNREACHABLE_STATE;
end if;

just to prevent XST from taking away the logic for UNREACHABLE_STATE. But I was hoping there were better solutions...

/Jerker

To solve any reliance on 'what xxxx tools might choose to do', the best
solution is to code
ELSE
state <= Enumerated_0000_State;

Normally, that should have zero additional hardware logic cost [except
for one-hot], ( because it is implicit in the .D construction), but now
you are more certain you and the tools 'are on the same page'.
I would try to avoid trying to add logic outside the state
expressions, as there you are again on thin-ice, with tool dependance.

-jg

 

[Duane Clark]

rickman wrote:

If this were true, then you would never need to specify that you are
using one-hot encoding. The states that are not used would be detected
as not needing to be decoded and the logic would automatically minimize
to just using one bit to represent each state...

Yes, I am talking about one-hot encoding. Where I have seen the problem
is on power when, for whatever reason, none of the states are selected.
In that case, the state machine is dead.

Where have you seen that a tool will optimize away the others clause?

Xilinx XST.

--
My real email is akamail.com@dclark (or something like that).

 

[Duane Clark]

Duane Clark wrote:

Yes, I am talking about one-hot encoding. Where I have seen the problem
is on power...

Uggh, that should say power-on.

--
My real email is akamail.com@dclark (or something like that).

 

[Hal Murray]

Right, I should say that this design with 20MHz and 1 out of 10 failure
rate is just one of several designs that I have problems with. I don't
only want to solve the problem for that particular one design; I want to
learn as much as possible about this issue, so that I can solve the
problem for all my designs and avoid it in the future.

Everything I've seen so far points to troubles with the initial
state and the first transition - the time when reset during
configuration goes away.

The basic problem you have to understand is that the global
reset signal is asynchronous. The next problem is that much
of the software doesn't beat you over the head with that
fact. (Every FF in the chip has this problem. Mostly we
just ignore it and get away with it.)

FPGAs work well with one-hot state machines. But if you use
that encoding, then it takes a lot of logic to detect an
invalid state. If you want to detect invalid states, it's
probably less total logic to use a denser encoding. It's
free if you use a ROM. At slow speeds with 16 or fewer states,
a binary encoding may be fine.

So the other approach is to avoid getting into invalid states.
The first key step is to make sure that all your normal logic
inputs meet setup/hold times. Metastability comes in here.

My rule of thumb is to use 2 FFs (costs a whole cycle) so
I don't have to think about it. Well, you actually do have to think
about it - they must be near eachother. If the placer puts them
on opposite sides of the chip the routing delay can cause problems.
You should be able to avoid that with timing constraints.

If you don't want to wait that extra clock cycle then you have to
think carefully. At 20 MHz with a modern chip it should be easy.
Check the app notes and such.

Now all that's left is that pesky initial reset.

If your state machine starts in state IDLE and stays there until
some external event comes along then you are probably safe with no
extra logic. You just have to make sure that no "event" happens
until several clocks after initialization. Many times that
happens for free.

If your events do happen early, you can add a simple state machine
to mask them for a few cycles. You get that right by inspection -
that is you design it as logic rather than a FSM.

Some state machines start off running, for example to generate
a pattern of constantly running timing pulses. You can make them
safe by modifying them to wait for an artifical event. If you feed
in an event of "1", things reduce to the previous paragraph.

For a simple one-hot encoding that starts off running, you can
detect the illegal states that result when things go wrong without
a lot of logic. That is don't catch all illegal states, just the
ones that can happen due to asynchronous reset troubles.

This has been an interesting discussion. Seems like good bait
for an app-note.

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

 

[rickman]

"Jerker Hammarberg (DST)" wrote:

That depends entirely on your timing specs. If you have none, then
they are not likely to be wrong XST will be trying to make every
path meet single clock timing.

Sure! I have specified a clock period constraint, which I thought would
be enough. See further my reply to Philip.

As others have suggested, if it fails on startup, it could easily be
the async reset vs. clock. I think you made two bad assumptions from
the way you describe your initial state. You indicated you used
"initial values by declarations". I don't think synthesis tools use
initial values as reset values. I have never asked if XST does this
or not since I don't depend on this. Accepted style is to put it
explicitly in your hdl code like this...

But this is a well documented feature in XST, see XST User guide,
Chapter 6, Initial Values. It says "When you give a register an initial
value in a declaration, XST sets this value on the output of the
register at global reset, or at power up.". So if the feature is there,
it must be OK to use it, and to skip explicit resets?

Ok, if you are sure this works for XST, then that is ok. But it won't
work with other synthesis tools which will make your code not portable.
If you later want to use a better tool, you will have to go back and use
the standard method on every signal you are initializing.

Either way, if it is being reset, then that is covered. But this does
not necessarily mean it will come out of reset correctly. Since the
clock is async with respect to the reset, and the reset has variable
delays throughout the chip, you can release reset on different parts of
the chip (including different FFs in the same state machine) on
different clock cycles.

One way to fix this is to make sure the global reset path delay is less
than one clock cycle and to sync the reset to the global clock. I
believe there is a config bit stream option to synchonize the end of
reset with your global clock. Check the docs. This is something you
will set when you generate the bit stream. I am not sure how to find
out how long the reset delay paths are.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[DrB]

Phil

Your allusion to "common" DCM / DLL issues has aroused my curiosity.

Could you elucidate please.

Martin


"Phil Hays" <Spampostmaster@comcast.net> wrote in message
news:imsoe05ptq3h66j0m4t0ha1dqsdrure8j3@4ax.com...

"Jerker Hammarberg (DST)" <jerkerNO@SPAMdst.se> wrote:

How is the reset signal handled? If the FFs are asynchronously reset,
then the end of reset can happen at different times to different FFs,
leading to an illegal state.

Hi Phil! I use no reset signal at all; instead I specify initial values
for all signals by the declarations, which is supposed to work fine with
XST.

You do have an asynchronous reset, you just didn't know that you did.
When a Xilinx FPGA finishes the program download, it has all initial
values held until an internal signal is released. This release is
asynchronous to your clock. To avoid problems with this add a counter
that is reset to all zeros. Until that counter counts to 15, keep the
state machine in the initial state.

(Note: Startup is a messy subject. This is a simplified version.)

There is another common issue with DCMs or DLLs that you might also be
having a problem with. Are you using a DCM or a DLL?


But your point is still interesting in case I would need to
introduce an asynchronous reset some day. Does that mean one should
avoid them if illegal states are a concern?

Yes. Suppose the initial state is "100" and the desired next state is
"010". This would be a three state one-hot machine.
If the first bit is held until just after the first edge of the clock
and the second bit is held until just before the first edge of the
clock, then the next state will be illegal, "110".
If the first bit is held until just before the first edge of clock and
the second bit is held until just after the first edge of the clock,
then the next state will be illegal, "000".

Does that make it clear?


--
Phil Hays
Phil-hays at posting domain should work for email

 

[Phil Hays]

On Mon, 12 Jul 2004 10:26:21 +0100, "DrB" <nospam@nospam.no> wrote:

There is another common issue with DCMs or DLLs that you might also be
having a problem with. Are you using a DCM or a DLL?

Your allusion to "common" DCM / DLL issues has aroused my curiosity.

Sure. I'm not sure "common" was the correct word, but I suspected
that the original poster might have run into the following issue.
I've seen it in someone else's design. These problems are curable by
reading the fine manual (RTFM).

RTFM # 1 "Do not use the DCM output clock signals until after
activation of the LOCKED signal. Prior to the activation of the LOCKED
signal, the DCM output clocks are not valid and can exhibit glitches,
spikes, or other spurious movement."

You can keep the part in configuration until the DCMs are locked by a
bitgen option, or you can use the synchronized locked signal to force
reset to all state machines and all other critical logic. Better do
one of the two. The bitgen option is probably best, unless you may be
resetting the DCMs after configuration, in which case you need to do
the second.


I didn't think he had this issue, but I've seen it as well. In my own
design.

RTFM # 2 "To ensure consistent locking, if a DCM is configured with
external feedback, applying a reset after configuration is strongly
recommended."

"Strongly recommended" isn't quite correct. "Required" would be
better wording.


--
Phil Hays
Phil-hays at posting domain should work for email

 

[DrB]

Phil

Thank you for the dits

If only one could RTFM (Read The Full Manual) - it never seems to get
published these days

An F* problem in its own right; but fore warned is fore armed

Martin


"Phil Hays" <Spampostmaster@comcast.net> wrote in message
news:av25f0psef0joqr911kraedr7rbdco8q4d@4ax.com...

On Mon, 12 Jul 2004 10:26:21 +0100, "DrB" <nospam@nospam.no> wrote:

There is another common issue with DCMs or DLLs that you might also be
having a problem with. Are you using a DCM or a DLL?

Your allusion to "common" DCM / DLL issues has aroused my curiosity.

Sure. I'm not sure "common" was the correct word, but I suspected
that the original poster might have run into the following issue.
I've seen it in someone else's design. These problems are curable by
reading the fine manual (RTFM).

RTFM # 1 "Do not use the DCM output clock signals until after
activation of the LOCKED signal. Prior to the activation of the LOCKED
signal, the DCM output clocks are not valid and can exhibit glitches,
spikes, or other spurious movement."

You can keep the part in configuration until the DCMs are locked by a
bitgen option, or you can use the synchronized locked signal to force
reset to all state machines and all other critical logic. Better do
one of the two. The bitgen option is probably best, unless you may be
resetting the DCMs after configuration, in which case you need to do
the second.


I didn't think he had this issue, but I've seen it as well. In my own
design.

RTFM # 2 "To ensure consistent locking, if a DCM is configured with
external feedback, applying a reset after configuration is strongly
recommended."

"Strongly recommended" isn't quite correct. "Required" would be
better wording.


--
Phil Hays
Phil-hays at posting domain should work for email

 

[Jerker Hammarberg (DST)]

I have now implemented the protection against race condition as a result of
asynchronous reset, as proposed by Phil and others. The machine hasn't
locked after that, so hopefully that was the solution.

I learnt a lot through this discussion. Thanks a lot to all who contributed!

/Jerker

 

[Peter Alfke]

A Xilinx App Note was suggested. Here is an attempt.
Let me know if it makes sense.

Beware of Start-Up Synchronization Errors
Peter Alfke, July 12, 2004

All Xilinx FPGAs provide global (p)reset to all internal flip-flops and
latches, which means that every flip-flop is either set or cleared
(configuration option) when the FPGA goes active after configuration has
been completed. This attractive feature requires no general routing
resources. It is łfor free˛, but like with many łfree˛ offers, there can be
strange side effects.

€ The (p)reset signal is distributed across the whole chip, and it is not
very fast. Tens of nanoseconds delay are common on large chips.
€ The (p)reset signal is synchronous with either CCLK or, better, with the
user clock, but there may be more than one user clock.
€ The user clock is normally running while the FPGA is being configured.
This is only tolerable because flip-flops are being held (p)reset, nodes are
forced High, and outputs are being held inactive, as described in the
configuration documentation.

These three features combined can cause unreliable start-up after
configuration, when the trailing edge of the asynchronous (p)reset signal
has so much skew or uncertainty with respect to any flip-flop clock, that
some flip-flops can begin operating on different clock cycles. This might
lead to an irrelevant start-up glitch, but it might also cause a state
machine to enter an illegal state, or even to freeze up.

There are several alternate solutions to this problem.

1.
Disable all clocking until about 100 ns after the end of GSR, the automatic
global signal that asynchronously (p)resets all flip-flops.

2.
Distribute a synchronous CE (clock disable) signal with a tight distribution
delay of less than one clock period.

3.
Analyze the design for sensitive circuitry, e.g. state machines, and create
a localized synchronous CE signal that delays operation for several clock
cycles after the end of GSR.

A convenient reset synchronizer and stretcher consists of a flip-flop with
the usual GSR reset, with a High on its D input, and with its Q output
driving the SRL16 input to its own LUT. The SRL16 output then goes High a
controlled number of clock pulses after the end of GSR. This is a good
signal to use for driving the CE input of critical state machines.

Ken Chapman published a longer and more entertaining description in
TechXclusives.
Click on this insanely long URL:

http://support.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=&sSeco
ndaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=kc_smart_reset


Peter Alfke

From: "Jerker Hammarberg \(DST\)" <jerkerNO@SPAMdst.se
Organization: DST Control AB
Newsgroups: comp.arch.fpga,comp.lang.vhdl
Date: Tue, 13 Jul 2004 18:14:14 +0200
Subject: Re: FSM in illegal state (conclusion)

I have now implemented the protection against race condition as a result of
asynchronous reset, as proposed by Phil and others. The machine hasn't
locked after that, so hopefully that was the solution.

I learnt a lot through this discussion. Thanks a lot to all who contributed!

/Jerker

 

[Jim Lewis]

Peter,
Since the Xilinx parts have internal POR, it seems a
shame not to use it. However, since GSR is slow, we
are cautioned against using it due to problems like
these.

Is there a way to connect the output of GSR to the
input of the circuit that Ken Chapman suggested in
the section "Strategy for the 0.01% of cases" of his
TechXclusive and leave off the asynchronous reset input.
Would this be a way that I can effectively cause all of
resets (or critical resets) for a clock domain to be
deasserted at the same time without having to
have a redundant external POR?

If this is possible, is there a VHDL coding methodology
that you can recommend? The big missing piece for me
is how do I access the output of GSR?
#1: Explicitly through instantiation?
#2: Implicitly through initializing the VHDL
signals that create the registers?
Although this technique seems possible in XST,
would it also work the same in other synthesis tools?
#3: Put the reset logic in a separate hierarchical
block and explicitly code an asynchronous reset, but
at the next level of the design tie the asynchronous
reset to a constant inactive value?


If I have multiple FPGAs and they are all connected
in a serial fashion for configuration, is the internal
POR released at approximately the same time?

The details of POR and GSR functionality has always been a
little troubling to me, is there a good (really detailed)
application note that you can recommend.

Regards,
Jim Lewis
SynthWorks VHDL Training

Ken Chapman published a longer and more entertaining description in
TechXclusives.
Click on this insanely long URL:

http://support.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=&sSeco
ndaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=kc_smart_reset

A Xilinx App Note was suggested. Here is an attempt.
Let me know if it makes sense.

Beware of Start-Up Synchronization Errors
Peter Alfke, July 12, 2004

All Xilinx FPGAs provide global (p)reset to all internal flip-flops and
latches, which means that every flip-flop is either set or cleared
(configuration option) when the FPGA goes active after configuration has
been completed. This attractive feature requires no general routing
resources. It is łfor free˛, but like with many łfree˛ offers, there can be
strange side effects.

€ The (p)reset signal is distributed across the whole chip, and it is not
very fast. Tens of nanoseconds delay are common on large chips.
€ The (p)reset signal is synchronous with either CCLK or, better, with the
user clock, but there may be more than one user clock.
€ The user clock is normally running while the FPGA is being configured.
This is only tolerable because flip-flops are being held (p)reset, nodes are
forced High, and outputs are being held inactive, as described in the
configuration documentation.

These three features combined can cause unreliable start-up after
configuration, when the trailing edge of the asynchronous (p)reset signal
has so much skew or uncertainty with respect to any flip-flop clock, that
some flip-flops can begin operating on different clock cycles. This might
lead to an irrelevant start-up glitch, but it might also cause a state
machine to enter an illegal state, or even to freeze up.

There are several alternate solutions to this problem.

1.
Disable all clocking until about 100 ns after the end of GSR, the automatic
global signal that asynchronously (p)resets all flip-flops.

2.
Distribute a synchronous CE (clock disable) signal with a tight distribution
delay of less than one clock period.

3.
Analyze the design for sensitive circuitry, e.g. state machines, and create
a localized synchronous CE signal that delays operation for several clock
cycles after the end of GSR.

A convenient reset synchronizer and stretcher consists of a flip-flop with
the usual GSR reset, with a High on its D input, and with its Q output
driving the SRL16 input to its own LUT. The SRL16 output then goes High a
controlled number of clock pulses after the end of GSR. This is a good
signal to use for driving the CE input of critical state machines.

Ken Chapman published a longer and more entertaining description in
TechXclusives.
Click on this insanely long URL:

http://support.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=&sSeco
ndaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=kc_smart_reset


Peter Alfke






From: "Jerker Hammarberg \(DST\)" <jerkerNO@SPAMdst.se
Organization: DST Control AB
Newsgroups: comp.arch.fpga,comp.lang.vhdl
Date: Tue, 13 Jul 2004 18:14:14 +0200
Subject: Re: FSM in illegal state (conclusion)

I have now implemented the protection against race condition as a result of
asynchronous reset, as proposed by Phil and others. The machine hasn't
locked after that, so hopefully that was the solution.

I learnt a lot through this discussion. Thanks a lot to all who contributed!

/Jerker

 

[Hal Murray]

A Xilinx App Note was suggested. Here is an attempt.
Let me know if it makes sense.

I think your summary was good, but I also think I understand
the problem. (I got bit years ago. It's one of my hot buttons.)
The real question is how to get this problem on every designer's
mental checklist so that they are thinking about it at the right time.

My request for an app-note was actually misleading. I should have
asked for support in the tools. They should be smart enough to
complain about state machines that don't have some mechanism to
come out of reset cleanly.

What do ASIC/CPU designers do? My guess is that they don't
have a global-reset so their version of this problem is a bit
different.

This seems like a good open source project. Or maybe a masters
thesis. All the info is in the EDIF/netlist. Right?

Is the GSR in the netlist? Or would a tool have to add it
by magic?


Ken's TechXclusive article is good. Thanks.

It actually doesn't cover the mechanism I think I would try to
use. He holds the whole state machine in reset. That chews up
local resources. Many FSMs stay in the idle state until they get
poked, for example a memory controller waits for a read or
write request. I was thinking of blocking that sort of
request signal.

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

 

[Jim Lewis]

Hal,

What do ASIC/CPU designers do? My guess is that they don't
have a global-reset so their version of this problem is a bit
different.
In ASIC design, we would connect the asynchronous reset to the

circuit Ken showed (or one like it). Reset for each clock
domain is separately synchronized. Reset would need to settle
in a clock period. Routing generally allows this. If not,
you work it out (build a fanout tree with buffers or
registers). Going back some time, on my first ASIC we had
to manually balance the clock tree.

See my post. GSR would be generally alot more useful if
we could quantify in general that it settles in X to Y
amount of time and then apply its output to a circuit like
the one Ken shows to stabilize all logic or all control
logic. From the difference between Y and X we could calculate
how many states we needed to delay "critical" reset so that
it occurs last. Four registers is kind of ad-hoc and means
something much different for different clocks (20 MHZ vs
200MHZ).

Of course, going a step further, since synthesis tools can
and do recognize statemachines, and they know the clock
frequency of a particular clock, they could automatically
do the right thing for Xilinx (insert Ken's circuit).
However I like being in control of these type of things
and I am not sure I would like this solution.


Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[rickman]

Jim Lewis wrote:

Peter,
Since the Xilinx parts have internal POR, it seems a
shame not to use it. However, since GSR is slow, we
are cautioned against using it due to problems like
these.

I don't think the problem with GSR synchronization equals a
recommendation to not use the GSR. The point is to use it with
"caution" and to take the appropiate design steps.

Is there a way to connect the output of GSR to the
input of the circuit that Ken Chapman suggested in
the section "Strategy for the 0.01% of cases" of his
TechXclusive and leave off the asynchronous reset input.
Would this be a way that I can effectively cause all of
resets (or critical resets) for a clock domain to be
deasserted at the same time without having to
have a redundant external POR?

Reread Peter's post. It is a good start and I think you misunderstood
some of the points in it. You don't need an external reset and most
likely you don't need a sync reset that is "global" to a clock domain.
Typically there are subsets of the design which are sensitive to
synchronous release of GSR. These circuits are typically FSM, counters
and the like. Normally the data path does not care about reset since it
will immediately go to the correct state on the next clock.

One circuit you can add to any FSM to provide a sync reset is just one
or a pair of FFs which work just like a metastability reduction
circuit. Have the GSR hold these FFs in the '1' state and wire the D
input of the first one to a '0'. The last output will be your sync
reset. The sync reset will be held for one or two clock edges after the
release of GSR. This will only need to be used by the first two bits of
a one-hot FSM, the first changed bit of a gray coded counter, the first
bit of a JRC or even the first bit of a binary counter (assuming it
starts at 0); and so will not overly complicate them and slow them
down.

I have done lots of FPGA designs and have never needed anything complex
to start the chip up. Just pay attention to the startup and don't
assume that all FFs are released at the same time, between FSMs, not
just within them.

If this is possible, is there a VHDL coding methodology
that you can recommend? The big missing piece for me
is how do I access the output of GSR?

This is something that should be added to Peter's app note.

#1: Explicitly through instantiation?
#2: Implicitly through initializing the VHDL
signals that create the registers?
Although this technique seems possible in XST,
would it also work the same in other synthesis tools?
#3: Put the reset logic in a separate hierarchical
block and explicitly code an asynchronous reset, but
at the next level of the design tie the asynchronous
reset to a constant inactive value?

You don't need to access the GSR signal explicitly. If you provide an
async reset control that is common to most/all of your sequential logic,
I believe the tools will infer the GSR.

run_en_reg: PROCESS (sysclk, reset) BEGIN
IF (reset = '1') THEN
run_en <= '0';
ELSIF (rising_edge(sysclk)) then
run_en <= '1';
END IF;
END PROCESS;

This is what I use. But I only refer to the run_en signal in the FFs
that actually need to be released synchronously.

If I have multiple FPGAs and they are all connected
in a serial fashion for configuration, is the internal
POR released at approximately the same time?

Approximate is the key word. There is a common sync signal to provide
this, but you still have the wide range of delay inside each chip and
you need to select what clock is used to control it.

The details of POR and GSR functionality has always been a
little troubling to me, is there a good (really detailed)
application note that you can recommend.

You can learn a lot about it by reading how the end of configuration
works. But the main thing is to stop assuming that the end of GSR is a
synchronous event. On other chips we get used to the reset just working
(like magic). In the FPGA we need to give it a little thought, even if
it is not really hard.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Jim Lewis]

Rick,

These circuits are typically FSM, counters and the like.
Normally the data path does not care about reset since it
will immediately go to the correct state on the next clock.
I am a former ASIC designer. I think I understand this

part well. I do have a couple concerns. First I want a
reset methodology that is device independent and
simulates well for any ASIC or FPGA technology not
just specific to Xilinx. Hence, everything that requires
reset will need the synchronized reset. I agree most
data path does not need reset (except for on some ASIC designs
to get the device to pass vectors more easily on the tester).

My second concern is that selective reset is not for
everyone. For some this methodology will cause chaos.
For a design review with selective reset, this is just
one more item that needs to be reviewed in detail.

One circuit you can add to any FSM to provide a sync reset is just one
or a pair of FFs which work just like a metastability reduction
circuit. Have the GSR hold these FFs in the '1' state and wire the D
input of the first one to a '0'. The last output will be your sync
reset. The sync reset will be held for one or two clock edges after the
release of GSR. This will only need to be used by the first two bits of
a one-hot FSM, the first changed bit of a gray coded counter, the first
bit of a JRC or even the first bit of a binary counter (assuming it
starts at 0); and so will not overly complicate them and slow them
down.
To me this seems like Chaos**n. Not that it will not work,

it just adds more details you need to manage.

This methodology would have to buy me something significant
(speed or device size) for me to want to do additional
analysis and verification to prove that a circuit designed
as above actually works under all conditions.

If this is possible, is there a VHDL coding methodology
that you can recommend? The big missing piece for me
is how do I access the output of GSR?


This is something that should be added to Peter's app note.


#1: Explicitly through instantiation?
#2: Implicitly through initializing the VHDL
signals that create the registers?
Although this technique seems possible in XST,
would it also work the same in other synthesis tools?
#3: Put the reset logic in a separate hierarchical
block and explicitly code an asynchronous reset, but
at the next level of the design tie the asynchronous
reset to a constant inactive value?


You don't need to access the GSR signal explicitly. If you provide an
async reset control that is common to most/all of your sequential logic,
I believe the tools will infer the GSR.

run_en_reg: PROCESS (sysclk, reset) BEGIN
IF (reset = '1') THEN
run_en <= '0';
ELSIF (rising_edge(sysclk)) then
run_en <= '1';
END IF;
END PROCESS;

This sounds like it would address my needs nicely.
What do you connect reset to? Do you just leave
it floating? What do you do with it in simulation?

If there is something here that would work with
XST, Synplicity, and Mentor, without changing the
code, this would make me happy. Especially if
the only thing I needed to change for each FPGA/ASIC
technology is the reset block and where the power-on
reset comes from.

You can learn a lot about it by reading how the end of configuration
works. But the main thing is to stop assuming that the end of GSR is a
synchronous event. On other chips we get used to the reset just working
(like magic). In the FPGA we need to give it a little thought, even if
it is not really hard.
On ASICs reset is explicit. On your flow above with Xilinx,

I code reset on the register, hook it to ?? or leave it
unconnected, and then "magically" it gets connected to GSR.

Is there a datasheet, manual, or appnote you recommend reading
on configuration.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~