Open side-bar Menu
 Real Talk
Graham Bell
Graham Bell
Graham is VP of Marketing at Real Intent. He has over 20 years experience in the design automation industry. He has founded startups, brought Nassda to an IPO and previously was Sales and Marketing Director at Internet Business Systems, a web portal company. Graham has a Bachelor of Computer … More »

Fundamentals of Clock Domain Crossing Verification: Part Three

 
July 24th, 2014 by Graham Bell

Last time we looked at design principles and the design of CDC interfaces.  In this posting, we will look at practical considerations for designing CDC interfaces.

Verifying CDC interfaces

A typical SOC is made up of a large number of CDC interfaces. From the discussion above, CDC verification can be accomplished by executing the following steps in order:

  • Identification of CDC signals.
  • Classification of CDC signals as control and data.
  • Hazard/ glitch robustness of control signals.
  • Verification of single signal transition (gray coding) of control signals.
  • Verification of control stability (pulse-width requirement).
  • Verification of MCP operation (stability) of data signals.

All verification processes are iterative and achieve design quality by iteratively identifying design errors, debugging and fixing errors and re-running verification until no more errors are detected.

Practical considerations for CDC verification

Effective deployment of CDC tools in the design flow requires due consideration of multiple factors. We have discovered that first-generation CDC tools were not being used effectively in design flows. Based upon feedback from users, we have identified the following factors as the most important considerations for CDC deployment:

  • Coverage of error sources.
  • Design setup cost.
  • Debugging and sign-off cost.
  • Verification run-time cost.
  • Template recognition vs. report quality trade-off.
  • Top-level vs. block-level verification trade-off.
  • RTL vs. netlist verification trade-off.

There is consistent feedback from the users that the minimization of engineering cost for high-quality verification is critical for effective deployment of the CDC tools.

Coverage of error sources

CDC errors can creep into a design from multiple sources. The first is inadvertent clock-domain crossing where there is an assumption mismatch or oversight at block interfaces. The second is faulty block-level design. The designers, because of oversight or because of the pressure to design correct and high-performance interfaces, can make a design error. As an example, consider the protocol in Figure 12. Here, tapping Feedback Signal from an earlier flop stage can reduce the latency across the interface. But correct operation of this interface requires that the transmitting clock frequency be lower than the receiving clock frequency. Otherwise, it is possible to signal New Data before Load Data is completed.

 Fig12
Figure 12. Reduced latency protocol.

These two error sources are properly covered by RTL analysis. They can also be covered by netlist analysis. But not all CDC error sources are covered by RTL analysis. This is because CDC errors are dependent upon glitches and hazards. It is a well-known phenomenon that synthesis transformations can introduce hazards in the design. Hazards in CDC logic lead to CDC failures. Figure 13 shows an example of a design failure caused by synthesis. Here, the multiplexor implementation created a logic hazard that violated the multi-cycle path requirement on the data bus. We are aware of multiple design failures because of this phenomenon.

 Fig13
Figure 13. Logic hazard caused CDC failure.

With the increasing complexity of SOCs and the increasing number of CDC interfaces on the chip, the contribution of this risk factor is increasing. As a result, CDC verification must be run on both RTL and netlist views of the design.

Design setup cost

Design setup starts with importing the design. With the increasing complexity of SOCs, designs include RTL and netlist blocks in a Verilog and VHDL mixed-language environment. In addition, functional setup is required for good quality of verification. A typical SOC has multiple modes of operation characterized by clocking schemes, reset sequences and mode controls. Functional setup requires the design to be set up in functionally valid modes for verification, by proper identification of clocks, resets and mode select pins. Bad setup can lead to poor quality of verification results.

Given the management complexity for the multitude of design tasks, it is highly desirable that there be a large overlap between setup requirements for different flows. For example, design compilation can be accomplished by processing the existing simulation scripts. Also, there is a large overlap between the functional setup requirements for CDC and that for static timing analysis. Hence, STA setup, based upon Synopsys Design Constraints (SDCs), can be leveraged for cost-effective functional setup.

Design constraints are usually either requirements or properties in your design. You use constraints to ensure that your design meets its performance goals and pin assignment requirements. Traditionally these are timing constraints but can include power, synthesis, and clocking.

Timing constraints represent the performance goals for your designs. Designer software uses timing constraints to guide the timing-driven optimization tools (synthesis) in order to meet these goals. You can set timing constraints either globally or to a specific set of paths in your design. You can apply timing constraints to:

  • Specify the required minimum speed of a clock domain.
  • Set the input and output port timing information.
  • Define the maximum delay for a specific path.
  • Identify paths that are considered false and excluded from the analysis.
  • Identify paths that require more than one clock cycle to propagate the data.
  • Provide the external load at a specific port.

Correct functional setup of large designs may require setup of a very large number of signals. This cumbersome and time-consuming drudgery can be avoided with automatic setup generation. Also, setup has the first-order effect on the quality of verification. Hence, early feedback on setup quality can lead to easy and effective setup refinement for high quality of verification.

 Fig14
Figure 14. Design setup flow.

In the next posting we will discuss the costs associated with debugging and sign-off verification .

Related posts:

Tags: , , , ,

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

DownStream: Solutions for Post Processing PCB Designs
Verific: SystemVerilog & VHDL Parsers
TrueCircuits: UltraPLL



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