How do they handle shorts during the dynamic reconfiguration

[valtih1978]

Normally, the tools check that there are no driver conflicts during
synthesis and shut down all drivers when start the configuration. Yet,
one and the same line can be driven by different drivers in different
designs. And, no logic is shut down in dynamic reconfiguration. I see
that it is possible therefore that the new driver is connected to line
before the old one is released. This is a short! How do they detect and
avoid this? Hardly, user can do this.

Xilinx seems unable to answer that question
http://forums.xilinx.com/t5/Hierarchical-Design/How-active-reconfiguration-is-possible/td-p/146856

and their active reconfiguration does not work.
http://forums.xilinx.com/t5/Hierarchical-Design/How-large-the-diff-based-reconfiguration-can-be/td-p/157134

 

[valtih1978]

PS: I did runtime reconfiguration on an ATMEL AT94 part once, and
found issues with contention as well. My workaround was to "idle" the
chip with an "almost empty" bitstream first, and then repeat
reconfiguration with the new target bitstream. The temporary
bitstream contained nothing but I/O definitions to drive sane levels
to the peripherials on the PCB.

On Xilinx v2p, even this workaround does not help (see refs).

 

[Ed McGettigan]

On Jul 4, 4:55 am, valtih1978 <d...@not.email.me> wrote:

Normally, the tools check that there are no driver conflicts during
synthesis and shut down all drivers when start the configuration. Yet,
one and the same line can be driven by different drivers in different
designs. And, no logic is shut down in dynamic reconfiguration. I see
that it is possible therefore that the new driver is connected to line
before the old one is released. This is a short! How do they detect and
avoid this? Hardly, user can do this.

Xilinx seems unable to answer that questionhttp://forums.xilinx.com/t5/Hierarchical-Design/How-active-reconfigur...

and their active reconfiguration does not work.http://forums.xilinx.com/t5/Hierarchical-Design/How-large-the-diff-ba...

Yes, there will be momentary contention during partial
reconfiguration. The duration is not long to cause damage to the
device.

Ed McGettigan
--
Xilinx Inc.

 

[Marc Jet]

Yes, there will be momentary contention during partial
reconfiguration.  The duration is not long to cause damage to the
device.

What happens if the source controller of the configuration update
(internal or external to the chip) crashes/hangs/pauses in the middle
of a reconfiguration? Wouldn't that potentially extend a momentary
contention into a more long term contention?

If that is able to cause damage to the device, then it would be
advisable to specify a minimum reconfiguration speed. (I haven't
checked whether such a specification is already present in the
datasheets).

Marc

PS: I did runtime reconfiguration on an ATMEL AT94 part once, and
found issues with contention as well. My workaround was to "idle" the
chip with an "almost empty" bitstream first, and then repeat
reconfiguration with the new target bitstream. The temporary
bitstream contained nothing but I/O definitions to drive sane levels
to the peripherials on the PCB.

 

[Ed McGettigan]

On Jul 5, 8:44 am, Marc Jet <jetm...@hotmail.com> wrote:

Yes, there will be momentary contention during partial
reconfiguration.  The duration is not long to cause damage to the
device.

What happens if the source controller of the configuration update
(internal or external to the chip) crashes/hangs/pauses in the middle
of a reconfiguration?  Wouldn't that potentially extend a momentary
contention into a more long term contention?

If that is able to cause damage to the device, then it would be
advisable to specify a minimum reconfiguration speed.  (I haven't
checked whether such a specification is already present in the
datasheets).

Marc

PS:  I did runtime reconfiguration on an ATMEL AT94 part once, and
found issues with contention as well.  My workaround was to "idle" the
chip with an "almost empty" bitstream first, and then repeat
reconfiguration with the new target bitstream.  The temporary
bitstream contained nothing but I/O definitions to drive sane levels
to the peripherials on the PCB.

The time to failure will be highly dependent on the exact resources
that are in contention and the reliability factors for those
resources. There will always be pathological cases that can be
contrived or created that will accelerate time to failure, so there
isn't a single number that can be specified.

If the reconfiguration "failed" it would (or should) generate a system
reset and reconfiguration. Either automatically or by human
interaction because the system is down. A few drivers in contention
for hours or days won't be a problem. If it was expected to be even a
minor risk then we would have a completely different partial
reconfiguration methodology.

If it is a big concern then an empty bitstream could be loaded first
before the new design bitstream.

Ed McGettigan
--
Xilinx Inc.

 

[valtih1978]

My workaround was to "idle" the chip with an "almost empty" bitstream
first

ISE 13.2 says "The design is empty. No processing will be done"

Moreover, what will happen during dynamic logic "tear down"? Will you
have uncontrolled inputs (randomly uncontrolled drivers)?

 

ISE 13.2 says "The design is empty. No processing will be done"

To generate an empty bitstream, open 'fpga_editor', save an empty design (.ncd) and then run 'bitgen' on it.