An alternative way to generate a reset for an RM is to add code to the RM so it self-generates a reset when it loads. This method requires a finite state machine (FSM) with the following states:
rm_reset <= '1' when state = ST_WAIT_ON_EOS else '0';The state machine returns to ST_WAIT_ON_EOS if a system reset occurs, or
if you load the RM using DFX. In both cases, the transition occurs because the
underlying DFF is reset, not because of any combinatorial logic.
In this FSM, assert the reset signal to the remainder of the RM in
ST_WAIT_ON_EOS, and deassert it in ST_OPERATIONAL.
You need an FSM like this because EOS asserts when RMs in other RPs load, so your RM
cannot use EOS directly to generate its own reset signal. Instead, it must respond to
EOS only when it is loading. This FSM is sensitive to EOS only when you have loaded the
RM or when there is a system-wide reset, in which case it ignores EOS because EOS
remains high during the reset.
This approach has several disadvantages compared to an externally generated reset, such as:
- The FSM can only be a single bit unless you carefully place data flip-flops (DFFs) that all see global write enable (GWE) at the same time. This step can be overlooked, and extra states can be added later by someone who does not fully understand the impact.
- You must include and verify the FSM in each RM individually.
- You must route both the system reset and EOS signals into the RM. An externally generated reset only requires one signal to be routed.
- It doesn’t handle blocks in the RM that have an edge-sensitive reset. Although you can add extra states to support this, doing so is vulnerable to the problem described in #1.
This approach provides no advantages over an externally generated reset and introduces risks and limitations. AMD does not recommend it.