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.

The level of teamwork was pretty cool; each having our own layer of responsibility and pulling those layers together as we moved along. I’ve never had another experience quite like it. Much more common is to have one DV person assigned to each block and that person is in charge of all of the above. No layered responsibility and minimal teamwork.

People who follow this blog know I get a little complain-y about UVM from time-to-time. To be clear, I see myself as a relatively happy UVM user who mainly thinks it’s OK. My complaining happens in times where I see UVM morph into things that are truly horrifying. The horror usually grows slowly and unintentionally. And it can get pretty bad to the point it becomes (a) very cumbersome to do simple things and (b) very difficult to undo.

Granted, it’s not the library’s fault that we DV engineers tend to push its boundaries into the realm of the intended. But… and feel free to disagree with this… UVM is still a software library full of software concepts being used by a hardware community that even after 15(?) years has yet to collectively develop the software skills required to avoid the horror it repeatedly inspires. Through UVM training and specialization usage has become more coherent, don’t get me wrong. But it does feel like our training-and-specialization approach plateaued years ago. As a group I’m not sure we’re improving anymore. Hence, I expect our mainly-OK-but-sometimes-horrifying UVM usage to continue.

What’s the deal with combining a years old verification story with more UVM complaining? Well, my complaining got me wondering if maybe there’s a better team-based model for using UVM. One that minimizes the need for understanding UVM and mitigates the accidental horror I 100% guarantee we’ve all seen.

Just throwing this out there…

What if there were a level of specialization that splits us into how DV engineers and what DV engineers engineers. A how engineer specializes in building out testbench infrastructure while a what engineer specializes in verifying product features. The what engineer leads because they know what requirements need to be tested; the how engineer is a supporting role serving the needs of those requirements. Importantly, the how engineer “knows” UVM and how everything fits together while the what engineer may not.

The closest thing we have to this now would be methodology engineers. I see methodology engineers as the folks who build strategy and IP with the intention of educating the broader team and guiding them through deployment at arm’s length. They are mainly hands-off; maybe hands-on but temporarily so. Their goal is building and promoting best practices such that they proliferate and flourish through the team. An example specific to UVM may be construction and maintenance of a customized base class library with a sprinkling of training and mentoring as part of roll out.

A methodology engineer is like a how engineer but different. A methodology engineer is promoting best practices with the hope the team uses those best practices while a how engineer is doing certain best practices for the team so the team doesn’t have to. Major difference. Again coming back to UVM, the how engineer would work at the testbench/environment level with responsibilities for stuff like skeleton environment creation and maintenance, DUT connectivity, run-flow maintenance, spawning and integrating skeleton components as required, configuration structures, customization hooks, test and sequence templates and so on. It’d be like the how engineer is responsible for everything NOT in a UVM component.

Inside the UVM component is where the what engineer lives. They would know product requirements, standards and all the characteristics of the DUT. They design the device models, checkers, BFMS and so on; probably the corresponding data types (though data types may be an area of overlap). Really, the what engineers do the critical 95% of the job that most of us should be focused on 100% of the time (instead of trying to figure out UVM).

The teamwork aspect is critical to how these two responsibilities blend successfully. Together, the how and what engineers continuously settle on the next feature to build and work out requirements for the environment (i.e. need packets from <here>, configuration of this that and the other, and the output goes <over there>). The how engineer then adds the required scaffolding after which the what engineer fills in the gaps. It’s already two different aspects of what we do. What I’m suggesting is we split those two aspects into two people.

As far as scaling, I think there’s probably an 1:N ratio of how-to-what because as the testbench matures, major infrastructure additions taper off. Exceptions would be orthogonal features that tend to break testbench molds and, coincidentally, carry the highest chance of horror. This is exactly when the how engineer is important, to focus on and maintain consistency across the testbench thereby mitigating the horror.

Splitting two jobs into two people would require more teamwork and cohesion than most of us are used to but I think it’d be doable. Best case scenario is the how engineer is always a step or two ahead of the what engineer so the infrastructure always supports the next feature on the list; that’d take some practice. Prioritization may be tricky for the how engineer if they’re serving more than one effort; but I see that settled with a bit of practice (and discipline) as well.

As for major benefits, I think there are many (maybe there’s a follow-up blog coming?). At minimum, it’s worth repeating the what engineer does not need to be a UVM expert. That’s the big one. The what engineer just needs to know where to put code as guided by the how engineer. Similarly, the how engineer doesn’t need to be a product expert – relieving another significant burden – they just need to make sure they’re serving the infrastructure needs of what engineers. Together, it means people are put in positions that leverage their strengths without trying to compensate for (UVM) weaknesses. That’s the punchline from the story I opened with: have people do what they do well. It’s productive and fun and satisfying.

What do you think? Doable? Useful? Stupid? I’m doubtful a path to a horror-free UVM future goes through the masses knowing more UVM because I haven’t seen that work yet. And UVM isn’t going anywhere anytime soon. So I figured knowing less UVM might be worth a try.

-neil