May 29, 2006
Verification Update
Please note that contributed articles, blog entries, and comments posted on are the views and opinion of the author and do not necessarily represent the views and opinions of the management and staff of Internet Business Systems and its subsidiary web-sites.
Jack Horgan - Contributing Editor

by Jack Horgan - Contributing Editor
Posted anew every four weeks or so, the EDA WEEKLY delivers to its readers information concerning the latest happenings in the EDA industry, covering vendors, products, finances and new developments. Frequently, feature articles on selected public or private EDA companies are presented. Brought to you by If we miss a story or subject that you feel deserves to be included, or you just want to suggest a future topic, please contact us! Questions? Feedback? Click here. Thank you!

When was Questa first released?

We announced Questa as the first SystemVerilog simulator in the world at the DAC conference. This year Questa 6.2 is coming out with a much more complete feature set, a very stable tool. We are announcing it in time for the DAC conference.

Questa itself works all the way from a specification level down to the gate level. It has links to MathLab. It is a five language simulator (SystemVerilog, Verilog, VHDL, PSL, and SystemC) plus C and C++). It is a single kernel simulator. That means all of these capabilities will execute with minimal overhead. Questa has a simulator, a constraint solver, an assertion engine and a function coverage engine. What we believe is unique about Questa 6.2 is the way it handles coverage. We are pretty excited about this.

The other thing is performance. As you know every simulator release has to come out with the simulator running a little faster because of course the circuits being worked on are a little bigger. We have more performance. We have a new optimization engine in there called vopt. We have seen designs that have been accelerate up to 10X using vopt. Vopt, typical of optimization engines, extracts the piece of designs where they are not interested in poking into certain aspects of those circuits. Those things are abstracted out. We have way more debugging in it so we can debug TLM and assertions. We can debug cause and effect relationships. We have a 5 language native verification
environment. And of course Quest 6.2 executes AVM.

We believe that coverage is really that thing that helps verification and design engineers become more efficient. What you need to be able to do is gauge what impact your testbench is having on your design. If you are applying stimuli from your test bench that is not covering new aspects of your design, you are really wasting your time. You have to be able to tell what the testbench you are executing is doing to your design, what it is covering and not covering. In Questa 6.2 we have automated a great deal of that. SystemVerilog has covergroup and coverpoint statements and things like that. If you use these statements properly, you will get a good snapshot of what is going on in your
circuit relative to what the testbench is simulating. You can get to the point where your testbench can query coverage metrics in order to make choices about what vectors it generates next or what path it will take on the next execution cycle. It answers questions like “How much of my test plan is covered?” The test plan is a high level document that says you will check for FIFO overflow, check for clock recovery … Then when you write your testbench, you have to relate what your testbench does to your design back to your test plan. Did I or did I not cover FIFO overflow? Did I or did I not cover clock recovery error?

Where does coverage come from?

Inside the Mentor system you have several choices on where coverage comes from. Part of your coverage can come from formal analysis. You might have a block in your circuit and the best way to cover this piece of the circuit is to use static formal. Once I use static formal, I know that this block is correct. I would like to enter data about the fact that I have covered this block into a coverage database. The other places where you can create coverage is through the simulator. The simulator will tell you which assertions fired and which didn't. It will tell you which parts of your code executed. Your testbench further tells you what kind of functional coverage you have. You can see
that coverage is not one simple thing. Function coverage, assertion coverage, code coverage and plain old coverage coverage.

We are introducing as part of Quest 6.2 a new Unified Coverage Database (UCDB). It has a read and write API that allow users to customize the reporting. What happens with UCDB is that all the coverage metrics are put into a high performance database in real time while the simulator or formal is running. Thus for example you might kick off a regression run on Friday. The regressions runs all weekend. On Monday morning the manager of a large SoC gets a report on his desk to understand what happened with those regression tests. Did all the changes that were made last week in the chip result in more or less bugs and what is the actual coverage?

UCDB is a very high performance database. It allows more than 1,000,000 insertions per second. The read and write APIs allow users to create other fields, tag things, tie things together with scripts and what ever else they want to do. We are creating an environment that allows people to understand what their coverage is, what is left to cover on the chip, and things like that. One of the problems we have in the industry today is that generally verification stops when somebody says it is time to tapeout rather than when someone says that I have enough coverage. I think that leads to respins and a whole bunch of heartache. We believe that if people have the ability to understand their
designs and what has been covered, they will do a much better job.

Using UCDB you will be able to identify coverage holes. Graphical printouts tell you out of the coverage you wanted to have done how much is in fact done and how much is not done; color coding for people to key in on. You can tie the UCDB output back to the test plan. You can review a test plan and see that you have covered everything you want. You no longer have to test a particular module for those things because you know that stuff has been tested.

Infrastructure helps the industry make a transition to SystemVerilog. We are announcing the Vanguard Program, a group of companies from around the world working closely together to accelerate the adoption of advanced verification techniques and methodologies. There are a range of companies offering services in training, consulting, conversion and verification IP. All that we require to join Vanguard is that whatever they create has to support AVM and Questa. It can support anything else but at a minimum they have to be able to execute in the Questa environment and be compatible with AVM.

The list of companies includes Sutherland HDL, Willamette HDL, Denali, Averant, and Spiratech. It is a good start in the industry. It is important that customers have an ecosystem otherwise it is very difficult for them to make rapid progress. We are offering this to the industry as a way of motivating the adoption of SystemVerilog.

When was Questa first introduced commercially?

Last year just before the DAC conference (May 2005).

How many customers or seats are out there?

That is something we not specifically publish. But I can tell you that 30% of our deals have Questa in it. That doesn't mean that 30% of our sales are Questa. I think the question you are asking is how much penetration and how many people have started using Questa in the marketplace. We find it interesting that 30% of our deals have Questa in them. There is a percentage of our customers that have now converted to SystemVerilog. The problem we have in understanding the metrics is that no large company has made a wholesale shift. We have a lot of startups, generally in the Bay Area and in the Valley. A new startup company with no legacy can make a choice about going full tilt with
SystemVerilog. We have quite a few startups that take a SystemVerilog route and are quite successful at it. We know how many licenses that are out there but the metric itself doesn't mean a heck of a lot. So we haven't published that number.

Has the methodology been tested out with any customers of significant size?

Yes. In fact it has. My statement that the EDA industry does not generate methodologies is absolutely true. So the methodology AVM is not something developed in a vacuum. It was developed with several lead customers. In the press release there is a quote from one customer (HDL Design House) who was a pretty close partner for us. AVM has been out in the industry in both alpha and beta format for about 9 months. What you are seeing is AVM 2.0. This is really a methodology that has made the rounds through the industry. We have been very quite about it, but it has seen real use.
The problem with developing a methodology as an EDA company is that we don't earn our living by designing chips. We earn our living by helping people design chips. The methodology really has to come from the user community. What we have done is found people at the leading edge of things, who have experience with methodologies. They have been the ones to advise us what to do. We have done our homework well and have been able to package up the best ideas in the industry on how these things ought to be done.

You can find the full EDACafe event calendar here.

To read more news, click here.

-- Jack Horgan, Contributing Editor.


Review Article Be the first to review this article


Featured Video
Manager, Field Applications Engineering for Real Intent at Sunnyvale, CA
Upcoming Events
SEMICON Europe at Grenoble France - Oct 25 - 27, 2016
ARM TechCon 2016 at Santa Clara Convention Center Santa Clara CA - Oct 25 - 27, 2016
Call For Proposals Now Open! at Santa Clara Convention Center, Santa Clara, CA California CA - Oct 25 - 27, 2016
DeviceWerx - 2016 at Green Valley Ranch Casino & Resort Las Vegas NV - Nov 3 - 4, 2016
S2C: FPGA Base prototyping- Download white paper
TrueCircuits: IoTPLL

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:
AECCafe - Architectural Design and Engineering TechJobsCafe - Technical Jobs and Resumes GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy