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


(Unregistered)
06/24/06 08:16 AM
Verification Languages: 3 points to ponder beyond "which one?" 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
(Unregistered)
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
(Unregistered)
06/29/06 08:48 AM
Goal Driven Verification is the way to go... new 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

 

CST Webinar Series



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