Multiple factors must exist for this to occur and the expected failure rate is considered extremely low.
These factors include routing resources used, configuration frame ordering, order of the delivery of partial bitstreams, and the current value of the static signal.
Given that the glitch condition is partially based on bitstream construction, the behavior is repeatable.
A specific transition from one reconfigurable module to another reconfigurable module (but not back) might exhibit the condition.
If hardware testing has not shown any disruption in static design behavior, it is unlikely to be seen in a deployed system.
Nevertheless, to ensure the integrity of the static design during reconfiguration, the insertion of a blanking bitstream is recommended.
Users can create and deliver black box or blanking partial bitstreams to effectively remove all routes in a Reconfigurable Partition (RP) prior to the loading of the next Reconfigurable Module (RM).
This blanking bitstream will contain only static routes for the defined region, so no glitching can occur.
Unlike clearing bitstreams for UltraScale devices, delivery of blanking bitstreams is not order-dependent and only one is required per RP.
See (Xilinx Answer 63419) for more information on bitstream types.
Creation of the blanking bitstream is simple:
From a routed full design checkpoint, call update_design -black_box for each Reconfigurable Partition where this is a required step in the PR flow and save the resulting checkpoint.
write_bitstream will create a blanking bitstream for each RP, and the -cell option can be used to target specific RPs.
See (UG909) for more information.
Create an explicit design configuration with black boxes, importing the static results from the primary design configuration.
bitgen will create a blanking bitstream for each RP.
See (UG702) for more information.
Note: All ISE users are advised to migrate to Vivado for any active design activity to take advantage of improved features and quality of results.
Bitstream compression can be used to minimize blanking bitstream size.
Blanking bitstreams should be considered the same as standard partial bitstreams when it comes to behavior (for example: DONE) and delivery.
However please note the following difference:
Decoupling logic should be enabled prior to loading the blanking bitstream and held through delivery of the subsequent partial bitstream, as the module outputs are undriven for the blanking module.
The Partial Reconfiguration Controller (PRC) IP can be used to manage standard and blanking partial bitstreams, however, the user must define the sequence of events outside of the PRC.
Alternatively, contact Xilinx Support for amore automated approach using the PRC.
This blanking process will be automated in a future release of Vivado, and will not require user action.