CCD, My read of Certess technology and positioning

 

With due respect to the technology behind Certess’s tool I have some discomfort with the way it is being positioned – atleast in the below article:

http://www.edadesignline.com/howto/215600203;jsessionid=TP12OA3IF1X3UQSNDLOSKHSCJUNN2JVN?pgno=2

Before I talk about my discomfort, let me state the positives: Not very often do we get to read such well written, all encompassing technical article, Kudo’s to Mark Hampton – he touches on every aspect of functional verification in this article, not so common in an EDA product “promotional” article – to which this article may be characterized to (unfortunately IMHO). Having said that, I personally believe Certess should position the technology “along with” existing ones than challenging/trying to replace time tested/well adopted methodologies such as code cov, functional cov etc. Not that I differ from his views on the shortcomings of these technologies, rather going by what Pradip Thakcker said in DVM 08 (http://vlsi-india.org/vsi/activities/2008/dvm-blr-apr08/program.html)

“Code coverage and functional coverage are useful techniques with their own strengths and weaknesses. Rather than worrying about their weaknesses, focus on the positives and use them today”..Pradip, during his “Holistic Verification: Myth or The Magic Bullet?”

I will be very glad if Certess focuses on their real strength of exposing lack of checkers in a Verification environment than trying to “eat” into the well established market of Code/Func coverage tools. Another rationale: Both the cov and qualification is compute intensive and given the amount of EDA investment that has gone into stabilizing and optimizing these features, it will be irrational to try and replace them with “functional qualification” (No offense meant, I have great respect for Mark – given his excellent article and ofcourse the product). With SpringSoft acquiring Certess hopefully their customer base/reach increases and that will throw up more success stories in the coming months/quarters. So good times ahead!

ITG, CCD & ACC - Emerging Verification technologies

Well, it is not the overly hyped *V here - such as CRV, CDV, ABV - we at CVC (www.noveldv.com) consider them as yesterday-ones for the sake of giving room to next generation ones such as:

• ACC - Automatic Coverage Closure 
• ITG - Intelligent Test Generation (such as Graph based)
• CCD - Covered & Checked implies Done (such as Certess/SpringSoft)

Out of this let me spend more time on the last two as the ACC is already been discussed for a while now (atleast more than the other two).

ITG - Intelligent Test Generation (such as Graph based)

ITG - is still in its early days. Two tools seem to be addressing this as of today:

1. Infact  from Mentor is one big name.
2. The other one that is very promising is: Breker Systems with a very high profile team behind it. These folks know what they are talking about - with their CTO holding "Adnan holds 15 patents in test case generation and synthesis.".

We at CVC are yet to get our hands dirty with these tools, but certainly worth watching indeed! From our early analysis this technology will assist more and more system level tests being easily captured by raising the level of abstraction of testcase specification. This will be fun indeed!

CCD - Covered & Checked implies Done 

Coming to the other category: CCD (yet to find a better name) – this is a topic that has been haunting us for atleast a decade now. Ever since I started using Functional coverage (early 2000), we always had this problem of “I got it covered, but did I get it checked too?”. During an Ethernet monster switch/router verification at Intel we hit this problem atleast half-a-dozen times and those corridor discussions still ring in my ears. The Design (read it as RTL) manager (Sutapa Chandra) made fun of us asking “are we taping out RTL or testbench” as we seem to be finding lack of checkers every now and then. Most of these situations are the case of bugs went undetected at block/cluster level and later get got (luckily) at full chip level – then we do a rigorous review of our block level env, and find that we indeed had coverage points for those scenarios, just that we didn’t have enough checkers! Shame, but true. A technology such as Certess’s Testbench Qualification was what was indeed needed! A very detailed read of Certess technology is at: http://www.edadesignline.com/howto/215600203;jsessionid=TP12OA3IF1X3UQSNDLOSKHSCJUNN2JVN?pgno=2

Random testing for VHDL based designs

With so much buzz around CRV (Constrained Random Verification) it is hard to imagine that VHDL based design teams are staying quite away from this approach. From our experience at CVC, we have seen that SV-Tesbench with VHDL DUT is not that hard to get it working, so excpet for some additional tool cost (mabye?) it is very much a feaisble approach. However with great push and dedication from Jim Lewis, we are seeing that VHDL is fast catching up. See recent Aldec seminar for instance: http://www.aldec.com/Events/Event.aspx?companyeventid=74

Implementing Constrained Random Verification with VHDL

Interesting...