Open side-bar Menu
 Real Talk

Archive for March 7th, 2013

Part Five: Clock and Reset Ubiquity – A CDC Perspective

Thursday, March 7th, 2013

An asynchronous reset control that crossed clock domains but was not synchronously de-asserted, causing a glitch in control lines to an FSM.

The scenario above is at the confluence of the following three design requirements, and resulted in a failure when one of them was not met:

A. The need for multiple clock domains in the design that can be independently reset.
B. The need to use flip-flops that are asynchronously reset.
C. The need for reset signals to be asynchronously asserted but synchronously de-asserted.

Let us delve deeper into each of these design requirements in order to understand the context of the failure.

A. Need for multiple clock domains in the design that can be independently reset.

In the event of failure, a hardware reset is a necessity to restore the system to a known initial state from which it can start functioning deterministically. Power-cycling a modem is a classic example of allowing enough time for a system reset to propagate to all sub-systems, some of which might be operating at different clock frequencies. From a verification standpoint, since each of these subsystems typically is designed and verified separately, the presence of a reset in each subsystem enables effective block-level verification by ensuring that the design is in a known state for simulation.

It is good design practice for every flip-flop in a design to be resettable. In order to extract higher performance in functional mode, there may be certain parts of the design (e.g. pipeline registers) which themselves are not resettable but whose upstream registers are. In such cases, the design takes more clock cycles to be put into a known state as the upstream reset values need to propagate down to these registers. Often, this is an acceptable tradeoff but one that the system designers need to be cognizant of when determining the reset strategy for the SoC.

Several benefits stem from the ability to independently reset subsystems, some of which are:

  1. Managing functional complexity of the system
  2. Avoiding the long latency of a system-wide reset in the event of a subsystem failure
  3. Being able to run simulations on a subsystem level prior to integration
CST Webinar Series

Internet Business Systems © 2016 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy