Posts Tagged ‘x-verification’
Thursday, November 12th, 2015
A few weeks ago I attended the “10 Years of IEEE 1800™ SystemVerilog Celebration” lunch at an IEEE Standard Association symposium. One of the Verilog/SystemVerilog world’s luminaries sat next to me, and he started talking to other luminaries about how his son, as part of a general engineering degree, was using SystemVerilog.
I had to ask: “With more of a software background, what’s his reaction to SystemVerilog? It must seem like a godawful mess.”
He said, “He used those same words.”
Several months ago, I wondered whether SystemVerilog was the most complex computer language yet invented, and I found this page on StackOverflow. The number of keywords may not be the best metric of language complexity, but it is simple and easy to calculate. According to this answer, COBOL (the Common Business-Oriented Language invented in 1959) has 357. SystemVerilog has 323. C#, Microsoft’s answer to C++ and JAVA, is a distant third with 102. If this answer is complete, nothing competes with COBOL and SystemVerilog. (more…)
Thursday, October 15th, 2015
At the Design Automation Conference in San Francisco, Real Intent did a survey of 201 visitors to our booth. We focused on RTL and gate-level verification issues. Below is a brief introduction and you can see the entire survey on the DeepChip.com web-site.
DAC’15 “When is your next design start?”
0-3 months : ########################################### (52%)
3-6 months : ###################### (26%)
6-12 months: ################## (22%)
These numbers are very similar to what was reported in 2012 on DeepChip. With half of the future design starts occurring in the next 3 months, this leads me to think design activity is remaining strong despite any EDA user consolidation we might have seen with the big mergers of various chip companies, and the slowing of the Chinese economy. However, the latest IC forecast from Gartner has 2015 growth falling from 5.4% at the beginning of 2015 down to 2.2% in July.
Thursday, October 8th, 2015
In this blog, we are presenting the highlights from Real Intent’s Fall 2015 Verification Newsletter. First are some thoughts from Prakash Narain, CEO, followed by an introduction to the new 2015 release of Meridian CDC for clock-domain and reset-domain crossing sign-off, and finally a review of our fall events including an ASICON tutorial.
Thoughts From Prakash Narain, President and CEO…
Most functional verification for SoC and FPGA designs is done prior to RTL hand-off to digital synthesis, since gate-level simulations take longer to complete and are significantly harder to debug. However, gate-level simulations are still needed to verify some circuit behavior. Unfortunately, X’s in gate-level simulations can cause differences in the RTL simulation output and the gate-level simulation output. X’s generally exist in all designs – it can be difficult to prevent this for practical reasons. Simulation results may be different because of X’s that are hidden in the RTL simulation by X-optimism, or additional X’s may exist due to X-pessimism in gate-level simulations. Pessimism can be fixed by overriding the simulator because you know that real hardware would always resolve to a deterministic value. The challenge is confirming that the X value is a result of X-pessimism and not simply X-propagation, and then forcing it to the right value at the right point in time so the simulation matches that of real hardware.
Thursday, June 25th, 2015
The propagation of unknown (“X”) states has become a more pressing issue with the move toward billion-gate SoC designs, and especially so with power-managed SoC designs. The SystemVerilog standard defines an X as an “unknown” value used to represent the state in which simulation cannot definitely resolve a signal to a “1,” a “0,” or a “Z.”
Synthesis, on the other hand, defines an X as a “don’t care,” enabling greater flexibility and optimization. Unfortunately, Verilog RTL simulation semantics often mask the propagation of an X value, while gate-level simulations show additional Xs that will not exist in real hardware.
The sheer complexity and common use of power management schemes increase the likelihood of an unknown “X” state in the design translating into a functional bug in the final chip. This possibility has been the subject of two technical presentations at the Design and Verification Conference during the last couple of years: I’m Still in Love With My X! But, Do I Want My X to Be an Optimist, a Pessimist, or Eliminated? and X-Propagation Woes: Masking Bugs at RTL and Unnecessary Debug at the Netlist. Let’s look more closely at this issue and the requirements for a solution.
Thursday, October 23rd, 2014
DVClub Shanghai took place on Sept. 26, 2014 with presentations by Real Intent, Solvertec, Mentor Graphics, Cadence, Synopsys and ARM. The theme of the meeting was “Making Verification Debug More Efficient.” Before I talk about two of the presentations that were recorded, here is some quick background on DVClub Shanghai which started at the end of 2013.
It was initiated by
The principle goal of DVClub is to have fun while helping build the verification community through quarterly educational and networking events. The DVClub events are targeted to the semiconductor industry in China, with a focus on design verification. Membership is free and is open to all non-service provider semiconductor professionals. Most members work in verification, but there are also plenty of entrepreneurs, students, managers, investors, and even design engineers who attend. There are at least 4 events every year: March, June, September and December.
Mike Bartley opened the event with a talk that was titled “Improving Debug – Our biggest Challenge?” If you follow the link you can see the recording of his presentation, where he talks about the 6 things that we need for improved debug.
My presentation was on “Shortening Debug with New Methods in Static Verification.” (more…)
Thursday, July 3rd, 2014
SoC companies are coming to rely on RTL sign-off of many verification objectives as a means to achieve a sensible division of labor between their RTL design team and their system-level verification team. Given the sign-off expectation, the verification of those objectives at the RT level must absolutely be comprehensive.
Increasingly, sign-off at the RTL level can be accomplished using static-verification technologies. Static verification stands on two pillars: Deep Semantic Analysis and Formal Methods. With the judicious synthesis of these two, the need for dynamic analysis (a euphemism for simulation) gets pushed to the margins. To be sure, dynamic analysis continues to have a role, but is increasingly as a backstop rather than the main thrust of the verification flow. Even where simulation is used, static methods play an important role in improving its efficacy.
Deep Semantic Analysis is about understanding the purpose or role of RTL structures (logic, flip-flops, state machines, etc.) in a design in the context of the verification objective being addressed. This type of intelligence is at the core of everything that Real Intent does, to the extent that it is even ingrained into the company’s name. Much of sign-off happens based just on the deep semantic intelligence in Real Intent’s tools without the invocation of classical formal analysis.
Thursday, June 26th, 2014
This article was originally published on TechDesignForums and is reproduced here by permission.
Reset optimization is another one of those design issues that has leapt in complexity and importance as we have moved to ever more complex system-on-chips. Like clock domain crossing, it is one that we need to resolve to the greatest degree possible before entering simulation.
The traditional approach to resets might have been to route to every flop. Back in the day, you might have been done this even though it has always entailed a large overhead in routing. That would help avoid X ‘unknown’ states arising during simulation for every memory location that was not reinitialized at restart. It was a hedge against optimistic behavior by simulation that could hide bugs.
Our objectives today, though, include not only conserving routing resources but also capturing problems as we bring up RTL for simulation to avoid unfeasible run times there at both RTL and – worse still – the gate level.
There is then one other important factor for reset optimization: its close connection to power optimization.
Matching power and performance increasingly involves the use of retention cells. These retain the state of elements of the design even if appears to be powered off: in fact, to allow for a faster restart bring-up these must continue to consume static power even when the SoC is ‘at rest’. So, controlling the use of retention cells cuts power consumption and extends battery life. (more…)