Robert Eichner’s presentation at the Verification Futures Conference
Robert Eichner’s presentation at Verification Futures:
The Race For Better Verification
| Graham Bell|
Sr. Director of Marketing of Real Intent
Improving quality requires smarter debug reporting and tools that can find and fix those errors more quickly.
SoC verification is gearing up for renewed competition among the big vendors and verification-only companies like Real Intent. They are delivering their next-generation SoC verification suites with a focus on specific areas of concern. Clock-domain crossing, X-verification and reset optimization, SDC correctness and consistency, are some of the areas that are receiving dedicated RTL analysis using static analysis. Static analysis is a mix of structural and formal techniques that let designers focus on verification and not on customizing the tool to attack a problem area.
Besides raw speed, and capacity, the newest tools are addressing the data management for sign-off of these SoCs. Smart reporting and assisted debug is a key requirement otherwise designers and verification teams will drown in a flood of analysis results. All of this innovation and targeted investment will be making SoC sign-off manageable, if not easier.
Recently, I saw the importance of having smart debug reporting in the results of an evaluation of Real Intent’s Ascent IIV tool by NEC in Japan.
Ascent IIV is an automatic RTL verification tool. Since no testbench is needed, it is an efficient method to find RTL bugs earlier in the design flow before they become more expensive to uncover. It finds bugs using a hierarchical analysis of design intent. The analysis tries to distinguish what is the root cause for issues to minimize debug time. When the tool is launched, Ascent IIV performs a comprehensive analysis of each of the design elements in the RTL code to generate functional assertions or what we call intent checks. These intent checks are then analyzed by an array of engines to verify a design’s functional behavior.
Like other automatic formal tools in the marketplace, Ascent IIV handles a wide range of intent checks:
- FSM deadlocks and unreachable states
- Bus contention and floating busses
- Full- and Parallel-case pragma violations
- X-value propagation
- Array bounds
- Constant RTL expressions, nets & state vector bits
- Dead code
- Uninitialized memory
In the following table you will see the results of the analysis of Ascent IIV on 130K gates of RTL logic that was done by NEC in Japan.
Table 1. Ascent IIV Intent Checks and Failures Report for a 130K Gate Block.
The tool generated 31,186 intent checks (assertions) that were analyzed by its various engines and 2,999 failures were produced in total. The hierarchical reporting of the tool characterized these failures into several categories. It determined that by fixing the Primary Errors (purple column in the table) this would eliminate the duplicate, secondary and many structural errors. In this benchmark, 181 primary errors were identified. This represent a dramatic contraction of almost 95% of the total failures from the tool. For further comments by NEC, you can read them here.
Smart reporting is a now an important and necessary component of RTL verification and SoC sign-off. With the ever growing complexity of verification we need more leverage in finding and fixing those errors that will make the biggest impact on design quality.
Experts at the Table: The Future of Verification – Part 2
| Graham Bell|
Sr. Director of Marketing of Real Intent
Ed Sperling, editor in chief of Semiconductor Engineering sat down with Prakash Narain, CEO of Real Intent, and other industry experts to discuss The Future of Verification. In Part 2, presented here below, Narain considers how implementation issues are affecting functional verification.
Experts At The Table: The Future Of Verification Part 1
| Graham Bell|
Sr. Director of Marketing of Real Intent
Ed Sperling, editor in chief of Semiconductor Engineering sat down with Prakash Narain, CEO of Real Intent, and other industry experts to discuss The Future of Verification. In Part 1, presented here below, Narain explains why he is ” very happy that verification continues to be a problem.”
Video: Orange Roses, New Product Releases and Banner Business at ARM TechCon
| Graham Bell|
Sr. Director of Marketing of Real Intent
Real Intent was exhibiting at ARM TechCon on Oct. 30 – 31. We gave away 100 orange roses at our booth in celebration of Halloween, and in anticipation of Diwali on Nov. 3.
Orange Roses Giveaway for ARM TechCon
Sanjay Gangal of Internet Business Systems interviewed me at the show as well. In the following video, I spoke about the new releases of the Ascent Lint tool and the Ascent X-verification system and some hints about our upcoming business announcement for our fiscal year that just ended. Enjoy.
Shubh Diwali and remember Veterans Day on November 11.
Minimizing X-issues in Both Design and Verification
| Lisa Piper|
Technical Marketing Manager at Real Intent
The propagation of unknown (X) states has become a more pressing issue with the move toward billion-gate SoC designs. The sheer complexity and the common use of complex power management schemes increase the likelihood of an unknown ‘X’ state in the design translating into a functional bug in the final chip.
This article describes a methodology that enables design and verification engineers to focus on the X states that represent a real risk, and to set aside those which are artifacts of the design process.
The idea is to reduce project time, particularly that spent in simulation, and overcome the limitations inherent in high-level techniques at both RTL and gate level.
Billion gate designs have millions of flip flops to initialize. Many of the IP blocks used in such designs also have their own initialization schemes.
It is neither practical nor desirable to wire a reset signal to every single flop. It makes more sense to route resets to an optimal minimum set of flops, and initialize the rest through the logic, but this is a significant RTL coding challenge.
The analysis of any system with such a reset and initialization scheme is bound to throw up many Xs. The issue is in knowing which ones matter, since dealing with unnecessary Xs wastes time and resources. However, missing an X state that does matter can increase the likelihood of late-stage debug, cause insidious functional failures and ultimately, respins.
Today’s power schemes further complicate the analysis of X issues. Blocks that are subject to power management have additional flops to retain state across power-state transitions, and any analysis of their reset structures must be undertaken dynamically. Interaction between blocks in different power states must also be considered.
Two simulation phenomena work against us in this respect.
X-optimism is primarily associated with RTL simulation, and is caused by the limitations of HDL simulation semantics. It occurs when a simulator converts an X state into a 0 or a 1, creating the risk that an X causes a functional failure to be missed in RTL simulation.
X-pessimism is primarily associated with gate-level simulation of netlists (though it can also occur in RTL simulation). As its name suggests, it happens when legitimate 0s or 1s are converted into an X state. This can lead to precious debug resources being directed toward unnecessary effort. Additionally, after synthesis has done its work, debug at the gate level is more challenging than in RTL.
Core methodology principles
Any methodology to handle X issues efficiently must focus on solving the problem in RTL, using tools and methodologies that can be applied to RTL simulation. Gate-level simulation is slow and will tend toward X-pessimism. Any real bugs uncovered at the gate level will be more difficult and time-consuming to fix than in RTL.
Assuming a focus on RTL, the next desirable feature of the methodology would be that it addresses the different skills and requirements of design versus verification engineers.
Real Intent has discussed X issues with customers and while both types of engineer share the same overall concerns – avoiding X-propagated functional bugs and catching them as early as possible – they have different perspectives.
Many design engineers now work with strict guidelines aimed at achieving X-accurate coding. This is a delicate task that requires further automation, but it can catch a good number of X issues early. The designer’s priority is to know where the X-prone regions of the RTL may be.
In contrast, a verification engineer typically thinks about controlling the amounts of X-optimism and X-pessimism at each stage of the verification flow.
Finally, the methodology needs to accept that there is no single practical technology that will deliver the quickest and most accurate X-analysis in all cases. For example, formal analysis techniques such as model checking and symbolic simulation can be a big help, but they face capacity challenges (such as memory usage).
A successful methodology to handle X propagation must therefore combine several techniques, balanced to deliver thorough results in the best available turnaround time.
Figure 1 shows the methodology Real Intent has developed based on our Ascent XV tool suite.
The methodology tries to capture relevant X issues as early as possible in the design flow, and has separate phases that are design-centric and verification-centric.
The first thing a designer wants is to minimize the number of X-sources that exist. The methodology first identifies where Xs might originate. Appropriate structural analysis looks at the characteristics of the RTL to identify potential sources. Lint tools can flag hazards such as explicit X-assignments, signals within a block that are used but not driven, out of range assignments, and flops that don’t have a reset signal, to name a few.
However, structural analysis cannot determine whether a real X-issue exists, and does not include any sequential analysis. The Ascent XV methodology uses sequential formal analysis to determine the baseline list of uninitialized flops, and then suggests additional flops, that if reset, would lead to complete initialization.
The creation of the hazard report is therefore augmented by using formal techniques to result in a more precise list. The designer can then manage and respond to this list as appropriate.
Designers also want to identify which X-sources can propagate to X-sensitive constructs.This portion of the flow uses automation to trace X-source propagation through X-sensitive constructs. It then presents the results in a hazard report, which is focused on relevant constructs using a number of static techniques in the simulation context.
Customer conversations revealed that verification engineers tend to focus on X-optimism and X-pessimism in their efforts to manage X-propagation.
In the Ascent XV methodology, X-accurate modeling is used to address both, and existing simulation checkers then help to detect functional issues. This is done in a way that does not touch the user’s code and is easily integrated. The performance overhead of the X-accurate simulation is strictly controlled.
Once an issue is discovered, the verification engineer needs further information to isolate the cause. For this, it is useful to know which signals were sensitive to X-optimism and which control signals had Xs.
The methodology uses the simulator’s assertion counters to track statistics for these signals. Monitors can then print a message the first time a signal is flagged as sensitive to X-optimism, which is useful for determining its root cause.
An important constraint here, though, is that the monitor does not slow simulation to a crawl by offering a print every time a flag is raised. The aim is to provide a readout so that the verification engineer knows where to use waveform analysis and trace a signal back to its source.
This X-accurate modeling can be used at both the RTL and netlist levels though, again, the emphasis is on undertaking appropriate simulation at as high a level as possible.
Pragmatism and balance is as important as the power of the technologies used in addressing X-propagation in today’s complex designs.
The methodology outlined here targets a specific but important problem. It aims to ensure, through its use of tools such as Ascent XV, that design and verification engineers can focus their resources on avoiding and fixing bugs, minimizing design turnaround time.
A more detailed discussion of the Real Intent methodology discussed here and the various technologies available to combat X-propagation can be found here.
There’s more on Real Intent’s Ascent XV X design and verification system here.
Value of a Design Tool Needs More Sense Than Dollars
| Rick Eram|
Director of Sales and Field Operations at Real Intent
It is interesting when I talk to purchasing managers at semiconductor companies and they use the dollar cost for a tool as the measure of its value.
Tool value can be hard to quantify and a price tag will not tell the whole story. The real cost behind any tool is the engineering effort to use the tool and the real time-saving and efficiency it brings to design teams.
The Meridian CDC solution from Real Intent, for example, is often compared to tools from other vendors. When technical decision makers are involved, the value is very obvious since they can quantify the difference in effort.
It takes much less time to debug the results. Why? Because Meridian CDC analyzes the complete interface of the crossing and it reports how data and control crossings are associated. This generates dramatically fewer violations for review, despite the fact that all analysis rules are always turned on. Needless to say, having all rules on all the time helps in NOT missing design bugs.
Because of the fast analysis run-time, combined with the low-noise reporting feature of the tool, each iteration for CDC violations is much faster than other tools. As a result the cost of engineering time is much less.
As an example, one of the popular CDC tools generated 130K messages on a design about 10M gates in size. Once the rule set was “optimized” (codeword for watered down) the messages dropped to a mere 20K. Then tinkering with the setup got it down to 8K. Now imagine sitting in front of the screen and trying to go through 8k messages. Don’t forget you may have missed something all together because some rules were turned off to keep the noise down.
So now the designer has to sort through 8K messages, costing productivity, next he has to run it again and wait for results, costing more time. Now if the setup is not right or needs to be further tuned; the process is repeated, and again more waiting for the results and more cost. I think you get the picture. This is not even counting which way the tool may steer you and why using a simple setup may require more fine tuning later on.
Ah, almost forgot! Some of the vendors use a hierarchical analysis as a crutch to help painfully slow algorithms or to manage capacity. So black boxing or “abstract modeling” are promoted as the solution, which most engineers knows that accuracy is sacrificed and there is a loss of information in a block-level model. Again the risk of missing design bugs because of the inability to analyze CDC bugs at the full chip level, is greater.
So in short, reducing rules to run, or using abstract models is the prescription for added respins and cost, not to mention the risk of having a dead SOC.
So, The real cost of CDC is not the tool cost but the risk and effort put into the analysis process by using a tool that cannot scale to the necessary complexity of design analysis .
For those who want do a hierarchical analysis without compromises check out the loss-less approach from Real Intent and find out why it gives results that are the state-of-the-art.
Looking at the cost of a tool and comparing it to others might be a fair comparison if the tools are equivalent in performance and usage. However, the next generation of design analysis tools that have the speed, coverage and targeted debug to handle the most complex SoC designs are invaluable to design teams. You cannot afford to put up with slow and noisy analysis that can let bugs slip through to tapeout.
Graham Bell at EDA Back to the Future
Real Intent’s Vice President of Marketing Graham Bell at the EDA: Back to the Future dinner and auction at the Computer History Museum:
The Secret Sauce for CDC Verification
| Graham Bell|
Sr. Director of Marketing of Real Intent
Advanced semiconductor processes have made it possible to integrate hundreds of millions of gates of digital logic on a die. What has made this practical, however, has been the shift to block-based design, in which many large functional blocks from a variety of sources are quickly integrated into a new SoC. Without the ability to reuse design blocks, it would be impractical, and perhaps even impossible, to take full advantage of the capabilities of an advanced process in any reasonable timescale – designing all that functionality from scratch is simply too complex.
What abstraction to the block level gives with one hand it tends to takes away with the other. Even if each block can be relied upon to behave properly within its boundaries, a complex SoC design attempts to integrate and then coordinate many such blocks, despite the fact that each may have been designed by a different group using a different strategy. Each block, for example, may expect a different clock rate, may dynamically adjust its clock to match its workload, and may employ sophisticated clock-gating strategies to minimize power consumption.
How bad is the problem becoming? According to a survey last year, 32% of SoC designs underway among those surveyed employed 50 or more clock domains. SoC designers, therefore, are faced with trying to ensure that their systemic and inter-block clocking strategies work as expected, even as thousands of signals pass between tens or even hundreds of different clock domains. Add in power-management strategies that turn blocks on and off to minimize energy use, and therefore leave signals at block boundaries in undetermined states, and complex external interfaces which introduce their own clocking requirements, and the potential for errors multiplies.
What sort of errors can occur? Clock domain crossing (CDC) bugs can happen when a signal crosses from one asynchronous domain to another, and arrives too close to the receiving clock edge, so that the captured value is non-deterministic due to set-up or hold-time violations. This metastable state results in incorrect values being propagated through the design, causing functional errors. The problem with such errors is that using standard methods to track them down, such as simulation or static timing analysis, doesn’t make sense because the failures arise due to corner-case combinations of timing and functionality that can make them unpredictable and intermittent.
Some of the tools used to tackle such bugs have limited capacity, which can force designers into partitioning their SoCs artificially, so that each sub-block can be handled within the tool’s capacity. Other methodologies produce so many false positives that their diagnostic value is self limiting – there are just too many potential errors to consider.
Our current thinking is that designers need a configurable solution, which uses both structural and formal analysis to ensure that signals which cross between domains on both ASICs and FPGAs are received reliably. Such a tool also needs high capacity and to work hierarchically, so that a design can be partitioned for analysis in a way that matches the original design intent, but doesn’t sacrifice top-level, full-chip precision on extremely large designs.
If we can get this right then we have a chance of helping designers tackle the new class of issues that has emerged as chip design has evolved into a block-integration challenge.
Clean SoC Initialization now Optimal and Verified with Ascent XV
Three weeks ago, I shared a video interview of Pranav Ashar talking about how SoC Sign-off Needs Analysis and Optimization of Design Initialization in the Presence of Xs. Last week Real Intent announced the latest release of its Ascent XV that address this new sign-off concern.
Analysis and optimization of design initialization in the presence of X’s is a new requirement for SoC sign-off due to modern power-management schemes. Ascent XV provides the necessary analysis of initialization sequences to ensure they are complete and optimal for various power states in an SoC. It provides the same best-in-class verification performance and debug efficiency as our other Ascent products, uncovering issues prior to digital simulation and synthesis.
Ascent XV identifies X-sources and potential X-propagation issues early-on in Verilog RTL or netlist designs. It enables the detection and debug of functional issues caused by X-optimism at RTL, prior to synthesis. It also eliminates unnecessary X’s caused by X-pessimism at the netlist. Ascent XV analysis can catch issues prior to RTL sign-off, driving costs down and avoiding monotonous, error-prone debug at the netlist level.
Notable features for the new Ascent XV release include:
- Initialization analysis that reports flops and latches uninitialized after the reset sequence
- Reset and retention-flop optimization that ensures complete initialization with minimal hardware and routing requirements for savings in area and power
- Hazard analysis that reports design susceptibility to X-hazards, and automatically detects and reports all X-sources in the design
- SimPortal that enables Verilog simulation to detect and debug real X-optimism issues, and to model low power retention cells at RTL
- A debugger that correlates X-optimistic and X-pessimistic signals to X-sources
Find out more about Ascent XV here on the Real Intent web-site.