Home Tips Review - Verification Leadership Seminar

Search

Review - Verification Leadership Seminar PDF Print E-mail
User Rating: / 2
PoorBest 
Thursday, 24 December 2009 00:00

How many of you have tried to cut on coffee? or even quit drinking coffee altogether? I guess a lot. Well, personally I’ve given up on trying but you know what? there’s actually something worse than having 8 cups of coffee per day - it’s the muffins that come with them! (or any other form of candy for that matter). The evil muffin of muffin-compliant just sits there in the cafeteria waiting to attack when you’re most vulnerable - holding a cup of coffee in your hand.

Now things get really out of control at those professional seminars and conferences where the agenda [hopefully] varies but one thing remains in common - plenty of coffee and cakes Recently I had to risk temptation yet again when I took the Verification Leadership Seminar at Ace Verification (given by Akiva Michelson, CTO & Founder).
I’ll admit to it right away - I had a lot of coffee plus an average of 5 to 6 croissants a day (it was a 3-day thing) but it was really a small price to pay for an insightful view on various verification approaches and a series of interesting discussions on today’s challenges in leading verification projects.

 

For example, we talked about the problem of marketing the verification profession to VLSI engineers. Traditionally, verification has been less appealing than other professions such as logic design, partly because verification as we know it today simply didn’t exist before. This makes it a quite a challenge for verification leaders to recruit and keep good engineers on their team. Try to ask new graduates what they would prefer - design some module or verify it? What do you think the answer is going to be?

In another discussion we tried to come up with some guidelines for building a productive verification team, how to split the debug and environment writing work among the team - should there be a clear distinction between people who develop the code and the people who execute it? or maybe it’s better that everybody does little of both?

It was also interesting to see how different companies have different views on the complex love-hate relationship that verifiers have with designers. I guess that subject alone deserves its own study We tried to find out, for instance, just how deep you would expect a verification engineer to dig into the design when a failure occurred. Would you want your verifier to spend time on reverse-engineering the RTL in order to understand the root cause? or maybe it would be enough to send the failure details over to the designer? but then what if the bug is merely a bad configuration or an environment issue? 

Other discussions were quite technical in nature. For example, I remember one dramatic session about the pros and cons of aspect oriented HVLs vs. object oriented HVLs. I was surprised to see opinions varying quite a bit there. Seems like not everybody is so keen on AOP, even those who work with e. Oh, and we had a long talk about coverage and ways to make coverage goals more feasible, which reminded me of a rule I once tried to establish back at PMC-Sierra : Cross-coverage points with 3-dimensions or more must get manager approval.

As expected, we also mentioned the less-common verification techniques such as Formal, Assertions, etc. and found out yet again that there’s probably a good reason why they still remain less-common. Ok, I’ll stop here and refer you to the course website where some of the presentations are available, and more information can be found.

Summing up, it was a good seminar. It was interesting and also fun, and I think all of the participants are now feeling a bit relieved knowing that colleagues at other companies are facing similar problems and that there are no quick solutions to everything. I believe the challenges in managing and executing verification projects these days are manyfold and call for creativity not less than adhering to proven methodologies. That’s what makes it so exciting!

 

Disclaimer: This review was written in 2007

 

 
More articles :

» Latest Buzz From The EDA & Verification Community

{loadposition pos101}{loadposition pos102}{loadposition pos103}{loadposition pos104}{loadposition pos105}{loadposition pos106}{loadposition pos107}{loadposition pos108}{loadposition pos109}{loadposition pos110}{loadposition pos111}{loadposition...

» The Cost Of Verification

We spend about one third of our lives in bed, right? doesn’t it make sense then to buy a good bed and not a cheap one? The same can be said for your verification tools as you spend so much of your project time on verification. Buying cheaper tools...

» Verification Documents - Love Them, Hate Them, But You Can't Ignore Them

Verification Plan (or Test Plan) and Coverage Plan are two documents that specify the features to be tested in the verification process. The first document usually lists the DUT features that need to be covered and the latter - the coverage points...

» To Randomize Or Not To Randomize

One of my former colleagues once revealed the fact that she had no less than 70 pairs of shoes. That’s right, seventy! She had been very good at her job and by no means had any plans to start her own shoe business so I asked myself why on earth...

» What Makes A Great Verification Team GREAT?

Your tool provider won’t tell you that, nor will those fancy methodology books, but verification is not all about mastering technical skills. True, those will help you very much in your daily work but verification is first and foremost TEAM WORK....

Add comment


Security code
Refresh

Copyright © 2018 Think Verification - Tips & Insights on ASIC Verification. All Rights Reserved.
Joomla! is Free Software released under the GNU/GPL License.