Open side-bar Menu
 Real Talk

Posts Tagged ‘cdc’

The Switch from Atrenta to Real Intent for CDC, Lint, and X-prop

Thursday, May 12th, 2016

John Cooley’s web-site likes to publish end-user experience with various EDA tools.  On May 6, he published a posting on why a designer switched from Atrenta SpyGlass to Real Intent for CDC, Lint, and X-propagation analysis.  His report details the reasons for converting to our best-in-class tool suite.

Here is the first part of the posting:

We had been using SpyGlass from Atrenta, and it worked OK for us, but we
were told by our local Real Intent sales guy that “there would be fewer
iterations for Lint, easier setup for CDC, lower-noise reporting, and
faster runtimes” — if only we evaled his tools.


I spent one work week (5 days) evaluating Meridian CDC. We used different
designs to evaluate this tool. The first was 850K gate design that had
3 asynchronous clock domains. For the analysis setup, Meridian CDC
automatically detected all the clock/reset candidates correctly at block-
level as well as the top-level. No additions were needed for the setup
file, while our Spyglass run did require manual editing of the setup.
The Meridian runtime for this block was ~5 minutes.

The second design was 4 million gates and had 5 asynchronous clock domains.
Again the automatic clock/reset detection worked as expected. The runtime
was ~15 minutes.

Read the rest of the report on CDC, lint and X-propagation here.

Have you switched EDA tools recently?  How was that experience?

7 Design Faults Leading to Clock and Data Glitches

Thursday, April 28th, 2016

Recently I came upon an article by Ankush Sethi of Freescale on the importance of avoiding bad design practices that lead to glitches in clocks which result in asynchronous behavior. He points out:

It is very important to make digital designs free of any clock or data glitches to ensure correct functioning. There are many cases where such issues have caused functional failure, or increased design time through incurring extra debug effort. Hence, it is very important for a designer to take care of such issues at the earliest stages of design once flagged by a tool or gate-level synthesis.

Here is his introduction followed by an iframe of the article from EDN magazine.

With the increasing complexity of SoCs, multiple and independent clocks are essential in the design. The design specifications require system level muxing of some of these clocks before they are sent to actual IP. Also, to save power, clock gating cells are inserted in clock paths. While implementing these muxing and gating cells, a designer tends to make mistakes that can lead to glitches. A glitch on a clock signal exposes a chip (or a section of a chip) to asynchronous behavior. A glitch-prone clock signal driving a flip-flop, memory, or latch may result in incorrect, unstable data. This paper discusses structural faults that can lead to glitches in clocks. Also, some bad design practices that lead to glitches in data are discussed. (more…)

Verification Coffee Break – Where are We Going?

Thursday, April 14th, 2016

Pranav Ashar, CTO at Real Intent was interviewed in April by SemIsrael, Israel’s leading semiconductor design and development portal, on the latest trends in the world of verification. Below, I have embedded video clips that cover each of the five questions he addressed. You can watch the entire video here.

Q1. What is the current trend driving verification?


How Physical Implementation Can Break Your Clock-Domain Crossing Logic

Thursday, March 31st, 2016

At DVCon’16, Mark Litterick presented a paper and presentation on “Full Flow Clock Domain Crossing – From Source to Si.”   Here is the abstract for the paper:

Functional verification of clock domain crossing (CDC) signals is normally concluded on a register-transfer level (RTL) representation of the design. However, physical design implementation during the back-end pre-silicon stages of the flow, which turns the RTL into an optimized gate-level representation, can interfere with synchronizer operation or compromise the effectiveness of the synchronizers by eroding the mean time between failures (MTBF). This paper aims to enhance cross-discipline awareness by providing a comprehensive explanation of the problems that can arise in the physical implementation stages including a detailed analysis of timing intent for common synchronizer circuits.

Mark works for Verilab as senior verification consultant and holds the position of fellow. He is based in Munich, Germany.  To see more of Mark’s technical papers, check out his profile page on the Verilab web-site.

Even though, you may have signed-off for CDC at RTL, logic synthesis, design-for-test and low-power optimization tools can break CDC at the gate-level, the physical implementation stage of design. Real Intent’s Meridian products provide clock-domain crossing verification and sign-off.  Our most recent offering is Meridian Physical CDC and provides sign-off at the netlist level of the design.  It uses a mix of structural and formal methods to identify  glitching and other errors that break the correct registration of signals crossing clock domains. (more…)

Informal, Unformal, or Appformal? …and new

Thursday, March 10th, 2016

Around the Design and Verification Conference in San Jose at the beginning of the March, a lot of activity was happening in the online world in preparation for the big meetup of the verification community.

First, the web-site published a set of five (5) articles that surveyed the world of formal verification in EDA, written by Jim Hogan, of Vista Ventures, a Silicon Valley investment firm.  Jim is currently on the Board of OneSpin, a formal tools company.  Knowing Jim, he did his homework before getting involved with them.  If you read the articles, which total 12,000 words, you will have to agree with me there is a lot of great content here.  If a technical writer charged for producing this, you would be looking at a bill close to $20,000.

These days you have to two general ways to verify the functionality of your RTL with formal.  You either write your own properties and then feed them and the RTL to a formal property verifier (FPV) tool, OR you have an application-focused formal tool  automatically read and apply properties to your design.


CDC Verification of Fast-to-Slow Clocks – Part 3: Metastability Aware Simulation

Thursday, January 28th, 2016

We continue the short blog series that addresses the issue of doing clock domain crossing analysis where the clocks differ in frequency. In Part 1 and Part 2, we discussed the use of structural and formal checks when there is a fast-to-slow transition in a clock domain crossing. In this blog, we will present the third and final step using a design’s testbench.

The next step in the verification process of fast-to-slow clock domain crossings is to do metastability-aware simulation on the whole design. When running a regular simulation test bench, there is no concept of what could happen to the design if there was metastability present in the data or control paths within the design. One of the key reasons for doing CDC checks is to ensure that metastability does not affect a design. After structural analysis ensures that all crossings do contain synchronizers, and formal analysis ensures that the pulse width and data are stable, a whole-chip metastability-aware simulation is needed to see if the design is still sensitive to metastability. Functional monitors and metastability checkers are shown in Figure 7. No changes are made to the design, and the necessary monitors and checkers are written in an auxiliary Verilog simulation test bench file. This auxiliary file is simply referred to by the original simulation test bench file to invoke the metastability checking. As a prerequisite, this step requires that the design have a detailed simulation test bench. (more…)

CDC Verification of Fast-to-Slow Clocks – Part 2: Formal Checks

Thursday, January 21st, 2016

We continue the short blog series that addresses the issue of doing clock domain crossing analysis where the clocks differ in frequency. In Part 1, we ended the discussion noting that when there is a fast-to-slow transition, there is a possibility that a short duration control pulse may be completely missed by the receive domain and a formal analysis is required to discover if this is a potential problem. We will look at how formal analysis can verify this kind of transition.

A formal check also is required on a slow-to-fast data crossing with feedback. In such a circuit, as shown in Figure 4, an acknowledge signal coming from the receiving fast-clock domain to the transmitting slow-clock domain also requires a formal Pulse Width check. Although the control pulse (request) is going from slow to fast and does not need a formal pulse width check, the acknowledge pulse-width check is necessary because the acknowledge signal (the feedback circuit) is going from a fast to a slow clock and, in order for the acknowledge to be properly captured, the acknowledge pulse (transmitted from the receiving side) must be sufficiently wide to be captured (received on the transmitting side) by the slower clock domain of the transmitting side flops. Failure to check for this condition is the reason behind many a request/acknowledge circuit not working as expected. Note that feedback circuits in a fast-to-slow crossing are operating in a slow-to-fast mode and the acknowledge signal in such a circuit does not need to be pulse-width checked. In short, all fast-to-slow control signal transitions, whether connected in a feed-forward or a feedback manner need to be formally pulse-width checked to ensure integrity of the control aspect of the clock domain crossing. (more…)

CDC Verification of Fast-to-Slow Clocks – Part 1: Structural Checks

Thursday, January 14th, 2016

This is a reprise of  a short blog series that addresses the issue of doing clock domain crossing analysis where the clocks differ in frequency, and the use of three different techniques for a complete analysis.


CDC checking of any asynchronous clock domain crossing requires that the data path and the control path be identified and that the receive clock domain data flow is controlled by a multiplexer with a select line that is fed by a correctly synchronized control line.  Meridian CDC will always identify all the data and associated control paths in a design and will ensure that the control signals passing from a transmit clock domain to an asynchronous receive clock domain are correctly synchronized.  There are three separate techniques that are used within Meridian CDC: structural checking, formal checks and simulation-based injected metastability checks.

(more…) Survey: “Real Intent to possibly replace SpyGlass?”

Thursday, December 17th, 2015


It’s not a BUG, it’s a FEATURE!

John Cooley at does an annual survey of visitors to the Design Automation Conference to find out what was interesting, and the biggest lie.

In one of his roll-up articles he looked at Real Intent, Atrenta (acquired by Synopsys), and One Spin.

With acquisitions, customers get nervous and for good reason.  The support and responsiveness they get changes.  Five respondents said they were considering possibly replacing SpyGlass with Real Intent.  One user reported the following conversation:

“Your SpyGlass customer support won’t change as a result of the SNPS acquisition.” They actually said that to me with a straight face.

The article also reported a customer evaluation of our Ascent Lint and Meridian CDC (clock-domain crossing) tools. Here is a quick snippet: (more…)

Video: “Why A New Gate-level CDC Verification Solution?”

Thursday, November 19th, 2015

Recently, I interviewed Vikas Sachdeva, Sr. Technical Marketing Manager at Real Intent where we discusse why gate-level CDC verification is necessary, what are some of the failure modes that can occur, and why Meridian Physical CDC is the right tool to do gate-level sign-off. You can see the video below.  You can also find more information about Meridian Physical CDC here.

Click here to watch other Real Intent videos on our YouTube Channel.

S2C: FPGA Base prototyping- Download white paper

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