Verification Update

Let's talk about methodology.
In many methodologies that are in use today by customers we find that engineers in the companies have specific tasks. There are engineers that are architectural level folks, engineers that are hardware implementation level folks, verification engineers and software engineers. These folks tend to stratify in terms of what abstraction level they work at. They talk to each other at these abstraction levels.

Software engineers talk to SoC architects but very rarely talk to verification engineers. They really have nothing to talk about. Verification engineers talk to hardware engineers but very rarely to SoC architects. This leads to misinterpretation of specifications, misunderstanding, incomplete things and so on. You find that the kind of bugs that creep through the verification process today and there is a range of them but you find that the really painful ones are ones that miss cross communicating between high level of abstraction and lower level of abstraction, especially today with the amount of reuse going on.

One of the goals we had in designing AVM is to have folks in these various jobs - higher level of abstraction people and lower level of abstraction people - to be able to communicate with each other around what the specifications are and what a particular design is supposed to do in terms of meeting these specs.

What is AVM?
One of the essential features of AVM is the way of handling abstractions, the way of allowing people to move between levels of abstraction in their designs seamlessly. We believe that AVM will lead to the industry's first system level to gate level verification methodology.

AVM has been designed not only with SystemVerilog in mind but also SystemC. SystemC in the industry is a language that is heavily used for testbenches. There is no sense in going to the designers in the industry and saying you have to rewrite all of your SystemC in SystemVerilog. One thing we have learned about moving things forward in the industry is discontinuity is difficult for people to accept. You need to build bridges to get them from where they are to where they want to go. You have to keep their business on the air. So AVM embraces both SystemC and SystemVerilog.

The point about abstraction layers is that AVM is built upon an object oriented technology plus transaction level modeling (TLM). TLM is the key in the abstraction adaptation layer. In AVM we cover stimulus generation, assertions and coverage. Coverage is another key point. We have a how to guide, examples, base class libraries and utilities. We make all that available in source code. We use open-source licensing. This means that you do not have to strictly be a Mentor customer to use AVM. If you want to use a simulator from a competitor or use your own proprietary simulator, you can pick up AVM and use it in your environment. There is licensing. We use Apache 2.0 license which is a very gentle open source licensing approach. The reason we want to make it available in source code and with open source license is that we would like to create a community in the industry that pushes this methodology forward. One of the things I believe is that EDA companies do not invent methodologies. I believe that the only people that really invent methodologies are end users. Therefore we are trying to create an infrastructure to kick start a user community to develop methodologies that will then move the entire industry forward.

Proprietary methodologies generally fall flat on their faces sooner or later. The real methodological changes in the industry have always been motivated and promoted by user companies. Synchronous design is that design style that enabled the move from gate level to RTL simulation and also enabled the advent of RTL level synthesis. Synchronous design was motivated by the end user community. That's the theory behind AVM.

What are the properties of AVM?
It makes a verification team more efficient and more effective. When you write less code, you find more bugs. Reusability is one of the best ways to get efficiency into your operation. Because AVM relies on TLM you can see why you can write reasonable code. We also reuse SystemC so that you do not have to rewrite your testbenches from scratch. It has in it all the classic stuff like constrained-random testing and assertions to broaden bug search. There are AVM libraries for common tasks. You don't have to write serializers and deserializers. It is quite a rich library of systems services. We deliver examples of testbenches that have certain properties. You might have a testbench aimed at a device with 8 serial channels. You might have a testbench aimed at very transaction rich and control rich chip. Those are handled differently. We have examples of these testbenches that you can actually use and incorporate into you verification environment as a starting point for advanced testbench in SystemVerilog.

A high level model is transaction level model that deals with packets and is concerned with throughput and latency. A low level model is a detailed pin level of the device under test (DUT) sending waveforms, 1's and 0's. It is concerned with setup time, hold time and various low level transactions. It would be very good in both cases that you would not have to rewrite your test benches. The way you can do that is by using abstraction adaptation layer, abstraction conversion layer that will take packets and convert them to pin wiggles when you need them to be pin wiggles. If your DUT is a high level model you don't need that. You need something that basically generates packets. It is complicated to explain.

It is a key point. It is what sets the AVM apart from other verification methodologies in the industry like Synopsys VMM which does not have this concept in it. We believe that this concept is pretty unique in the industry and will make a significant difference to the efficiency and effectiveness with which people can verify their design.

We believe that AVM is a bite sized methodology that allows you to implement incrementally. You do not have to swallow the whole thing. I go back to the statement I made that to get people to go from where they are to where they want to be you have to provide a path for people to follow that is smooth and prevents them from falling off cliffs. One of the design goals of AVM was to give people a way of starting with SystemVerilog without having to take a year off to reeducate themselves. You can use object programming which SystemVerilog supports or you can use standard old HDL with SystemC and make incremental changes to your testbenches. AVM has the property that you can use both object oriented and HDL-style constructs. You can mix and match.

Are there any competitors out there?
Synopsis VMM (Verification Methodology Manual)! In terms of access AVM is open, VMM is closed. We can execute AVM with confidence on any SystemVerilog simulator. With Synopsys VMM it is closed, you have to be on VCS. With AVM source code is available, with VMM it is not. Both have base libraries. AVM is TLM based which includes this abstraction adaptation layer. We believe that is unique and we believe it is one of the key things that you have to do to make progress in verification. If you don't do that, I believe that you will find that your testbenches are not serving you well. You will not be able to use them to validate things at the system level. We support SystemVerilog and SystemC to RTL. The use model is hybrid in contrast to VMM which is class based. VMM has been in the industry for a while. AVM is relatively new. We have done some learning in the industry as to what works and what doesn't. We have had the benefit of people using previous methodologies and getting their comments and their suggested improvements. AVM is really a second generation methodology. VMM is first generation.

Any other competitors?
Not really. Our friends at Cadence have been silent on that topic which is quite curious. We are getting some indication that something maybe be coming. What we understand is that it will be more than likely aligned with AVM and not VMM. So there are only these two things in the industry right now that we know of. There are a bunch of smaller things like Spiratech in the UK that talks about tools to automatically generate transaction level models. But that is not an entire methodology. It is something very local. I think AVM and VMM are unique.

« Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7  Next Page »


Review Article Be the first to review this article

ClioSoft at DAC

Featured Video
Senior Electrical Engineer for Allen & Shariff Corporation at Pittsburgh, Pennsylvania
Upcoming Events
DAC 2018 at Moscone Center West San Francisco CA - Jun 24 - 28, 2018
Symposium on Counterfeit Parts and Materials 2018 at College Park Marriott Hotel & Conference Center MD - Jun 26 - 28, 2018
Concar Expo 2018 at Convention Hall II Sonnenallee 225 Berlin Germany - Jun 27 - 28, 2018
Nanotech 2019 at Tokyo Big Sight East Halls 4-6 & Conference Tower Tokyo Japan - Jun 30 - 1, 2018
ClioSoft at DAC

Internet Business Systems © 2018 Internet Business Systems, Inc.
25 North 14th Steet, Suite 710, San Jose, CA 95112
+1 (408) 882-6554 — 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 PolicyAdvertise