Here are the steps to implement the RDC handling logic:
- Use a reset-generation request from the reset-controller module
- Identify the appropriate delay value, based on the limits discussed above
- Implement a chain of shift-registers based on value in (b) that operates on destination reset and ungated clock
The data flow in the proposed implementation is shown in Fig. 5. The logic needs no further acknowledgement to the reset-controller for reset completion/clock enablement.
In many applications, the logic domain with less-frequent resets (rst2_n) may contain static and sensitive data, like device and security configurations. In such cases, causing the destination registers to go metastable (due to unclean reset crossing) may be a favorable attack condition. For example, flipping the last bit of the delay-chain will essentially bypass the shift stages, resulting in an immediate reset propagation. This may induce metastability and result in undesired values being latched at the destination registers, which may be of interest to an adversary.
To make the logic robust against such conditions, we recommend the registers of the delay chain be triple-voted for protection against power/voltage glitch attacks. Alternatively, we can sample all N-elements in the delay chain to be '1', rather than just the last element, for additional robustness. However, this would create a large combinational cloud at the enable input of a clock-gating cell, which needs to be handled accordingly.