Due to of a variety of factors, reconfigurable modules (RMs) require in-system mechanisms to ensure they synchronize with the rest of the system after loading. Failure to include these mechanisms can result in sporadic error conditions. Non-DFX designs also require these mechanisms (see AR 44174), although issues are less likely. In DFX designs, the clocks are often already running when reconfiguration happens, which makes synchronization issues between the RM and the static shell much more likely to occur.
When you use partial programming images include steps that occur after you load design data into the target device. At a high level, the RM startup sequence automatically includes these fundamental steps:
- Assert GRESTORE to initialize all of the synchronous elements to their initial values
- Assert global write enable (GWE) to make synchronous elements writable from the PL
- Assert end of startup (EOS) to signal that all configuration startup tasks are complete
This list is not exhaustive, and additional activities occur between these steps. Importantly, configuration is not complete until EOS asserts, and it is not safe to enable the RM logic until this point.
The global signal GWE is not synchronised to your user clock and can take substantial time to propagate to all parts of the device, especially for exceptionally large RPs in devices that use SSI technology. As a result, the synchronous elements in an RM can start operating on different user clock cycles, corrupting the RM’s state. Because GWE asserts after GRESTORE, the configuration process has no opportunity to return the RM to an uncorrupted state.
The RM is in a partially operational state in the period during the period between GWE asserting and EOS asserting. Individual DFFs can operate, but you cannot predict which ones operate or what they do. For example, a 4-bit state vector might have bits 1 and 3 activate and transition to new value, while bits 0 and 2 remain inactive and unable to change. When this happens, the RM is in a corrupted state.
There are three solutions to this problem, which individually or combined can help avoid DFX designs from getting into a corrupted state.
- Apply a reset to the RM until EOS asserts, or longer if required.
- Stop the user clock until EOS asserts, or longer if required.
- Deassert clock enable to all synchronous elements until EOS asserts, or longer if required.