SVA Based Verification

Dear Readers,

In year of 2002, this was called as OVA (Open Vera Assertions). Later on Synopsys Inc had donated the Open VERA language to the Accellera committee to be part of System Verilog language. Several other companies made contributions for the formation of the new Systerm Verolog language. System Verilog language included the assertion language as part of the standard which is called as a “System Verilog Assertions” (SVA).

For verification engineers, main objective is “to verify the design under test (DUT)” thoroughly and make sure there are no functional bugs.

I have seen different approaches to develop test bench:
  1. Directed way of writing a test bench
  2. Constrained random test bench
  3. Semi randomize way of writing test bench

Main points while architecting any verification environments are given below:
- Simulation Generation
- Protocol Checking
- Data Checking
- Protocol Coverage
- Test Plan Coverage

If you see the history and figure it out, you could see, most of the Test benches which were developed before SVA were taking care of all above given categories. Later on when SVA introduced in System Verilog language and two categories, first Protocol Checking, second Protocol Coverage addressed by SVA. These two categories are closer to the design signals and can be managed more efficiently within SVA than by the testbench.

By connecting these assertions directly to the design, the performance of the simulation environment increases tremendously as does the productivity. Using this approach we can share information dynamically during the simulation.
We can not say that without SVA protocol and test plan coverage is not doable. People were doing those things when SVA was not invented!! I can say those parts are easy and effective using the SVA because of its strong constructs and features. For more details on coverage model and brief on Assertion please refer http://asicwithankit.blogspot.com/2011/01/coverage-model-in-system-verilog-test.html

References : A practical guide for system Verilog assertions, By Srikanth Vijayaraghavan, Meyyappan Ramanathan

Enjoy!
ASIC With Ankit

Ohh God ! Would this triggers a ‘Recession Blast 2011-12'?

Dear Reader's

Many of you might be knowing the recent hot news..... Any way let me give you a brief on it. "Recently John Chambers a CEO of CISCO has announce that they are going to fire 10,000 people from his organization from which thousands of them were expected to be gone at the end of August and rest of them would accept the buyouts". Isn’t it a shocking news?


I was shocked after hearing this news and end up with a deep though that “Would this action leads the industry towards the Recession?” We just came out from the global recession. We know that it went so bad that most of the people in this industry were affected one way or other way.

If we go and see the history of CISCO, we can easily see the growth and revenue of organization. Since talking over as CEO of Cisco in 1995, Chambers has grown the company’s revenue from $1 billion to more than $40 billion which shows his capabilities and business quality.

To me, revenue growth would not create the shareholder’s value. Anyone can ‘grow revenue’, especially through acquisitions. All you have to do to grow revenue is buy companies. Important part to create stakeholder’s value is ‘Grow earning per share’. If such kind of action would be taken by few giant companies, then surely our industry will be in crunch!

At the same time I was wondering when I saw few opening on Cisco’s career site. I was just wondering, at one side management is announcing firing and at the same time we can see hiring on its web page! It seems there is nothing to do with industries bad time. It just that organization might have taken some bad decision in past. So I don’t see any problem with current Industry.

If you see recent ASIC industry growth, engineers’ engagements with their clients, and consumer demands, I could see no problem for at least next two years. As we know electronics consumer demands are high now a days, companies has enough work and projections for at least next few years.

I would say this action would not lead this industry towards the Recession! what do you say ?

Enjoy,
ASIC With Ankit

Modelsim Vs Questa Features

Dear ASIC Readers,

We as an ASIC Engineer are frequently using different simulators for our simulation activity. At present time we are frequently using modelsim/Questa and vcs. These are the industry popular and well proven simulators.

I have seen people who are using modelsim / Questa simulator from Mentors but dont really know the exact difference between them.

I have captured some difference between Questa and Modelsim. Though both are simulators from the Mentor Graphics there are some differences between them

Below are the differences I captured :

ModelSim is Mentor Graphics HDL simulator. Questa is Mentor Graphics advanced verification platform that uses ModelSim as its core simulation engine.

Features of the two tools can be grouped into five categories and compared as follows:

1. Language Support
- ModelSim supports SystemVerilog IEEE 1800 for Design only, as well as VHDL (1987, 1993, 2002), Verilog (1995, 2001, 2005), as well as options for mixed language and language neutral licensing and support for SystemC 2.2 IEEE 1666/OSCI 2.2.
- Questa supports all of this as well as SystemVerilog IEEE 1800 for Verification, mixed language licensing (Questa is by default language neutral), PSL IEEE 1850, and SystemC 2.2 IEEE 1666/OSCI 2.2 as standard features.

2. Simulation
- ModelSim supports a single-kernel simulation engine, Verilog RTL & gate level performance optimizations, VHDL RTL & VITAL performance optimizations, performance and memory profiler, separate elaboration, waveform management tool set, VCD and extended VCD support, VCD re-simulation, batch mode simulation, integrated simulation, checkpoint & restore,

- Questa’s simulation support is identical to ModelSim’s

3. Design Entry, Debug, and Analysis
- ModelSim supports an HDL editor, integrated project manager, source code templates and wizards, interactive and post-simulation debug, dataflow graphical and textual causality traceback, source annotation, memory window, extra standalone viewer, multiple waveform windows, waveform compare, C Debugger and transaction viewing for SystemC.

- Questa supports all of this and the C debugger and transaction viewing for SystemC and SystemVerilog are standard parts of the product.

4. Advanced Verification Methods
- ModelSim does not support any advanced verification features.
- Questa supports assertion-based verification (including a library of pre-written assertions called Questa Verification Library or QVL, and an assertion thread debugger), automated test stimulus generation via a constraint solver engine, and PowerAware RTL verification supporting both CPF and UPF formats.

5 Verification Management and Coverage
- ModelSim supports Code Coverage (it is included in ModelSim SE, and an option to other versions of ModelSim).

-Questa supports code coverage along with functional coverage, a unified coverage database (UCDB), coverage viewing, test ranking, and test plan tracking

Hope you find this information useful.

Enjoy reading...!
ASIC With Ankit

Coverage model in System Verilog Test Bench

Dear All,

I am back after a long time ! Here I would like to share my experience on coverage model in System Verilog..

There are different ways to define verification plans, I have worked with different organization where I have been involved in verification activities with different approaches. There are two main questions which each verification engineer needs to take care, which are “What to verify” and “How to verify”. I would try my level best to explain it in details with my experiences. Hope you enjoy this technical writeup.

Success of a verification relies heavily on the completeness and accurate implementation of a verification plan. A good verification plan contains resource usage and estimated schedule.There are different ways to define verification plans, such as a spreadsheet, a simple document or text file in some cases. It depends on company to company as way of following a process may be different.

What to verify and how to verify are the major two things which each verification engineer has to think before starting actual verification.

First of all engineer has to clearly defined features to verify in feature extraction phase. And then after defining what exactly need to be verified, engineer has to define how to verify them.

There are two approaches in current industries to make sure that verification is done using Assertions and Functional Coverage. You might have heard about the different methodologies like CDV, RVM, VMM, AVM, OVM and UVM etc... Methodologies are nothing but a flexibility for verification engineers. Using methodologies engineer can reuse and and utilize the power of base classes and the features in a different way. Its a beauty of each methodologies we have been using. I am not denying the that without methodologies we could not make sure on confidence of verification environment, we could. As we know now a days SoCs and ASICs are becoming complex and complex each day, verification engineers ending up with thousands of scenarios with complexity of environment, so in this case methodologies have helped us in utilizing the power of features and functionality of methodologies. I have worked on RVM, VMM and OVM too... I have realized that each methodologies have their own strong features and re-usability. Any way, I would try my best to come up with an detail writeup on methodologies ! Hope I should be able to come up soon :-)

As I have mentioned there are two approaches in current industries to make sure that verification is done. Those are 1. Assertions 2. Coverage. Thats where AIPs (Assertion IPs) and VIPs (Verification IPs) came in to picture.

1. Assertions :

Assertions are primarily used to validate the behavior of a design. ("Is it working correctly?") They may also be used to provide functional coverage information for a design ("How good is the test?"). Assertions can be checked dynamically by simulation, or statically by a separate property checker tool – i.e. a formal verification tool that proves whether or not a design meets its specification. Such tools may require certain assumptions about the design’s behavior to be specified. There are two types of Assertions:

Immediate Assertions:

Immediate assertions are procedural statements and are mainly used in simulation. An assertion is basically a statement that something must be true, similar to the if statement. The difference is that an if statement does not assert that an expression is true, it simply checks that it is true, e.g.:

Concurrent Assertions :

Concurrent assertions are used to check behaviour such as this. These are statements that assert that specified properties must be true. 

2. Coverage Model :

As I have explaing above that SoCs and ASICs are becoming complex and complex each day ! The main concerns for industries are :

1. How do they close verification ?
2. How can they say , they are done ?
3. How can they make sure they have stimulated each possibilities ?

To answers these questions, they came up with languages called system verilog with the concept of functional coverage. This concept is mainly used to make sure accurate configuration.

All our current day methodologies have brought in the concept of re-usability of the agents such as BFM’s and monitors across projects. An engineer also creates a coverage model in order to provide the management with a picture of the verification activity status.

Using the strong constructs called covergroup, coverpoint, bins, cross coverage and class concept engineers are easily develops coverage model to generate functional covergare report after they run each simulation. Coverage reports gives us a lot of information in detail in pictorial view as well as in text formate too (based on the tools which you are using).

Its very important and individual should write functional coverage very accurately. I have mentioned some tips on writing functional coverage. Please read my article http://asicwithankit.blogspot.com/2010/03/dont-rely-on-illegalbins-for-checking.html (has been published by two most popular websites testbench.in and asicguru.com)

Hope you have enjoyed this article ! Please shoot me an email or post a comment if you have good thought on this point or you have any questions which you want to discuss.

Enjoy !

ASIC With Ankit