Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded

Structural, reset faults in SoC designs (Part 1)

Posted: 16 Oct 2013 ?? ?Print Version ?Bookmark and Share

Keywords:system-on-chip? reset? metastability? SoC? metastable?

In system-on-chip designs, as in most electronics systems, it is important to include reset capability. A reset clears any pending errors or events and returns a system to normal condition or an initial state. It is usually done in response to an error condition when it is impossible or undesirable for a processing activity to proceed and all error recovery mechanisms fail. The lack of a proper reset ability can render the device useless after a power loss or malfunction.

With the increased complexity of digital design, the reset architecture used in current nanometre-scale designs has become very complex. While implementing such complex architecture, the designer tends to make some basic mistakes in the implementation of such resets leading to metastability, which in turn results in functional failures in the system.

Metastability is the tendency for a digital electronic system to persist for an unspecified time in an unstable equilibrium or metastable state, where a circuit may not be able to settle into a stable '0' or '1' logic level within the time required for proper circuit operation. As a result, the circuit can act in unpredictable asynchronous ways, leading to "glitches" that cause system malfunctions.

In modern nanometre-scale SoC designs, implementation of a reset architecture is therefore a crucial part of any design. Designers need to consider each and every aspect to ensure that the system will not get any false reset trigger or become metastable/corrupted due to wrong reset design implementation.

This article discusses some basic structural issues in reset design and the metastable problems they cause, including: reset domain crossing, glitches at reset source due to combinatorial loops, combinatorial logic in the reset path, misapplication of synchronous resets, reset-syncrhonizer redundancy, and, finally, reset de-assertion due to uncommon clock paths. At the end of the discussion of each problem some solutions are proposed.

Figure 1: Reset domain crossing issue.

Reset domain crossing
In traditional sequential designs that operate synchronously, if the asynchronous reset of source register is different from the reset of destination register, during the reset assertion of start-point register the data input of destination register changes asynchronously. This path will then operate asynchronously and unpredictably without regard to the global clock although both source and destination register are in same clock domain. This condition C known as a 'reset domain crossing' C occurs where the resets of the launch and capture flop are different. It can cause metastability at the destination register during reset assertion of source register.

In this scenario the asynchronous reset assertion of start point register-C and of the destination register-A are different (figure 1). Suppose that during reset assertion of register C the flop A is not in reset. In such a case, if some valid data transaction is going on at the input of register A, then the changes due to asynchronous reset assertions on start point register C can cause timing violation at destination register A. This will produce metastability.

Solution: In the timing diagram in figure 1, when some valid data transaction goes through C1, then rst_c_b gets asserted, causing C1 to change asynchronously (w.r.t clk). As a result, meta-stability at QC1 may cause functional failure. To avoid this problem, in addition to using a synchronous reset, non-resettable flops or POR for the D1 flop it will also be necessary to determine if the source of the reset rst_c_b is synchronous. If it is, then it is safe to assume that considering the timing arc from C_CLR>Q for setup-hold check from>C_CLR>C_Q1>C1>A_D can avoid metastability. in design. However usuallyby default- C_CLR>Q timing arcs are not enabled in library and as a result it they need to be explicitly enabled during timing analysis.

Use a two-flop synchroniser at destination (A) to avoid the propagation of metastability throughout the design.

Glitch at reset source due to combinatorial loop
In an SOC the global system reset is a combination of various reset sources in a device (figure 2) generated either by software or hardware: LVD reset, watchdog reset, debug reset, software reset, and loss of clock reset. All can be used to assert global system reset.

1???2?Next Page?Last Page

Article Comments - Structural, reset faults in SoC desi...
*? You can enter [0] more charecters.
*Verify code:


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

Back to Top