Career in verification

Bren · Junior Joined: Aug 02, 2004 Posts: 5 Location: UK

Hi.

I'm currently working on the design and verification of a 0.18um standard cell ASIC down as far as RTL. Synthesis and layout will be done by another company when the time comes.

I want to change company after this project, but won't have Synopsys experience, which seems to be a requirement for all ASIC positions.

I thought I could possibly land a job using my experience in verification, but I recently read in the Verification Guild archives that this could trap me in an area that's ill-understood and very vulnerable to economic climate.

Does anyone have any advice on what I should do? Thanks in advance.

hemanth · Senior Joined: Aug 16, 2004 Posts: 93 Location: Bangalore

This is not intended to be an advice of any sort but I wonder what the economic climate has to do with verification. In all probability it is the one thats the permanent feature in all coming designs. Notwithstanding that there are certain uncertainities in the verification field but its all attributable due to the new significance attached to it and absence of well defined methodologies. So I feel its a solid area with rich promise for those indulging.

Larry · Senior Joined: May 24, 2004 Posts: 10

I don't think I'd characterize the field as having an "absence of well defined methodologies"... consider Janick's Writing Testbenches, Bening & Foster's Principles of Verifiable RTL Design, etc.

Sure, there isn't a step-by-step checklist for every possible verification scenario... but there also isn't a step-by-step checklist for every possible design scenario either. Both require a certain amount of creativity, insight, perseverence, and adaptability to the problem at hand.

Bren · Junior Joined: Aug 02, 2004 Posts: 5 Location: UK

So we'd all say that moving into Verification is pretty-much as secure as Design?

I'm tempted to try to do both, but then I run the risk of being a Jack of all trades, Master of none.

Decisions, decisions...

phip · Junior Joined: Jan 15, 2004 Posts: 6

Hi Bren,

Not to discourage you from a career in verification or anything, but another possible option that I haven't seen mentioned yet is to take a synopsys training course.

You could also use your verification experience to get a job, and then try to transition into design work later. There is the risk of becoming a jack of all trades, but on the other hand, I see lots of job adds for someone with 5 years of work experience, who has experience in verification, synthesis, timing analysis, layout, place & route, formal verification, embedded software design, FPGA prototyping, multiple bus interfaces, various networking and communication protocols, unix scripting, assembly language programming, PCB design, and windows device driver development. (OK, maybe a slight exageration :-)

Good luck,
Phil

vhdlcohen · Posted: Fri Aug 20, 2004 10:50 am **Post subject:**

Dilbert address his views on verification at
http://www.unitedmedia.com/comics/dilbert/archive/dilbert-20040817.html
_________________
Ben Cohen http://www.systemverilog.us/
* SystemVerilog Assertions Handbook, 3rd Edition, 2013
* A Pragmatic Approach to VMM Adoption
* Using PSL/SUGAR ... 2nd Edition
* Real Chip Design and Verification
* Cmpt Design by Example
* VHDL books

daveola · Posted: Sun Aug 22, 2004 3:28 am **Post subject: Job security**

IMHO, verification is extremely secure from a getting-job perspective, once you have experience, but it is generally looked at as a level below design at all but the more enlightened companies. (The first question I ask recruiters is what the design/verification ratio is, because that's an awfully good indicator of their view on verification).

So, if you're interested in the limelight, take a synopsys course. If you want really good job security, get into verification.

But maybe more to the point, do you have a verification mindset? Like to break things? Like to use things in new ways, or look at things from all or unusual perspectives?

Good luck..
_________________
DaveSource Consulting
http://DaveSource.com/

peetj · Senior Joined: Feb 12, 2004 Posts: 18 Location: Colorado

The danger of all our engineering jobs is that they are moving overseas. The question is which jobs, design or verification, are more likely to go overseas. Design has two main parts, entry (the actual rtl writing) and then the synthesis (fighting with the compilers to get the physical part to map and timing to work). The rtl entry has successfully been moved overseas. It has been around for along time, and thus is the easier of the two parts. I started doing RTL entry at IBM in the mid 80s, it got old entering similar stuff at about the 10 year mark, now it has been almost 20 years. The synthesis part, when your not on the bleeding edge, is also not too difficult, and is pretty much routine. This also has been successfully moved overseas in a lot of cases. If you are on the bleeding edge of sysnthesis, where you have to really play with the tools over many iterations to get things to work, takes an expert. They do not have this kind of expertise overseas.

Verification is very unique to each design, it does not really have an easy part to it. Now if you do old style verification (watch line wiggle in signal scan), than that to is easy and can find success overseas. The trend over the past few years (because companies are cost and profit driven) is to ship everything overseas. They are finding out that rtl entry and simple verification worked fine, but highend verification and highend synthesis did not see the same success. The person who can do either of these two, or both, and become invalueable to a company, will have the best job security. Of the two, I'd put my money on verification. It has shown to be the harder of the two in the past years, taking up 70% of the overall combined effort. It is the least automated, the least plug and chug, the one that takes the most expertice, and the area that still has the most problems to solve. I believe the majority of companies are still in the dark, and are still put design over verification. These are the short sighted companies that layoff the verification team first and the design team 2nd. But that is changing as well. The likely new trend will be to ship rtl and design jobs overseas first, and verification last.

peet
_________________
******************************Peet JamesAuthor of "Verification Plans" published by Springerpeetj2@earthlink.net

Bren · Junior Joined: Aug 02, 2004 Posts: 5 Location: UK

Well thank-you all very much for your views - I'm now a little more confident in taking Verification-only jobs.

Do you have suggestions in how to make myself stand out in the field? I'm currently quite au fait in VHDL and Verilog, with some C/C++.

There seem to be lots of up-and-coming tools in this area, (e, Vera, SystemC, SystemVerilog etc.). Anything new for me would have to be from a free, (or inexpensive), download. Any recommendations therein?

Thanks in advance!

peetj · Senior Joined: Feb 12, 2004 Posts: 18 Location: Colorado

Modern verification is first about methodology and 2nd about language. Many companies and engineers jump on the band wagon, choosing a language and a tool, only to not grasp the more important enabling methodologies. I would suggest to anyone new to or converting to building modern, pseudo random, high level verification languaged based verifcation system, to first get everyone on the verification team grounded in the enabling methodoloies. This foundation is crucial. I do not know how many times a company has engaged my services on the 2nd pass, because they did not achieve success. They did no coverage for instance and were verifying blind. I have a chapter in my book all about this, and I gear the verification plan to the 3 enabling methodologies. Janicks book has information as well. Most classes you take will be about the 'math' of the language, with little to no information on how to engage the necessary methods in realistic ways. When I teach a class, I start with the methods, and then do the 'math' while always making the code examples based on one of the three methods.

The methods, in short, are:
1) Generation: You want rich constraint generation constructs so that you can build a layered generation engine that can easily be guided into typical and interesting scenarios that the circuitry will encounter. Random elements are stategically used to aim the simulation into smart target areas.
2) Checking: You want a rich temporal language and list method technology so that you can both build a set of checkers (for control) and scoreboards (for data), that will point out success and failure. The verification generation will throw lots of data at the system under test, these checkers and scoreboards need to be robust so that they catch bugs, yet do not cry 'wolf' and waste precious debug time. They need to catch the errors and lead you quickly to the buggy hardware. The scoreboards are often the most challenging verification code to get right.
3) Functional Coverage: You need a way to see what functions have been tested and more important, what holes are in your verification. Without coverage you are verifying blind. You need the feedback mechinism to see what was generated and what happend. You need a set of constructs to easily add coverage, and a robust way to sleuth the resulting huge amount of data into tangible information that is easy to grasp, so that it guides which verification battles you will persue, and which you will let slide.

Now, as to which language/tool to use, it does not really matter. Some are better at one methodology then others, but are lacking in another. e for instance probably has the most evolved set of constructs, plus it has a back door macro setup so that u can write your own constructs. vera has really caught up lately by adding a lot of improvements in libraries, generation and coverage. These new addition are being tested in the real world, so they are still somewhat buggy. e and vera cost too much. That is their down fall, and some would say that both are on there way out. Their respective languages have been moved to the public domain, but probably to late for either to win. System C seams to be gaining some ground (David Black's new book is a good place to start for that), and testbuilder is a C based solution as well, that some are finding success with. When using these, I often find myself wishing for some of my e and vera constructs. I can build them in C, but who has time to do that, let alone support it afterwards. SystemVerilog is the one that currently seems to be perking peoples interest. Maybe it will win out. Who knows? It most likely will end up like verilog and VHLD, with several competing languages surviving. All of them compile down into C, so maybe it will become a wash. Write in the one you want, and the simulation engine will compile any of the languages. Maybe it will end up being a mix and match scenario.

One thing that keeps surprising me, is that whatever language I am consulting in, it seems the engineering team and myself are the only ones out there pushing the envelope. I am consantily trying to do what I have done in language a, in language b, and it just does not work. It should work. I end up debugging the language and tools for the eda company. It makes me think, are people out there really not pushing these languages? Do the majority still not grasp the 3 enabling methodologies? Take vera. It took them years to fix the and add to the coverage. Where teams actually ok with such lame coverage. How did they get the job done?

Whoever evolves these languages, needs to not be just a theory-miester. They need to be people who have done a bunch of these verification systems, with full blown use of all three enabling methodologies. Sure free is great, but if you have to spend tons of effort (and thus money), adding all the necessary constructs and libraries yourself, then you will not get the job done in the alotted time. So if I had a chip to get out the door this year, I would choose vera or e. Why? Most robust set of constructs at the moment that let me easily engage all 3 enabling methodologies. Also, they are the ones I know the best. If I was a free floating, newbie, fresh out of college, I'd probably look at a C based solution. Reguardless, I would watch the development of SystemVerilog, because it has a good potential. And of course, because I am joe consultant (and also, because it is just plain smart, and saves you money in the long run), I would realize that jumping into modern verification is a quantum jump. Hire someone to help you out and get you going in the right direction. To teach you stuff, so that you can make informed choices, and not have to learn from mistakes and failures.

Peet
_________________
******************************Peet JamesAuthor of "Verification Plans" published by Springerpeetj2@earthlink.net