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.
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…)
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?
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…)
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…)
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.
The 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 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.
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…)
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.
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…)