Hiring for ASIC Verification

You want to grow your asic verification team, and you decide you’re going to write a job description and post it with head hunters and on bulletin boards. You are looking for someone with HVL language experience like Vera, specman e, verilog or at least some vhdl experience. Perl is an asset. You have just removed 99% of all programmers in the world from your search. This is bad. You can’t afford to trim 99% of the potential candidates because they don’t know an HVL, because knowing an HVL is only a fortunate skill to have, one which can be acquired by reading a book.

One of the things your ASIC verification engineer will do is write a data structure parser for error injection or functional coverage, and you want this person to know specman ‘e’? Instead, you should wonder if this person knows how to write parsers. Otherwise, you will end up with “parser” on your schedule for every block-level environment you have, for every chip you ever do.

Someone who knows how to write a parser will create a recursive descent parser that your whole team can use by attaching a procedure to nodes being visited. You will be able to instantiate this parser anywhere in the verification environment where you have your data structure to parse. Someone who does not know how to write parsers will write one giant task in a scoreboard and manually travel down the data structure until the piece of interest is found. Nobody can reuse this parser because it is hardcoded inside the context where it is used. Any attempt of cut and paste to another place where it could be useful is doomed because the parser uses the scoreboard context instead of being self-contained.

I don’t think it’s an absolute necessity to know Vera or Specman, Verilog or VHDL to be able to do ASIC verification. Sure, it means the person has experience using those languages, but it does not mean they know how to program. Very few people know how to program in general. Of that, even fewer will know those weird proprietary programming languages that we use in ASIC verification. However, good programmers can learn new languages in a matter of a few weeks, and there is more good programmers that know C++, Java, Python and Ruby than there are good programmers that know Vera, Specman, Verilog or VHDL. So in the job posting, you need something that isn’t a turn off for 99% of the programmers.

In fact ASIC verification has little to do with hardware: writing parsers, creating entire libraries from scratch, writing your own mutually recursive functions to implement a constraint satisfaction solver, creating and data mining a post-synthesis timing database, are all things that I have done as part of so-called “hardware” verification. The problem is, those jobs are advertized with something like “verilog” as a requirement, and this simply turns off 99% of all software programmers because they think they will be playing with transistors all day and they’ve long determined that they wanted something more exciting like web 2.0, Ajax or JavaScript. Instead how about putting things like “combinatorics, QA, automated regressions, git and fan of Donald Knuth” in the ASIC verification job description.


3 Responses to Hiring for ASIC Verification

  1. Hi Martin,
    it’s been popular for a while to say that you just need programmers to do hardware verification. That’s not strictly true. You need programmers who can understand hardware (concurrency, clocks, timing, asynchronous events, etc, etc). Your “programmer” will also be expected to debug RTL and possibly even gate-level errors, so some hardware experience is necessary. Of course, it’s not enough to know these things without knowing a lot of software concepts as well, so verification cuts out 99% of the candidates on its own!

    So we need software guys who know hardware, or hardware guys who know software. One reason for asking for VHDL, Verilog, e, etc, is that it’s an /indicator/ that the person probably knows a bit about both worlds. Having a HLVL shows you /might/ know a bit more about the software world than just by knowing an HDL. I wouldn’t ignore a CV that didn’t have it though, but I’d look for C++, Java, or similar (OOP is a different skill from language syntax), along with some indication of previous digital hardware experience.

    > an HVL is only a fortunate skill to have, one
    > which can be acquired by reading a book.

    This has not been my experience from the mentoring work I do. Picking up a HLVL seems to fall into the following categories:

    1. Hardware designer *never* picks it up. Classes, objects, polymorphism, abstract base classes, design patterns, are forever the domain of someone else

    2. Hardware designer picks it up and spends years writing “verilog with classes”. You know, one class called TestBench and 5000 methods called test_foo(), test_bar().

    3. Hardware designer picks it up quite well, but spends 2 – 4 years learning OOP the hard way (much like software guys) before being an expert

    4. Hardware designer picks it up very quickly (a closet software programmer?)

    5. Software (OOP) guy picks up the syntax but never quite gets time consuming methods and event synchronisation

    6. Software (OOP) guy picks it up very quickly

    I’ve encountered only a few people who fell into categories 4 or 6. Most people seem to have a significant learning curve one way or another. A common gotcha is following all the good programming rules, just to find out that your testbench is too inflexible to deal with last minute specification changes. Another is creating verification IP that doesn’t actually catch any errors (don’t ask). So on top of language experience, you also have to add class library/methodology (VMM/OVM/AVM/RVM/eRM/SVM) experience and real testbench development experience.

    Again, HLVL experience is an /indicator/ that someone might have this.

    I suspect though that most places have these requirements for the same reason “must have 10 years Java experience” was seen on an advert a few years after Java was first released – the HR department don’t really know what they want. They hear buzzwords and make them requirements.


    ps – it would be interesting to see an example of the parser you mentioned in action.

    pps – nice blog

  2. Martin d'Anjou says:

    Now that you ask, I am not sure I know how I would design a parser like I described. The first problem I see is with the tokenizer. Say for example a tokenizer finds “8100” in a byte stream. This could mean an upcoming VLAN tag, but you will also find this pattern in random payloads, and it would not mean a VLAN tag… I have to ponder on this.

  3. Jay says:

    Very good enjoyed reading

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: