[Partial reconfiguration] FSM-states after reconf.

Hi NG,

I have got a partial Design with different CAN-Modules to be partial
reconfigured. Most of the time the reconfiguration works quit flawlessly.
Anyway sometimes (unpredictable) the FSMs in my design stop.

In more courious tests i found out, that some FSMs enter two states at the same
time:
  (fsm_state = idle & fsm_state=error_frame) == true

Can anyone tell me if there is an initial fsm state after partial reconfiguration?
Any Xilinx-sources on this topic?

using: virtex-2 

-- 
best regards
    -- Fabian Schuh

Fabian,

Does your partial bitstream include the FSM registers?  If it does, it
will also contain initial conditions for these DFF.

There is also the question of reconfiguring while the design is
running:  if there is a block RAM in your design (BRAM), it only has
two ports that may be used simultaneously -- the configuration
interface can not be used while the BRAM is being clocked (it will
lead to data corruption in the BRAM).

The same may be true of the logic, in that the DFF used for the FSM
can not be clocked while you are reconfiguring if they get inputs from
the reconfigurable section, or are inside the reconfigurable section.

austin <austin@xilinx.com> schrieb:
> Fabian,
Hi Austin,

> Does your partial bitstream include the FSM registers?  If it does, it
> will also contain initial conditions for these DFF.
Yep, the partial bitstream contains more than 5 FSMs, all have initial states
defined in the declaration.

> There is also the question of reconfiguring while the design is
> running:  if there is a block RAM in your design (BRAM), it only has
> two ports that may be used simultaneously -- the configuration
> interface can not be used while the BRAM is being clocked (it will
> lead to data corruption in the BRAM).
Acctually we do reconfigure the running design. ATM we do not care about
corrupted data. The problem is, the FSMs do sometimes just stop after reconf.
and sometimes there continue running perfectly.

> The same may be true of the logic, in that the DFF used for the FSM
> can not be clocked while you are reconfiguring if they get inputs from
> the reconfigurable section, or are inside the reconfigurable section.
I do not completly understand what you mean. My FSMs are within the dynamic
part. the only connection between base/static part and dynamic part are FIFOs.

|---------|          |---------|
| Base    |->TXFIFO->| dynamic |
| design  |          | part    |
|         |<-RXFIFO<-| (FSMs)  |
|---------|          |---------|

-- 
best regards
    -- Fabian Schuh

Fabian Schuh <usenet@xeroc.org> wrote:
> austin <austin@xilinx.com> schrieb:
 
>> Does your partial bitstream include the FSM registers?  If it does, it
>> will also contain initial conditions for these DFF.

> Yep, the partial bitstream contains more than 5 FSMs, all have 
> initial states defined in the declaration.
(snip)
 
> Acctually we do reconfigure the running design. ATM we do not care about
> corrupted data. The problem is, the FSMs do sometimes just stop after reconf.
> and sometimes there continue running perfectly.

Make sure that you FSM can get out of any illegal state that
it happens to get itself into.  I presume you allow a sufficient
number of clock cycles after reconfiguration, but if the FSM is
stable in states that it isn't supposed to ever get to, then
no delay will be long enough.

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> schrieb:
> Make sure that you FSM can get out of any illegal state that
> it happens to get itself into.  I presume you allow a sufficient
> number of clock cycles after reconfiguration, but if the FSM is
> stable in states that it isn't supposed to ever get to, then
> no delay will be long enough.

Hi glen,
All my FSM do have the 
	----------------------
	when others=>
		state <= idle;
	----------------------
Is this enough? I thought so.

Just started implementing a wait counter to reset the FSM for some clockclycles
before starting the FSMs. Gonna test, if it helps.

Is there some good way to get an FSM into a defined state, if it runs into an
illegal one?

-- 
best regards
    -- Fabian Schuh

Fabian Schuh <usenet@xeroc.org> wrote:
< glen herrmannsfeldt <gah@ugcs.caltech.edu> schrieb:

<> Make sure that you FSM can get out of any illegal state that
<> it happens to get itself into.  I presume you allow a sufficient
<> number of clock cycles after reconfiguration, but if the FSM is
<> stable in states that it isn't supposed to ever get to, then
<> no delay will be long enough.

< All my FSM do have the 
<        ----------------------
<        when others=>
<                state <= idle;
<        ----------------------
< Is this enough? I thought so.

That sounds right to me.

Though that doesn't guarantee that it works in all legal states.  

Some years ago (should be fixed now) I ran into some tools that
internally converted my state machine to a 'one hot' form.
The problem was that I used the state counter in external logic.
The tools were supposed to recognize that, but missed it in
my case.  

-- glen 

On Oct 16, 6:45=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Fabian Schuh <use...@xeroc.org> wrote:
>
> < glen herrmannsfeldt <g...@ugcs.caltech.edu> schrieb:
>
> <> Make sure that you FSM can get out of any illegal state that
> <> it happens to get itself into. =A0I presume you allow a sufficient
> <> number of clock cycles after reconfiguration, but if the FSM is
> <> stable in states that it isn't supposed to ever get to, then
> <> no delay will be long enough.
>
> < All my FSM do have the
> < =A0 =A0 =A0 =A0----------------------
> < =A0 =A0 =A0 =A0when others=3D>
> < =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0state <=3D idle;
> < =A0 =A0 =A0 =A0----------------------
> < Is this enough? I thought so.
>
> That sounds right to me.
>
> Though that doesn't guarantee that it works in all legal states. =A0
>
> Some years ago (should be fixed now) I ran into some tools that
> internally converted my state machine to a 'one hot' form.
> The problem was that I used the state counter in external logic.
> The tools were supposed to recognize that, but missed it in
> my case. =A0
>
> -- glen

Xilinx XST ALWAYS encodes state machines one-hot unless you force
it to use your encoding (see synthesis options).  Are you sure
that your dynamic portion has a reset term for starting up the
FSM logic?  One of my favorite approaches is to add a post-reset
state that just continues onto the idle state.  Then when reset
is released all of the states other than idle cannot be reached
until the post-reset state has become inactive, effectively a
synchronous reset release.

Regards,
Gabor

Gabor <gabor@alacron.com> wrote:
(snip)
 
> Xilinx XST ALWAYS encodes state machines one-hot unless you force
> it to use your encoding (see synthesis options).  Are you sure
> that your dynamic portion has a reset term for starting up the
> FSM logic?  One of my favorite approaches is to add a post-reset
> state that just continues onto the idle state.  Then when reset
> is released all of the states other than idle cannot be reached
> until the post-reset state has become inactive, effectively a
> synchronous reset release.

If you use the state register somewhere else, such as a module
output, then it shouldn't convert to one hot.  (or it should
properly decode the one hot value.)

The bug was with Quartus many years ago, I believe fixed while
I was still working on that project.

It was a simple four state FSM to accept data one byte at a
time and output to a 32 bit FIFO.  The state variable was two
bits, and Quartus gave me the low two bits of the one hot register.

Do you mean XST will give you the wrong output in that case?

It seems that what Quartus expected was a case statement
to select the next state and a separate case statement to do
whatever you wanted to do in that state.  I wrote mine as
a single case statement and, in addition, used the state variable
outside the module.

-- glen

On 15 Okt., 10:30, Fabian Schuh <use...@xeroc.org> wrote:
> In more courious tests i found out, that some FSMs enter two states at th=
e same
> time:
> =A0 (fsm_state =3D idle & fsm_state=3Derror_frame) =3D=3D true

This is only possible, if your statemachine uses one-hot encoding. In
that case I would use some logic that recovers from illegal (unused)
states.

In a later post you ask, if a when-others statement in VHDL is
sufficient to obtain this function.
No that is unfortunately not the case for some synthesis tools. Some
tools inferring one-hot-fsm allow to select self recovering one-hot-
fsm. For other tools you need to figure out how to avoid this.

For some fsm it will be best practice to start cycling trough all
unused states before entering the usual idle state. This will force
the synthesis tool to cover every state and includes a dedicated way
to recover from "unused" states.

bye Thomas

On Oct 16, 6:36=A0am, Fabian Schuh <use...@xeroc.org> wrote:
> All my FSM do have the
> =A0 =A0 =A0 =A0 ----------------------
> =A0 =A0 =A0 =A0 when others=3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 state <=3D idle;
> =A0 =A0 =A0 =A0 ----------------------
> Is this enough? I thought so.
>

That's tool dependent.  Check for some synthesis option that says
something about implementing safe state machines.  It can add
additional logic to use that option.  This would only be a band-aid to
fix a symptom, not a fix to the problem.

> Just started implementing a wait counter to reset the FSM for some clockc=
lycles
> before starting the FSMs. Gonna test, if it helps.
>

My guess is that it will fix the problem since it sounds like you're
not resetting the FSM when it comes alive.  Unless your system clock
is synchronized with the end of configuration, you'll have no way of
guaranteeing that you meet setup time requirements on the very first
clock cycle after coming out of configuration.  I also wouldn't
implement the 'wait counter' as a counter if it is in the logic that
is getting reconfigured, since you can't guarantee meeting setup
requirements on that counter when configuration ends either.  The way
to do this is with a shift register.  You can still violate setup time
on the input to the first stage but it will propogate through.  Your
newly configured logic can be considered alive and well by the stuff
that has not been reconfigured once you see two consecutive 'not
resets' coming out of the shift register (consider using a shift
register of 3-4 stages or so).  That way the new logic gets reset
properly, and the other logic knows when things are really alive.

The shift register reset after configuration is not unique to partial
configuration, it should be a part of every design.

> Is there some good way to get an FSM into a defined state, if it runs int=
o an
> illegal one?
>

The illegal state is just a symptom of the problem.  The problem is
(most likely) not meeting timing requirements (the other possibility
is inadequate power to the chip).  The correct solution fixes the
problem, not the symptom.

Kevin Jennings