In this solution, you generate the reset signal for the RM in the static design and route it into the RM. Each RP needs its own reset so you can reset the RM independently after loading. You need to assert these resets when the system wants to reset a particular RM and whenever any system-wide reset occurs.
If you apply a reset after EOS, the RM returns to a known state, as long you design the RM correctly (see Potential Problems for more information). However, you must prevent an RM from entering into a corrupted state in the first place. To do that, assert the reset before GWE asserts, and hold it until EOS asserts. You can hold the reset longer if your system needs extra time before the RM becomes operational.
Assume you have a design-specific signal called rm_being_loaded with the
following properties:
- Asserted when the design requests the RM to be loaded
- Deasserted (at the earliest) when EOS is detected
rm_reset <= system_reset OR rm_being_loaded;You can register the signal to meet timing if necessary. This example assumes active-High resets. Adjust the equation for active-Low resets accordingly.
Alternatively, you can use rm_being_loaded to control a DFX decoupler IP
on the system_reset input to the RM.
Configure the DFX decoupler to drive the reset active-level (1 in this example) when decoupled. You can select a global buffer to drive the signal if necessary. This approach can be useful if the DFX decoupler IP is already being used to decouple the RM's boundary during DFX.