MENU

Security-hardened reset domain crossing circuit

Technology News |
By Christoph Hammerschmidt

Metastability is one of the major concerns in complex designs involving multiple clocks/resets. Modern designs often have multiple resets i.e., power on resets, soft resets, debug resets, low power & local/global resets. Different resets may be asserted at different times, such that one part of the design is reset while the other part is still functionally operational. Any metastable value arising at the interface can result in erroneous functionality, which might be very crucial, for example in secure applications. Reset domain crossing (RDC) is a scenario where in sequential logic, where the source & destination flops operate on different resets, the destination flop is susceptible to corruption when the source reset is asserted but the destination reset is not and hence resulting in data transition at the destination flop. Reset paths are untimed and not guaranteed to meet within a clock period, resulting in metastability at the destination flop. Hence, it is needed to identify these scenarios in the design and include appropriate measures to ensure that the design properly handles metastable situations.

Fig. 1 Reset domain crossing scenario

This article presents a secure hardened implementation to handle reset domain crossing. The implementation uses a reset generation request from the reset generation module to gate the clock of the destination flop prior to reset assertion. The clock (for the destination flops) is re-enabled only after ensuring that all the transitions triggered by reset assertion have settled to safe values.


Note that simply gating the destination clocks during reset-assertion is not sufficient, as shown in Fig 2. Destination flop i.e., FFC is clock-gated, based on the reset assertion request. The clock is ungated and on rst1_n assertion, FFB gets cleared. However, source flop i.e., FFA may still be undergoing reset, based on reset propagation latency of the network. This may result in FFC getting ungated clock and hence can capture metastable data from FFA

Fig. 2 Gating destination clock during reset assertion

 

To address this issue, a delayed version of reset-generation request can be used to gate destination clock as shown in Fig 3.

Fig. 3 Delay chain for gating destination clock

A delay element is introduced to ensure clock is disabled after FFA is reset. However, this implementation would delay assertion of the reset request as well and if the delay between reset generation request and actual reset assertion is less than the delay chain, FFA is reset and hence FFC could be sampling metastable values.


To address this issue, only de-assertion of reset generation request can be delayed while assertion can shut down the destination clock immediately. This can be achieved by introducing a MUX as shown in Fig. 4 which would ensure the assertion of reset generation request will result in immediate clock gating of FFC

Fig. 4 Proposed implementation delaying
only reset generation request de-assertion

To ensure that clock to FFC gets gated before reset controller asserts the reset, N (number of delay stages) should be small enough to allow the propagation of reset request before reset application and should be large enough to allow the settlement of metastability at the source flop.

Hence, the duration of delay-chain should satisfy the below condition:

Tcontroller > Tdelay-chain > Treset_latency

Where: Tcontroller – Time taken by reset-controller between reset-request and reset-assertion

 Tdelay-chain delay-chain duration

 Treset_latency – Max reset-tree latency of the design

Maximum latency of the reset paths in the design can be extracted from physical layout. A good number can be extracted after a single place-and-route iteration. The delay chain operates on destination reset and ungated clock so these signals are unaffected by reset assertion in source domain.


Here are the steps to implement the RDC handling logic:

  1. Use a reset-generation request from the reset-controller module
  2. Identify the appropriate delay value, based on the limits discussed above
  3. Implement a chain of shift-registers based on value in (b) that operates on destination reset and ungated clock
Fig. 5 Waveform showing the data flow in proposed implementation

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.


Some previous articles like [1] discuss reusing EDA checks build for ensuring power boundary crossings to identify & verify reset crossings. However, [1] just identifies/flags violating condition, whereas our implementation proposes a circuit based robust mechanism to address RDC. Another known design [2] presents a set of solutions to handle RDC crossings that proposes an intelligent method to hold the destination data using clock gates to avoid corruption from source domain. Another work [3] proposes multiple techniques to handle RDC crossings in the design and various verification techniques. The proposed technique elaborates on an efficient practice to control the destination clock, rather than directly gating destination clock as in [3] and the drawbacks of implementing a simple clock gating are also explained. The solution is further hardened for protection against any security attacks.

We have proposed an efficient circuit implementation to safely handle RDC crossings in a multi-reset design by gating destination clock based on reset generation request from reset generation module. A comparative study has been presented against some of known work to ensure the robustness of our implementation.

References:

  1. DDeep Shah, Namit Gupta, Mohamed Shaker Sarwary, Reset Domain Crossing Management using Unified Power, US20180004876A1, 1/4/2018.
  2. Article www.embedded.com – Dealing with SoC metastability problems due to Reset Domain Crossing
  3. Multiple Reset Domains Verification Using Assertion Based Verification – https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8203467

About the authors:

Satyanarayana Murthy is part of security IP development team in Automotive Division of NXP Semiconductors. He was responsible for supporting DFT methodologies in Digital IP team at Freescale Semiconductors, India. He received his master’s degree in Microelectronics and VLSI from Indian Institute of Technology Roorkee, India in 2015.

Sandeep Jain is responsible for security IP development in NXP´s Automotive Business Unit. Before his current assignment, Sandeep worked as SoC design lead for an automotive design. Before that he was managing DFT activities for all Freescale automotive designs at India design centre. He received his bachelor’s degree in Electronics and Communications Engineering from MDU University, India in 1999.

Vivek Sharma is part of Security IP development team in Automotive Division of NXP Semiconductors. He was responsible for front-end Design Verification in Digital IP team at NXP, India. He received his MTech degree in VLSI System Design from National Institute of Technology Warangal, India in 2006.


Share:

Linked Articles
Smart2.0
10s