Gabe's EDA Update
In June 2012 Gabe Moretti will celebrate 44 years in EDA. Gabe has contributed to the industry first as a developer, then as a senior manager and now as an editor and industry observer. He is a Senior member of the IEEE and the recipient of the IEEE RonWaxman Meritorious Award. Gabe has worked … More »
Do What I Mean, Not What I Say
May 7th, 2012 by Gabe Moretti
A little over a month ago, Vaishnav Gorur of Real Intent published an article on Tech Forum with the title “Blindsided by a Glitch”.
In the early nineties, I had the opportunity to “experiment” with Design Compiler to find different semantics in both VHDL and Verilog to describe the same function but get different gate level circuits produced. At the beginning many results looked like bugs in the tool, but, as it turned out then and turns out today, logic synthesis does generate different circuitry depending on how the RTL is described.
More than twenty years later, we are still experiencing the same issue in logic synthesis. The subject of design intent, in the mean time, has become larger but the fundamental problem persists. How does one communicate intent? The problem of course is not just relegated to electronic design. Daily communications suffer from this problem as well. How many times one eras: “that is not what I meant” said?
What makes the language rich, semantics variations, also makes it less precise. Things must be interpreted in context, but we have not developed a method to define context yet.
This is not a matter of poor tool quality. The results depend not only on the synthesis algorithms employed, but principally on the rules that the tool must follow. When told to minimize power while at the same time increase execution speed and respect size limitation, tools some time produce legal logic that behaves properly under normal condition, but generates errors in particular cases.
The article, for example points out that designers should take several precautionary options when writing RTL to avoid glitches on CDC-related control, data and clock paths. The article contains the following guidelines:
• Avoiding combinational logic on a control path crossing prevents a glitch from being generated and subsequently captured in the receive domain.
But, even when designers handoff such carefully crafted RTL to synthesis, a distinct possibility exists that the synthesis tool could output a gate-level netlist that suffers from glitches.
As the author writes, the primary goal of contemporary synthesis tools is to generate a netlist design that meets a target specification based on three metrics – performance, area and power – while maintaining logical equivalence to the original RTL design. However, these tools do not guarantee glitch-free logic and that makes the gate-level netlists they produce susceptible to glitches.
Moreover, synthesis tools can move logic across registers (an optimization technique called ‘register retiming’) to meet performance targets in the synchronous parts of the design.
It is important to emphasize that these glitches are not present in the original RTL description and that they get introduced during the synthesis process. This is why running glitch analysis on a gate-level netlist is of paramount importance.
In his article Mr. Gorur offers an example of a Clock Domain Crossing (CDC) problem that was inadvertently introduced by synthesis if the resulting gate level circuit was part of an asynchronous circuit.
The rest of the article goes on to explain the importance of performing post synthesis analysis of CDC events using Real Intent’s Meridian CDC 4.0 tool and shows how such inadvertent condition can be easily identified using the tool. When using synthesis especially with today’s complex designs, it is important to always look at the result and ask the question: “Is this what I really meant?” before declaring the job done. Asynchronous logic is powerful and used more often today to minimize power use, but it is not always intuitive and thus can be misunderstood by synthesis algorithms.
The article is another example of how designers should consider EDA tools as design aids, not as substitute for their own intelligence and know-how. (I was going to write “intelligent design” but realized that this could take me in a total unintended direction).
In the past I have often written that EDA tools do not replace an engineer’s knowledge but aid designers and increase productivity. This article fully supports my assertion.