How do they handle shorts during the dynamic reconfiguration?

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

formatting link

and their active reconfiguration does not work.

formatting link

Reply to
valtih1978
Loading thread data ...

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

Ed McGettigan

-- Xilinx Inc.

Reply to
Ed McGettigan

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.

Reply to
Marc Jet

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.

Reply to
Ed McGettigan

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

Reply to
valtih1978

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

Reply to
valtih1978

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

Reply to
saardrimer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.