>> EDA User News and Reviews
Thread views: 39166 View all threadsNext thread*Threaded Mode

06/24/06 08:16 AM
Verification Languages: 3 points to ponder beyond "which one?" new Report this article as Inappropriate to us !!!Login to Reply

Verification Languages: 3 points to ponder beyond "which one?"

Use this link to read the full article

Sunil Kakkar
06/24/06 08:16 AM
There are no short cuts to verification new Report this article as Inappropriate to us !!!Login to Reply

The authors are very right in observing that the selection of a mere tool/language does not mean you are almost there when it comes to verifying a meaningful chip.
There are several tool independent steps which must be taken in the right direction even before a tool/language is selected :
a) Verification begins at the architecture definition stage in the form of performance modeling and designing for verification. A meticulous tool independent plan for this is a must.
b) A thorough tool independent test plan that covers all stages of design from block level RTL -> chip integration->gate level netlist->system level validation->FPGA->eval boards is a must.
c) Evolving an assertion & a coverage methodology is a must.
d) Running application code is a must.
One can then select a language, keeping all the above requirements in mind.
But even then, no matter what language/tool is selected, the final quality of the verification platform cannot be better than the skills of the verification engineers.

Akiva Michelson
06/29/06 08:48 AM
Goal Driven Verification is the way to go... Report this article as Inappropriate to us !!!Login to Reply

I like the analysis and the questions asked. I get the feeling that many people don't really inquire "Do we know what we're getting ourselves into?" on the onset of the project. Schedules are frequently set by wishing, rather than in-depth analysis.
I think that one of the biggest mistakes in verification is poor definition of the expected outcome of the project. This is a double edged sword, on the one hand if you don’t clearly state what features in which configuration are important than people might skip one of the critical ones, but overstating and defining an amorphous “0 bug goal” can have your engineers rat-holing for weeks in inconsequential spec gibberish.
Back to languages; Once you have defined a clear project goal, it will be easier to research which language gives you the capabilities to define your simulation goals (functional coverage points), create meaningful random data, and execute your project smoothly.

View all threadsNext thread*Threaded Mode
Jump to


© 2021 Internet Business Systems, Inc.
670 Aberdeen Way, Milpitas, CA 95035
+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