Global Sources
EE Times-India
EE Times-India > EDA/IP

Identifying reset domain crossing problems

Posted: 09 Sep 2014     Print Version  Bookmark and Share

Keywords:metastability  reset domain crossing  RDC  SoC  structural verification tool 

In a sequential system on chip design, if the reset of source register is different from the reset of destination register, even though the data path is in same clock domain, an asynchronous crossing path may occur which can lead to metastability at destination register [1].

This paper proposes a verification tool flow which can be used with any SoC structural verification tool to detect such reset domain crossing (RDC) problems. It also describes some techniques to make the SoC design tools you use intelligent enough to weed out false violations.

Why multiple resets in design are required
There are several reasons why resets are necessary in any system-on-chip design. One of the most important is that in any such design there is always some functionality which needs to be active up to the time the device gets a cold reset (Power On Reset due to unavailability of Power supply). These include such things as timekeeping functionality, calendaring features, clock and reset control modules. They are all expected to be intact when a global reset (warm reset) is asserted.

Other conditions when such resets are needed include when the software requests a warm reset to the system and the contents of the System RAM are expected to retain their values, as well as when there is a reset event causing a global system reset.

Apart from cold reset, sometimes the user wants to provide warm reset (global reset) to part of the system or a group of peripherals to start its functionality from reset state while the rest of the device is functional.

Scenarios where RDC occurs
It is important to understand the two typical design scenarios where reset domain crossing issues can occur: source flop reset—physically superset; and source flop reset—logically superset.

Figure 1: Source flop reset –physically superset.

Source flop reset—physically superset. Consider a case (figure 1) where we have two reset sources, rst1 and rst2, at top. Both are 'AND' connected to reset pin of first flop (async_rstA_b) and the second flop's reset (async_rstB_b) is only connected to rst2.

Here the reset sources of source flop are rst1 and rst2. The reset source of destination flop is only rst2. Hence we can say that reset sources of source flop are physical superset of reset sources of destination flop.

So there can be a situation where we have only first flop undergoing reset (assertion of rst1 only) and injecting metastability at second flop due to an asynchronous change of first flop's output.

Figure 2: Source flop reset –logically superset.

Source flop reset—logically superset. Consider another case (figure 2) when we have connected functional reset to async_rstA_b and POR (Power On Reset) to async_rstB_b. Functional reset always occurs whenever POR is asserted but vice versa is not true.

Now making reference to the above case, we can say the reset sources of source flop are func_rst (functional reset) and POR (as assertion of POR asserts functional reset) . And reset sources of destination flop is only POR.

Hence we can say that reset source of first flop, i.e. func_rst, is logically a super set of reset source of destination flop (POR). If functional reset is asserted due to any reset event except from POR, then there could be metastability at second flop.

Tool flow for detecting RDC violations
RDC violations vary with the complexity of a SoC. There could be millions of such violations for an SoC having multiple reset sources and a huge flop count. Identifying all such structures in design is not the key challenge. More of a problem is how to filter out the millions of reset domain crossing structures so that verification will be effective and less time consuming for the designer. Here's a tool flow that will help in analysing actual RDC issues:

Step 1: Load design
Tool loads the RTL design. It should be able to load verilog, VHDL, System Verilog, or a mix of all.

1 • 2 • 3 Next Page Last Page

Comment on "Identifying reset domain crossing pr..."
*  You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top