Verification Experts Vs. Generalists

Experts At The Table: As chips and systems become more complicated, more verification tasks get abstracted. So do we need more specialists who are experts in specific tasks, or do we need more generalists who know how to use the tools but don’t necessarily have the depth of understanding? Or do we need some way to balance both? Semiconductor Engineering sat down with a panel of experts, including Josh Rensch, director of application engineering at Arteris; Matt Graham, senior group director for verification software product management at Cadence; Vijay Chobisa, senior director for product management for the Veloce hardware-assisted verification platform at Siemens EDA; and Frank Schirrmeister, executive director for strategic programs for systems solutions at Synopsys. What follows are excerpts of that discussion. Click here for part one of this discussion.

L-R: Arteris’ Rensch; Cadence’s Graham; Siemens’ Chobisa; Synopsys’ Schirrmeister.

SE: Verification flows have evolved and grown in response to increasing complexity. What do you see as the biggest changes?

Rensch: There are a couple of things starting to happen, including verification teams in certain companies being given the authority to tell the designers which way to go. They’re also trying to make templates to improve the verification process. They’re trying to make things that are at a unit level and can be stamped out so they can verify smaller, LEGO-like pieces. You have the LEGO block, and you say, ‘Okay, I have my two, I’ve got my four, I’ve got my six, and I’ve got my eight LEGO block button things, and I can use those to stamp out other things that are bigger.”

SE: That sounds like a chiplet.

Rensch: Chiplet is a loaded term. It’s like when people say AI.

Schirrmeister: What that’s referring to is hierarchical verification.

Rensch: Yes, block-to-top reuse. And companies are building specific teams to build specific IPs, and that’s all they do. Before I was in the EDA industry doing verification work, we had to look at the whole thing where we could, conceptually, almost keep the whole thing in our head. You can’t do that anymore, so you have ‘ block-to-top reuse.’ I’ve also heard it called hierarchical reusability. There are lots of terms for this. People build these small blocks, and they have teams that just build this one block. They say, ‘My job is to build the six-by-two LEGO block. That’s all I do, every day.’ In verification, it’s even more interesting. It used to be, ‘I know how to do stimulus. I know how to do agents. In UVM terms, I know how to do all the different pieces of the UVM bench.’ I’m now encountering people who never touched a bench or never touched stimulus, so the specialization is growing. I’m hearing from people who hire verification people, and they say it’s hard to find someone who has a broad skill base to handle problems. There’s a really good book called, ‘Range.’ It’s about how generalists will rule the world, and it’s all about how ER doctors are generalists because they see all sorts of stuff, and they can’t be specialists. We’re getting down to that in our industry, as well. We’re all getting specialized, and we’re all trying to make smaller things because we can’t conceptually hold the bigger things in our head.

Chobisa: These trends are making verification very challenging. It’s long and complex. The reason for that is the software architecture defines how the hardware needs to function. Companies are not using commodity components for their designs. And as such, this is an area for differentiation amongst them and their competition. For example, Tesla is not using chips from Amazon, Amazon is not using chips from Google, and Google is not using chips from Microsoft. All these companies are doing their own designs and their own customizations. The Tesla chip is customized for Tesla cars. The Amazon chips are targeted for the Graviton server and customized for their data center applications. They are essentially doing high-performance computing. It’s similar for Microsoft. So these companies are doing silicon design and software together for their workloads or their software application.

Graham: Two of you touched on this idea of losing generalists or hyper-specialization. Isn’t that the next level of task abstraction, where we’ve abstracted to the point that whatever you mentioned is a specialization. It’s people narrowing and not understanding the fundamentals. Is that decrying the decline of the industry, or is it decrying my own descent into old age?

Rensch: It’s the ‘Get Off My Lawn’ syndrome.

Graham: I can’t crawl around on the floor with a roll of masking tape and lay out a chip. That’s a skill I’ve never possessed. And I’m sure there’s somebody 30 years older than me who would say, ‘If you can’t do that, you’re not a real IC engineer.’ Is it that, or is it something else?

Schirrmeister: It’s the complexity. It’s not that we are getting old. It’s that the chips are more complex. It’s the chip that got old, big, and we are still trying to fit. But the point here is that you again have to ask, ‘Hey, which verification team am I talking to? Am I talking to the IP team?’ Because if you take a processor, that’s complex in itself — plenty for blowing my mind capacity. So the next step is the integration verification, which they refer to as system verification. Often that’s a different team. So I’m in a meeting and I say, ‘Great, you do this for the processor, but what do you do for the system integration? Let me connect you to this guy.’ That’s number one. The complexity simply demands it from a verification perspective. The second corollary of that is the situation you see with people who run the validation at big companies. It’s very purpose-driven/purpose-built from a verification perspective that follows the IP blocks, as well. There are people who tell me, ‘If I find an IP-related bug while I’m emulating my system, I know where to go to make a change in the methodology, or look at the methodology for IP verification, because I cannot afford finding these bugs at the higher level.’ That now moves further, and you get into heterogeneous integration, and you have chiplets/dielets talking to each other, and it’s really the next level up. To Matt’s point, it’s simply so high in complexity that you have to mask away the problems underneath and rely on them to be complete. So now the kicker is, a lot of the aspects that are most interesting and hardest to find are actually not at the individual levels. They come into play when you integrate all the things.

Rensch: I disagree that specialists are the natural course of things, because you still need to have people who understand conceptually, maybe not everything specific, but all the pieces together. To illustrate, I’m going to go away from the engineering semiconductor world to toasters. There’s a really good YouTube video about a guy who tried to build a toaster from scratch. He went and mined all the materials. He did everything himself. It’s an amazing video because he tried to figure out how to build a toaster. Now, do we need to go build toasters, or do we need to go build every little piece of the chip? No, but you do need people who, in some way are generalists. Maybe it’s the AI thing. Maybe it’s AI. But you need a few of them. You can’t have everybody be a specialist. You need people who understand how these disciplines go together. I said at the beginning, I got acquired. We made register tools. A hardware/software interface touches everything. We touch software, we touch hardware, we touch verification, we touched everything — and documentation, management, all the things. And that is a skill set that is still needed. You need to conceptually understand all those things, how they play together, even though each of them has their own discipline — and there are people who are better at any specific discipline. But you need people who are generalists, and we’re losing those. That’s my concern, because unfortunately, people are retiring.

Graham: I’ll make Frank’s point about needing both and extend your ER doc analogy. I don’t want the ER doc replacing my hip when it inevitably happens in the next 10 years, and I don’t want my orthopedic surgeon diagnosing my strep throat when I go to the ER. So I’ll agree that both are absolutely necessary.

SE: This comes down to the industry needing more engineers, not less.

Schirrmeister: We often have this discussion. Do we need new job functions? One of the panels I proposed for a conference I’m helping with was, in the context of chiplets, do we need a new level of person, like knowledge base, to deal with chiplets, or is that simply the responsibility of the architect?

SE: Isn’t it the architect or the engineering manager?

Rensch: It depends on how you define engineering management. There’s matrix management, where there’s HR and there’s a guy at technical management, and then there’s the people that do both. You can’t be an expert in all those things. There are no supermen anymore.

Schirrmeister: I chaired a session at a recent conference and they were all talking about AI. They were talking about how AI makes people more productive. So the questions I asked the panelists were, ‘What’s the basic level of knowledge you have to have to actually be able to use AI productively? And How does that impact education?’ The example I’m always using is the following. I grew up in the early days of logic synthesis. I had to do transistor-based design, so I knew how the transistors were switching and everything. I had a software-educated guy next to me, and he always said, ‘This synthesis tool doesn’t work. It gives me something that runs at 100 kilohertz. I need to run it at 10 megahertz.’ So what did he do? He had an if statement. ‘If x times 15 is bigger than this set of registers added up, do this.’ I said to him, ‘Do you understand what the synthesis tool will build when you do this — a multiplier, like adding logic, which by itself takes a gazillion cycles to execute just for you? So of course, this thing will not go to your 10 megahertz, and it will be slowed down.’ The software engineer looked at synthesis as a compiler, and the language was Verilog, and that’s what he dealt with. Now we are getting to the situation where generalized knowledge is extremely critical, because you want to avoid these silly mistakes. That impacts AI and everything, because if you have somebody out of school and unleash AI copilots — or whatever they are called on very large designs — I guarantee things like I described in my own experience will happen. So this generalist is very important. It’s like a basic level that everybody needs to understand. Also, Matt was downplaying his knowledge. He knows he may not know the layout taping, how the different rectangles are all arranged, but he very well knows that these things will impact the power consumption for specific models, which he then in verification and emulation at the higher level will aggregate to get a power estimate. But now the complexity is going so much that you need to bring in the thermal guy, you need to bring in the EMI guy, you need to bring in xyz. So I agree that specialization by itself is so complex that it’s hard to understand. But I’m starting my diplomacy career here, saying this generalist knowledge is really important, too. But to me, this is a basic level of education that everybody has to have so that you don’t make silly mistakes.

Rensch: Where are they going to learn that?

Schirrmeister: From people who are not retired like yourself.

Rensch: With the schedules the way they are and everything else, how do we get these people educated in that fashion to understand?

Graham: I had the privilege of helping a friend’s son, who’s a mechanical engineering student, tutoring him through some calculus. And he, like all good mechanical engineers, asked, ‘What do I possibly need this stuff for?’ He wants to get into the construction of buildings. And I said, ‘Well, somebody in your industry needs to be able to design a roof truss so that it won’t collapse under snow, or the hurricanes won’t blow it off. But even if you don’t get into roof trust design, you need to know enough so that you can look at a roof truss and say that will probably work, and if I had to, I could do the math.’ My point there was I agree we have to educate, and we need people that know enough to say, ‘If I needed to, I could understand what’s going on at the lowest level.’ And now I’m starting my diplomacy career, with Frank’s point, of whether we will need that specialist, because the complexity of whatever it is so great that not everybody has the time. Josh, you were saying the same thing. Not everybody has the time to actually do the math on a daily basis. The other thing I’ll say is that I’ve noticed over my career that, like yesterday’s verification or logic designers, whatever they are, those same people are tomorrow’s tool builders because those are the people who know the fundamentals. They know what they want to be automated — not all of them, because not all of us need to be in EDA — and they know what they need done. They know what they’d like to see automated or advanced. And then they come and work for a company like Cadence, Synopsys, Siemens, Arteris, whomever it is, and they say, ‘Okay, I’m going to stop doing this thing that I do over and over again. I’m going to build a tool to do it.’ And that gradually abstracts the task to where somebody needs to understand it. But what’s needed in greater volume are the people who know how to run this new tool that whomever has built.