Learning a new language

One of the fun things about working in verification is every once in a while you have the opportunity to learn a new tool or a new language. Lately, I have been learning a new simulator and SystemVerilog.

The language I learned best as a computer science major, was the 'C' language. I believe the major contribution was just sitting down with the examples from Kerninghan and Ritchie's book called "The 'C' programming language". The beauty of the book is that it builds the language incrementally, and only rather late in the book (which is pretty short) starts alluding to built-in and other libraries.

SystemVerilog seems to have proponents who favor the "let's complicate things" school of thought. The books, courses, presentations, and "methodologies" I have seen do a wonderful service in making the language look complex and unwieldy.

In order to cope with the complexity, I'm doing my own incremental approach, and yes it even starts with "Hello, world". As I progress, I need additional functionality, I return to the books, skip through them and look for what I need. So far it has been going well.

As far as adopting libraries of someone else's code. I don't yet have an understanding of what these libraries actually do, and what I might gain by adding in these libraries. So until I do, I think I'll prefer to stick with my own code.

Over-compex environments

One of the problems that I encountered with many of the design teams I worked with is overly-complex work environments. Somehow it seems that almost every design team gradually evolves to a situation where nobody really knows how it all works. The good teams usually identify the problem, assign someone to put some order into it, and if they are successful they will reach a situation where one person now understands how it all works; but if they are really good, they will actually reach a simple solution where multiple people can understand “the system”.

This is how to know if you are on the right track:
“The System” you have should consist of what’s installed on your primary computer (PC, Laptop, Workstation, Xterminal etc.), standard desktop, where you do your editing, where you do your runs, source control, config files .cshrc etc., directory structure, filelists, compile script, run script, queuing (lsf), where your coverage information/ log files/ block verification/ failed tests go to, and standard practices.

To add a new user should be a matter of minutes (at most), till he can successfully run tests, make a change, rerun, see wave files etc.

The run script should be generic enough, that you can:
a. Choose to run individual parts (compile only, run only) etc.
b. Work with a make-file to assure that you are only recompiling the parts that you have changed
c. Be able to output its commands to a file which you can run manually with your addition
d. “push” a new version of a tool release by simply changing a constant in a config file.
e. Be able to be modified/debugged by multiple people.
f. Be able to run regressions
g. Be able to recreate failed tests efficiently (on specific releases, versions, tags etc)


Each design group needs a skilled engineer with good knowledge of Unix/Perl, who is good with “customers”, organized and methodical to set up this type of system for them.

If people are not comfortable using the development environment (they keep complainging about the scripts), if people are not efficiently using the licenses available, if some of your users frequently waste hours on integration issues or if you have made mistakes in using the wrong versions of RTL, or testbench; I suggest you take a step back and make the change.

Too many cooks spoil the broth

I get a few e-mail each day from a something called Eda-cafe. (www.edacafe.com) I'm not quite sure why they send so many e-mails, but if you take a peak about once a week at the newletter, you can identify the 2-3 things which have changed since the last time you glanced at it.

Yesterday, I was glad to see there were two articles on Verification. Interestingly, they were both from people in the same company (MosChip Semiconductor). I'm not sure if that was the intention of the writers, but I believe it's not a bad way to attract good verification engineers to your company. Being in a place which encourages development of verification skills, seeing verification in a broader context, and encouraging engineers to publish their ideas is win-win for everybody. Verification engineers will develop and sharpen their skills and management will get both better verification and good reason for their bright engineers to stick around.

Sunil's article ( http://www10.edacafe.com/nbc/articles/view_article.php?section=UserArticles&articleid=258632) was intersting to me, in that it talks about a more holistic approach to verification. I believe it is interesting to see that similar trends in other fields apply to verification as well. I believe the trend being developed is to look more at the broader picture in order to find out how to optimize locally. I identify well with his example of the "functional formal verification tool" and how (if you listen to vendors) you can dispose of other tools and methods if you just use this.

Whether it be a formal tool or any other, no single tool can replace everything, and like a good cook the up and coming generation of verification engineers need to choose a mix of spices and herbs, find a healthy entree, time their cooking, frying and baking to specification, and manage with way too many people in the kitchen.

Akiva

About Verification Tea

One of the things I noticed in the course of my career, is that verification engineers are always busy. Now, busy is a pretty good thing, seeing as it usually means that you will remain employed; but now and then, even great verification engineers need to take a 'tea' break and evaluate whether they are working hard and smart, or just working hard.

Functional Verification of RTL designs is a fascinating field, and promises the true explorer a rewarding and enjoyable career, each day we can learn new solutions, discover new bugs, and find entertaining ways to make the world around us work better with us. It is this exploration, and the occasional moment of epiphany which keep us enchanted for years on end. (that and the salary of course )

My goal in this blog is to share some of my tea-time ideas, hopefully get some good feedback from the audience, and provide an entertaining place to spend your tea-time.

So pull up some biscuits, or cookies if your from the other side of the ocean, and enjoy your break.

Akiva