ASIC Verification - Why?

Why ASIC Verification??

People have different approaches for ASIC Verification, but in simple terms "Verification is checking whether the design specification is brought into reality or not". Though today we are in a very fast, competitive, change emerging world where in hourly basis many companies are coming up with new tools and languages, but it solely depends upon users choice which method and language to adapt for his/her design verification environment to turn his/her black and white assumption to a meaningful chip and to promote people using the Chip-Set in various gadget. Though there are many gadgets in the market, companies need to consider the powerful pack of sleeky, user-friendly, all in one, stylish, resolution, clarity, speed and something unique features to attract the people and to survive in this competitive world of Conquer to Destroy.

Of course, the first paragraph was mile deviating from the topic of verification but the end result of verification is the chip and its fantacy in the market. Let's touch our fingers in 'Verification', Verification is not only just 'testcases' and 'testbench' environment. Its even more than the word "Testcases". Even writing testcases is an art, which people need to plan before coding. Then intention of the testcase, whether its precise and hits the corner cases, coverage these are some of the major tips which should be taken care before writing a pattern. "Planning" plays a major role in any kind of environment and then execution of the same is very important as we all know the great saying "Let our advance worrying become advance thinking and planning"

ASIC Verification can be divided into 2 major category

1. Functional Verification

• Directed Testcases: (In Verilog and C)
• Randomization: Like Vera, System verilog
• Assertion: (Like, System Verilog Assertion (SVA), Open Vera Assertion (OVA - Synopsys), Constraint based Verilog (Freescale)

2. Formal Verification

• Equivalence Check (EC):Its checking whether the golden design and revised design are same (Cadence Encounter - LEC, Conformal)
• Formal Check: Using Synopsys ( Semi-formal tool: Magellan), Cadence (Formal tool: IFV)

Now the word "Functional" and "Formal" may hit your mind what is that?

Functional Verification:

It requires user-defined stimulus which may not be checking all the corner cases and there is a heavy risk of missing some bugs. It depends upon how the user has coded.

Formal Verification:

Its tool based verification where the Design and the assertions are given as input to the tool, and the tool try to do a negative check on the design properties, If the tool fails to prove the property, it will declare Proven else Falsified but still there is a risk of state explosion or deadlock. Note here we do not write any testcases, the tool generates all possible scenerio.

Why we need assertion?

Assertions are really fantastic for detecting and isolating bugs. This increases productivity. The fact that they're re-usable in formal tools and simulators also increases productivity, and helps coverage closure. Assertions can help you monitor interactions between blocks. Suppose block A is driving block B. Assertions can be used to verify the block A interface, and can also be used to verify the assumptions for block B. Assertions can validate and ensure consistency between interfaces when two blocks talk to each other. Assertions: by their nature to find errors. If you miss, they fire – they indicate errors, they indicate the location, and they make debug much simpler.

RTL Verification can be said "DONE" only when we get good code coverage and functional coverage which is 100% (functional coverage) and 97-99 % (code coverage).

Again Coverage is a wide topic, but in general "coverage is percentage of testcases/functionality exercised". Its a wide topic to be discussed offline or on a separate topic.

Once we are done with the RTL verification, synthesis is carried forward to generate Synthesized RTL, Logical Equivalence Check (LEC) is carried to check the logical equivalence between the RTL and Synthesized RTL and checked for any ABORTS. If there are aborts in the design, gate level verification must be carried forward for the early detection of bugs.

So every stage from Specification to Tape-Out (TO), every phase has intensive verification. So by the above mentioned sentence one can roll his sleeve and say Its a very vast field where innovation and creativity is important to hit the bug.

About Author:
Jeyanthi Arumugam
Senior Design Engineer in Freescale, Noida

VLSICore Blog: http://vlsi-core.blogspot.com/