Where to Draw the Lines with UVM

In my last blog I covered a split in UVM verification responsibilities. It was pretty popular so I decided to carry on with an example of what it might look like in a little more detail. If you haven’t read that, I’d recommend going back before you carry on. To rehash, I suggested two people work on the same testbench. There’s a how engineer who is a UVM expert that takes care of how the testbench is constructed. The other is the what engineer – a product expert – who understands the product and therefore knows what needs to be built.

How those two people work together might look a little like this…

Continue reading

How, What, UVM and Why

I have a usual go-to story for my most productive experience as a verification engineer. It happened a while ago, in the middle of my 10 year consulting stint. We were a 3-person team. I was the experienced one who knew about testbench infrastructure with a younger fella who knew about the product and a woman who was more of a firmware developer. We were verifying a medium-sized, complicated’ish subsystem that – as I remember it – included a faux processor that ran some custom instruction set.

The reason I’ve always considered this a good experience is because it’s an engagement where we took advantage of three, non-overlapping skill sets. From the very beginning, I was in charge of infrastructure (I think it was VMM at the time), young fella added most of the functionality (without knowing much VMM) and our dedicated firmware expert built out processing support. In lockstep, we’d roll out incremental additions to the infrastructure, fill in functional gaps, incorporate new FW support, run a test and repeat. Continue reading