Being a “Pedantic Engineer” – self check for fresh VLSI engineers

As a sub-thread of a core technical discussion, Alan Fitch from UK brought up an important question: See the full thread (more technical @: http://www.verificationguild.com/modules.php?name=Forums&file=viewtopic&p=16440#16440 

Alan Fitch writes:

I agree with your answer, but as a pedantic engineer (is there any other sort?) 

I really wish there isn’t any other – but not sure if many young engineers agree with that. BTW I do consider myself young, am really talking about fresh/beginners/early career folks. I see some degradation on that side, I was at KCG Tech (http://www.kcgcollege.com/) this weekend for their NCV09 conference. We from CVC were  delivering our VoW tutorial series on "Functional Verification methodology", and also a case study on Assertion-Based Verification by Thirumalaiprabhu, my colleague @CVC. I met with the teaching staff there. Had a long chat on this very topic – the fresh graduates recently aren’t pedantic – atleast in VLSI domain. The reasons the staff attribute are:

  1. Too much use of cellphones
  2. Time wasted on Social Networking sites (Orkut, FB etc.)

 

To me – if you are an engineer – no matter which field it is, you *MUST* be pedantic – else you are not set for a complete, satisfying career – you may earn more money than many of us, may fly across oceans etc. But completeness is beyond all these – one’s self satisfaction about what we do everyday in professional life!

 

Signing off!

Now is the time to prepare for a bright career

16 Aug 2009:

http://www.livemint.com/2009/08/16131752/Corporate-India-resumes-hiring.html?h=A1

This is a very refreshing read indeed and inline with CVC’s prediction on the market. It is very important not to jump too many steps too fast and call it honky-dory, it is essential that we stay on the floor, do the basics and get the ecosystem back on track. For fresh graduates this is an ideal opportunity to acquire right skills needed in the industry and not fall prey to “name-sake” trainings. Start with “END” in mind – ask the right set of questions; ensure you have confidence in the team that you would work with during a training/incubation to see that your career is being built and not just a set of language skills.

 

For recently displaced workers – this is better than ever time to hone their skills to grab the opportunities as they open up locally, slowly. Do not rely just on openings at job-portals. For the past 6 months we at CVC have been assisting various VLSI companies hire right talent through our referrals; these are jobs never posted on job-portals.

1-day course on “Do-it Right – Advanced VMM”

1-day course on “Do-it Right – Advanced VMM”

…SystemVerilog framework for creating effective Verification Environment

CVC (www.cvcblr.com) is announcing a new session of its 1-day course on “Do-it Right – Advanced VMM” including new base classes and RAL.

Duration

Topic

Duration

Advanced VMM

1 day

The course is structured in a balanced manner with theory and lab sessions tightly embedded in a manner that helps in mastering topics learned so far in the course.

Schedule:

August 19th at Bangalore

To attend this class, confirm your registration by sending an email to training @ cvcblr.com

Ph: +91-9916176014, +91-80-42134156

Please include the following details in your email:

Name:

Company Name:

Contact Email ID:

Contact Number:

2-days course on “Do-it Right – Basic VMM”

2-days course on “Do-it Right – Basic VMM”

…SystemVerilog framework for creating effective Verification Environment

CVC (www.cvcblr.com) is announcing a new session of its 2-days course on “Do-it Right – Basic VMM” – a step-by-step guide to building scalable, reusable and flexible Verification Environment using VMM.

Duration

Topic

Duration

Quick SystemVerilog refresh

0.5 day

Verification Methodology

1.5 days

The course is structured in a balanced manner with theory and lab sessions tightly embedded in a manner that helps in mastering topics learned so far in the course.

Schedule:

August 12th ,13th at Bangalore

To attend this class, confirm your registration by sending an email to training @ cvcblr.com

Ph: +91-9916176014, +91-80-42134156

Please include the following details in your email:

Name:

Company Name:

Contact Email ID:

Contact Number:

ACC update

As a quick update to ACC post, VCS’s 2009.06 has come out with a related technology called Coverage Convergence Technology (CCT), read a user success at:

Improve Verification Productivity with Synopsys Coverage Convergence Technology

 

And NuSym rocks as ever before in this domain with great user interest for the successive DAC. They seem to have a good technology, but my worry is will the customers pay extra $$$$ for it? Let’s wait and watch. But their technology as can be read from their WhitePaper is based on “Path Tracing” and sounds very solid. The real challenge is in “execution” – or implementing that technology in a solid code in an EDA tool. Perhaps if you have few Armenian folks (who wrote the code for Synopsys’s new “Custom Designer” product), that will help? – A separate entry on that product soon..

 

Srini

Automatic Coverage Closure – my perspective

Migrating my old blog post to CVC’s homepage. Tune-in for an update (with DAC09 underway, didn’t you expect that anyway :-) ??)
 
Automatic Coverage Closure – my perspective

Recently EDA tools are emerging in the area of “Automatic Coverage Closure” that promise a new level of automation in CDV/MDV/any_other_Buzz_word_Driven_Verification process. A significant name in this arena is nuSym, a relatively new EDA player. There have been few good reviews about them @ Deepchip.com.

http://deepchip.com/items/0479-05.html

http://deepchip.com/items/0473-06.html

http://deepchip.com/items/dvcon07-06.html

And another one @ SiliconIndia:

http://www.siliconindia.com/magazine/articledesc.php?articleid=DPEW289996212

And very recently on VerifGuild:

http://www.verificationguild.com/modules.php?name=Forums&file=viewtopic&t=3102

I like Gopi’s post/comment b’cos I have the same opinion about CRV (Constraint Random Verification) – it catches scenarios/bugs that you didn’t envision – either via constraints or coverage (or otherwise). Now if we fool ourself by going behind “only the existing/identified coverage holes” we fall into a trap. This is inline/insync with what Sundaresan Kumbakonam of BRCM ( need his profile? See: http://vlsi-india.org/vsi/activities/dvw05_blr/index.html) shared with me once:

Quoting Sundaresan:

I don’t believe much in the idea of “writing functional coverage model” and then tweaking a constraint here-or-there, or writing a “directed test” for it to fill the hole.

Coming back to my view, I believe some redundancy via randomness/CRV is actually good. In my past verification cycles I have seen design errors due to “repeated patterns” – no big deal, is it?

So where exactly do these ACC tools fit?

Referring back to:

http://www.verificationguild.com/modules.php?name=Forums&file=viewtopic&t=3102

>> whether these tools are only used to reach last few % of coverage goal which is hard to reach ?

I would differ here, they shall be very useful somewhere during the middle phase – neither too early, nor too late. Too early – perhaps we don’t have full RTL and/or functional cov model. Too late – perhaps our focus should be more into “checking” than only coverage (As Nagesh pointed out in VerifGuild). I would like to add that during those last minutes, the coverage shall be taken for “granted” – meaning it is a *must* and not a *nice to have* thing and the focus shall be to look for any failures.

To me a reasonable flow with these ACC tools would be:

  • Run with CRV, measure code coverage. Add checkers
  • Add functional coverage, use CRV again to hit them using the coverage points as “potential trouble spots” than “actual scenarios” themselves. In few cases where in the scenario description is easy to capture using Functional coverage syntax, this is great. IMHO the existing coverage syntax is little too verbose and unusable to a large extent for solid, easy-to-use coverage specification. Specifically the SV syntax overhead of coverage is just too much for me. IEEE 1647 “e” fairs slightly better but that’s a different story altogether. I’m still on the lookout for a higher level coverage specification language.. (matter for another blog post anyway).
  • Once the RTL and the coverage model is reasonably stable, use ACC regularly as a “sanity” test on every interim RTL release. I believe ACC has a HUGE potential here – if we can optimize the tests needed to release interim RTL versions, we are saving quality time and enabling faster turn around.
  • Towards the end, enable “plain CRV” (without the ACC bias) and look for “trouble free regression for XX days”.

And while speaking to a friend of mine here a while back, he is damn against the idea of using these ACC tools for merely stimulus. He likes the idea of ACC if it can be used to:

  • Fill functional cov holes
  • Code coverage holes
  • Assertion cov misses/holes

A tough ask, but looks like nuSym can handle that – atleast based on the early reviews so far. Also reading their whitepaper on “intelligent verification”, they do a path tracing that enables them to systematically target code coverage without getting into Formal world – cool idea indeed! Kudos to nuSym folks (some of them my ex-colleagues BTW).

And on the application of these ACC tools to the poor, non-CRV/CDV folks – there is light at the end of the tunnel, if you read nuSym’s paper. We at CVC also have ideas on how to use this for a highly configurable IP verification with plain vanilla verilog/task based TBs. We need to prototype it before we can discuss it in detail though.

Anyway, good topic for otherwise a downturn mood.

More to follow.

Srini

P.S. Sorry for the “random” rambling, after all we are talking of “random verification” :-)

Community contributed, quality DV blog