In a sequential system on chip designs, if the reset of source register is different from the reset of destination register, even though the data path is in same clock domain, this can cause an asynchronous crossing path to occur which can cause metastability at destination register .
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.
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.
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 analyzing 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.
Step 2: Define top level reset
Tool should be able to take input of user-defined top-level reset sources. Top-level reset sources does not mean only external reset input but also the outputs of on-chip reset generation module. While defining reset sources user should be able to provide name alias for reset source for better readability.
Step 3: Tool-generated reset source
If a reset is generated inside a module deep down the hierarchy after some combinatorial logic, tool should automatically treat them as generated reset source and pop to user for proper disposition.
Step 4: Set/Case Constraint define
While loading the design user should have provision to make some combinatorial cell transparent by putting some set/case. If done, tool should automatically associate the reset to its parent reset source.
Step 5: Run 1
Once the above constraints are loaded, tool does initial analysis to find out the number of reset domains in design. If the assertion of two resets is different then they are part of separate reset domain. Here tool should give us two separate lists of tool-generated and unknown resets. It will be beneficial if at this stage user analyzes the two lists and defines Reset association and Reset pair exemption (explained below) based on them.
Step 6: Reset association
Tool should have intelligence to identify reset structures where two or multiple reset sources are generated from some logic where it is always ensured that their assertion will always be together. Once identified, tool can internally associate such structures to the same domain such that no RDC check is performed between them. User should also have provision to define reset association.
Step 7: Reset pair exemption
Tool should have provision to take user input of reset pair (with direction) to be exempted from RDC checks. For example if rst_a and rst_b belongs to two different reset domains and user wants to ignore RDC when source register is reset by rst_a and destination is rst_b . But user wants to check valid violation when source register is reset by rst_b and destination by rst_a .
Step 8: Run 2
Start doing analysis with above constraints and look for valid RDC paths in design.
Step 9: Manual waiver input
Tool should take manual waiver/filter input having RDC paths with source/destination register name with reset information. These are some RDC paths where structurally it’s an RDC violation but designer guarantees on the functionality. User should have provision to create waivers directly from GUI mode.
Step 10: Accelerating run on SoC
If RDC checks are performed at module level then smooth porting of IP-level constraints and merging them in SoC-level constraints will certainly accelerate SoC-level RDC check. Tool should have porting capability such that IP-level constraints/waivers can be re-used at SoC.
Step 11: Gray boxing of RDC checks
While performing RDC checks, if user wants to ignore any RDC violation inside an IP he should have the provision to grey box the IP which will reduce run time and effort in analysis.
Step 12: Tool log and schematic debug
The tool should dump a log that provides user sufficient information to make debug and post processing easy. Also tool should provide schematic debug capability to user. In the tool log we can provide the violations as shown below:
- RDC Error:-The reset x.y.z on source flop a.b.c crosses into reset u.v.w on destination flop d.e.f (where '.' is hierarchical separator). Better color coding in GUI/schematics depending on Reset domains will certainly help to accelerate the debug.
Setting up the tool flow
While analyzing and determining thereset domain of a device during RDC you should set up your tool flow sothat it can associate resets with specific domains by identifyingparticular structures. Below are some such structures.
Figure 3 shows a circuit set up so that the assertion of reset RESET_in andRESET_out will always happen together. However the de-assertion shouldalways be delayed by two clk cycles to allow time for the tool toautomatically associate these two reset sources in same domain.
Similarly,in a device there can be multiple reset sources which assert at thesame time but where de-assertion depends on different counter rolloversor the completion of some different function. Let’s take as an examplethe circuit shown in Figure 4 below. rst2_b and rst4_b can be used as two different reset sources in a design. rst2_b de-asserts first, which enables certain device initialization functionality, and rst4_b de-assertsonce that device initialization functionality is done. Since theassertion of these two resets occurs at the same time, they can beassociated in same domain.
Other advanced tool flow techniques
Acommon practice to avoid any RDC issues is to gate the system clock(s)during reset. A simple strategy to achieve this is shown in Figure 5 .As soon as a reset event is acknowledged we delay the reset assertionto the system. To do this we first gate the clock(s) and then assert thereset. The reset is then de-asserted and the clock is revivedafterwards. Here, the assumption is that no IP/logic in the SoC requiresclock during reset. If there is any requirement for a synchronousreset, then the designer needs to alter the scheme described.
Youshould also set up the tool flow so that you can specify which clocksare gated during reset. This should be done so that no violation isshown by the tool on paths running on that clock.
Using sync output at destination. The tool flow should be set up to identify the structure shown in Figure 6 and not flag violations when it is identified. To prevent anymetastability issues, the tool flow should be set up to create a list ofpaths where such synced output is used.
Destination flop reset – physically superset .There are sometimes situations where the reset sources of two flops aredifferent but the tool shouldn’t flag a violation, particularly when itmakes no difference to the proper functioning of the circuit. Anexample of this is shown in Figure 7, where both flops have differentresets but there is no functional problem since it is not possible forthe source flop to be under reset while the destination is active (notunder reset).
1. Dealing with SoC metastabities problems due to reset domain crossing , Embedded.com,
Arjun Pal Chowdhury is Lead Design Engineer at Freescale Semiconductor. He has seven yearsof experience in SoC Design and Architecture and is involved indesigning chips for automotive as well as industrial and multimediamarkets.
Neha Agarwal is Senior Design Engineer atFreescale Semiconductor. She has been working with Freescale for threeyears in SoC Design and Architecture and is involved in designing chipsfor the automotive market. She graduated from Birla Institute ofTechnology, Mesra, in 2009.
Ankush Sethi is amember of the SoC architecture and front-end integration team atFreescale India. He received his Bachelors degree in Engineering (inElectronics & Communication division) in 2012 from Netaji SubhasInstitute of Technology (NSIT), affiliated with the University of Delhiin India. He joined Freescale in June 2012 directly upon graduation.