BLOG

I’m still on both sides of the coin, after over two decades of ASIC design. Hiring and being hired. And both are not always pleasant experiences. Hiring is hard, getting a role is hard as well. We are all individuals, and individuals have an ego. Sometimes it is just the use of a particular word. Or an opinion that triggers the ego to roar its ugly head. Especially on the candidate side, you are mostly on the receiving end. There is no such thing as accountability for interviewers. In theory there is, but practically, it is always a bad idea to call out (perceived) mischief. Today I want to talk to you about both sides of the coin. Specifically, in verification.

Many years ago, in a land far, far away, ASIC design was not a partitioned job. Sure, chips were smaller, so we designed smaller blocks and modules. But we integrated IP cores back then as well. And verified the integrated top level. We designed, verified, synthesized, prototyped, emulated, checked STA, inserted DFT and ran our RTL sims on the synthesized netlist. Not the first year, but after 5 to 8 years of changing jobs and sectors, I was intimately familiar with all the front-end tools. My goal was to be a complete ASIC front end designer, project leader and manager. First as employee until the year 2010. Then freelance. The latter is my way to assure I deliver my best work all the time. I don’t take more time off than necessary. And I am committed to the client 100%. In return I can choose my benefits myself, if I want an expensive health insurance or if I want to maximize my pension funds, I can do that.

But back to verification. Back in the day, I worked for a subcontractor company that had a C++ based co-verification environment. Later I worked for several other companies that had a similar co-verification environment but with Python. That was before UVM even existed. I even have a certificate for finishing a SystemC training course from Doulos. This means I am familiar with OOP, object-oriented programming. Of course I am familiar with drivers or generators. And with monitors and data checkers or scoreboards. Environments and sequences, sequencers and compile once, run many test cases. I know how to write test cases that compile fast, run fast, and are lean on resources. Basically, verification is always part of the job. And as a candidate, people younger than I am, interview me as if I am a junior. Some grew up knowing nothing else but UVM. I try to avoid that situation, obviously. But recruiters sometimes mislead candidate or interviewer. Sometimes both. Intentional or accidental, such an interview is always a waste of time for both sides. And it is awkward in ways I can’t even describe. When I interview, I prioritize understanding the job of a verification engineer. Verification for me is about an eye for detail, questioning everything and finding blind spots. Find critical bugs fast and iron out corner cases later. Critical thinking is an essential skill for engineers, and even more so for verification.

So, this will be my new series on verification. Various things I noticed and wrote down, some stuff collected over many, many years of working in ASIC and FPGA front-end design.

You can find a summary article with links here, my most important pieces are in that recommended readings post. As always, thansk for reading!