Open side-bar Menu
 Real Talk

Posts Tagged ‘functional verification’

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?


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.


A Verification Standard for Design Reliability

Thursday, August 13th, 2015

_do-254The great thing about a standard is that once you decide to use it, your life as a designer is suddenly easier.  Using a standard reduces the long list of choices and decisions that need to be made to get a working product out the door.  It also gives assurance to the customer that you are following best practices of the industry.

A standard for the world of aviation electronics (avionics) is the RTCA/DO-254, Design Assurance Guidance For Airborne Electronic Hardware.  It is a process assurance flow for civilian aerospace design of complex electronic hardware typically implemented using ASICs or big FPGAs.  In the USA, the Federal Aviation Administration (FAA) requires that the DO-254 process is followed.  In Europe there is an equivalent standard called EUROCAE ED-80.

At first glance the standard seems daunting. It defines how design and verification flows must be strongly tied to both implementation and traceability. In DO-254 projects, HDL coding standards must be documented, and any project code must be reviewed to ensure it follows these standards.  They address the following issues: (more…)

Richard Goering and Us: 30 Great Years

Wednesday, July 1st, 2015


Richard Goering at his 30th DAC, San Francisco in 2014

Richard Goering, the EDA industry’s distinguished reporter and most recently Cadence blogger is finally closing his notebook and retiring from the world of EDA writing after 30 years.  I can’t think of anyone that is more universally regarded and respected in our industry, even though all he did was report and analyze industry news and developments.

Richard left Cadence Design Systems at the end of June (last month).  According to his last blog posting EDA Retrospective: 30+ Years of Highlights and Lowlights, and What Comes Next he will be pursuing a variety of interests other than EDA. He will “keep watching to see what happens next in this small but vital industry”.

When Richard left EETimes in 2007, there was universal hand-wringing and distress that we had lost a key part of our industry.  John Cooley did a Wiretap post on his DeepChip web-site with contributions from 20 different executives, analysts and other media heavyweights.  Here are a just few quotes that I picked out for this post: (more…)

Does Your Synthesis Code Play Well With Others?

Thursday, September 25th, 2014

Recently, Real Intent put out a new release of our Ascent Lint tool, which checks your RTL to make sure it meets the standards for good coding practices.  Linting has the advantages of delivering very quick feedback on troublesome and even dangerous coding style that causes problems that can show up in simulation, but will likely take a much longer time to uncover. With the right lint tool, you can catch the “low-hanging fruit” before tackling functional errors.  In a recent blog, we discussed how a staged analysis starting with Initial checks, followed by Mature and Handoff checks, can very efficiently get you to ‘hardened’ RTL code that is ready to be integrated with the rest of the design.


Autoformal: The Automatic Vacuum for Your RTL Code

Thursday, September 11th, 2014

The Roomba automatic vacuum cleaner may be the most popular home robot in the world.   It wakes up, wanders around your house collecting ‘dust bunnies’ and other dirt and then parks itself, where it can recharge and be ready for the next cleaning cycle.


Cat in a Shark Costume Riding a Roomba

Real Intent also offers an automatic tool that cleans up your RTL code. (more…)

CST Webinar Series
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