ASIC Verification is software development, not hardware
February 2, 2008 Leave a comment
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 126.96.36.199 when 188.8.131.52 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.