SystemVerilog for Verification seminar

Today I attended a SystemVerilog for Verification seminar by XtremeEDA. This was a high quality presentation, with good slides (ie real code was on the slides and I like code since it’s what I do all day). It had been a while since I looked at SV in this amount of detail. I guess the last time was when I attended an SV presentation by Cliff Cummings, and before that it was when I looked at SuperLog presented by Simon Davidmann back when I worked at the Big Nerd Ranch.

There was about 40 people at the seminar, so I think it was well attended. There were questions about randomization and constraint solver, and so while I though those concepts were now well adopted and well known, it seems I was wrong. There were questions on controlling the randomness of simulations. I guess those concepts have not made it to CS and EE programs in universities, or some people are simply new to this and the seminar was the place to ask. There is a great book by Janick Bergeron on all of this, I highly recommend it.

I don’t want to describe how great SV is as a programming language, because frankly, you can all read about it everywhere on the internet. Personally, I like the asic-world website because it shows actual code. What I am mostly interested in is the features the language does not have, because it’s always those features that I ultimately miss. But here is the catch: I have not used SystemVerilog, only Vera! So there I go, I can’t even comment on features SV does not have, since I haven’t used it!

Nevertheless, I have 5 “directed” questions about SV:

  1. Does SystemVerilog have covariant return types?
  2. Does SystemVerilog have classes that I can use without declaring or creating an instance (in Vera I need to declare an instance, but I don’t need to create it)?
  3. Does SystemVerilog have exception handling (throw, try-catch-finally)?
  4. Does SystemVerilog have destructors (so I can deallocate stuff, or close some IO I created outside of SV)?
  5. Are the functional coverage results stored in an open format like MySQL (it’s MY data, not the vendor’s)?

An interesting feature (or anti-feature) I learned about was that tasks can include time consuming statements, but don’t return a value, while functions do return a value (including void), but cannot consume time. Strange. Why would SV make a distinction, since it is annoying to have to use a task to consume time and return a value through an argument passed as a reference: why not have functions that can consume time? Distinguishing between tasks and functions is so… verilog! Strange or annoying I don’t know.

The assertions, aka SVA, look highly useful. They remind me of regular expressions, and I think that’s what they are: an entire state machine described as a one-liner cryptic expression.

Lastly, there will be a seminar by Cadence and Mentor on OVM in Ottawa on March 6th, 2008, I hope I can attend.

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.

ASIC Specification: how not to suck

I don’t know where bad ASIC specs started, but I suspect it was at the Big Nerd Ranch. ASIC designers would write a document describing their design, and voila, and ASIC Specification was born. Sorry, but when your write a description of your design, you are not telling me what you designed, you’re telling me how to designed it. Nobody really cares about HOW you implement the FizBoo feature. What I care about is whether you implemented FizBoo or not, how to program it, how to turn it off, and what it does.

The dictionary definition for specification is:

“a detailed description of how something should be done, made, etc.”

See, it should not even be called an ASIC Specification, because I don’t care how it’s made! Maybe you do, but I don’t! The ASIC Specification is the wrong thing to write. So let’s describe what kind of documentation I need as an ASIC Verification engineer:

  1. Feature name (FizBoo) and short description (FizBoo scares little kids on halloween night).
  2. How to program the feature, how to turn it off.
  3. What the feature does to the data. If you can’t describe it in terms of a data tansformation, it’s not a feature and I won’t verify it, so why are you doing it?
  4. What the functional interfaces are: am I talking to a PCI-X bus or a T1 interface?
  5. A functional description of the functional interfaces: how do I twiggle the signals on that interface to make it tango baby?

See, I don’t care that you store 20 kilobytes of user data in a sea of flops or an internal RAM. I really don’t. I want to know how to get the data in there, not how you made the address decoder.

Except for one thing: I need to know your corner cases. Like “the data is cached in 32 words of 64 bits before being stored”. I will use this information to craft pieces of data that nicely align on 31 64-bit words. Or 33. Anything that will break your design will be my pleasure to try. But the internal RAM stuff, keep that for the back end squad. And why and how you arrived at the conclusion it was a RAM and not a sea of flops, I don’t really care either.

So how to write the ASIC spec then? First, don’t call it an ASIC spec. Call it a Detailed Feature Guide. The document should be a big “foreach loop”. For each feature, describe items 1 through 3 above. For items 4 and 5, they aren’t really attached to a particular feature, they are more like the boundaries of your system, like going through customs. They are related to a physical, geographical separation between the external world and the bowels of the ASIC. So this should be a separate document: the ASIC External Interfaces document. There are internal interfaces too, but you only need to document them on demand: places where BFMs will be probing/pulling for data, i.e. boundaries between the provinces of the ASIC country. So for the internal interfaces, have a 3rd document, the Internal Interfaces document, generated on demand only! You create this document only if others need to know how to interface with your internal stuff.

And while you are at it, why not engage the verification team early: they are the first customers of the ASIC, long before the software team. So instead of having them dream up a massive verification environment, have them write the Detailed Feature Guide. Of course, you’ll have to talk with them regarding the content, but let them do all typing and the editorial work while you are busy figuring out whether you use a RAM of a sea of flops.

Lastly, you should also engage the software team on all this. So have them write the Programming Guide while the verif team is busy writing the DFG. So what you have is a fully parallel documentation delta force working for you:

  1. Verification team writes the Detail Feature Guide (DFG)
  2. Software team writes the Programming Guide (PG)
  3. Design team writes the Internal Interfaces Guide, only for the interfaces that are needed by the verif team (for BFMs), or the other designers interfacing to your sub-block.
  4. Three documents, three teams, a triangle of power, a delta force at your service. D’oh! I forgot the backend squad! Here it goes:

  5. Design team writes the Internal Description document, for all the things only backend cares about (RAM vs. sea of flops).

And for the External Interfaces document, I don’t really care who writes it, everyone needs to know whether it’s PCI or Utopia, and it’s usually already described somewhere else like in a standard.

At this point you are maybe getting anxious about having your verification team not writing the verification environment document or the verification plan, but they need the feature desription to know what to test, and the designers are usually overloaded towards the first half of a project translating marketing requirements into real world hardware. So have the verif team write the documentation they need. The verif team can develop their code while the designers write the RTL.

And bonus points if you find a way to cross refence external software register names between all 4 documents.

ASIC Verification is software development, not hardware

Why do I end up reading about the Knuth Shuffle when I try to verify whether all the different sequences of bus transactions have been tested? Why does it make more sense to me to use an SQL backend to handle loads of timing data rather than do it with a perl script like a hardware designer would do? Why do I laugh out loud when I read “How to write unmaintainable code“?

Simply because ASIC Verification is a software development activity. One hundred percent a software activity. Sure we bring up waveforms and run verilog simulations all the time, but who thinks in terms of transistors and logic gates anymore? At most, you need to understand the difference between synthesizable code, and the code your backend guy will reject because some obscure tool in the backend won’t take it. But other than that, as much as a hardware person you think you are, you are really only writing software. Software that compiles into millions of logic gates. It would compile into machine code and you, the ASIC Verification engineer, would not know the difference.

However, there is a slight difference. Once the chip is released to the fab, it’s gone. It’s over. The bugs that are in it, are in it for good. You don’t patch hardware, you don’t release 4.0.6.5 when 4.0.6.4 has a bug. Unlike software where new releases come out all the time because users are just an extension of QA, an ASIC cannot come out every week because hardware must go through extensive QA tests which software is never subject to: static discharge, temperature, humidity, power rail variations, etc. Physical things you see, take more time than testing a button on a web page. Plus, you cannot download a new graphic processor from sourceforge: physical things have to be fabricated. This means that the ASIC better be close to feature perfection when it’s time to release it.

This also means that the QA team for the ASIC (i.e. the ASIC verification team) has to anticipate all possible usage models: everything that software developers are going to throw at the ASIC has to be tested in simulation ahead of releasing the hardware. Every single driver that will be written for the ASIC has to be anticipated by the QA team, and everything those drivers will ever do has to be simulated. I just have one thing to say: wow.

This is why your ASIC Verification team (aka QA in software jargon) uses make, python, MySQL, git, and needs to be managed like they are software developers. This is also why they code using object oriented languages. This is why they use every feature their revision control software has to offer, and why they are not afraid to merge their code into what looks to the hardware designers like a code clusterfuck. It’s not a code clusterfuck, it’s software.

But there are still a few things to learn for ASIC Verification engineers: the lessons of software development. Recently, I have read rands in repose‘s recent book (managing humans), and an excellent post by Joel on software. Read, you will learn. But the two things that still differentiate us from software developers is that we can read waveforms and we undertand what “executing in zero time” means.