From Chip Requirements to Tape-Out with AI: The Bigger Question Isn't Speed — It's People

[Daniel Nenni]

I've spent 20 years in semiconductor design and verification. I've seen the back-and-forth, the politics, the long nights narrowing down a single elusive bug. So when I say AI is changing how engineers work — I'm not talking about hype. I'm talking about firsthand experience — building, debugging, and solving problems with AI as part of the ASIC design engineering process.

Two Real Examples​

1. Verification engineers who can now root-cause, not just report

A relatively-young verification engineer can now go beyond simply reporting that a design isn't producing the expected output. With AI, they can root-cause the exact RTL bug — and the design team needs only 30 minutes to review and approve the fix, all within a single day.

Without AI, the same process could easily take a week of back-and-forth communication and multiple trial runs just to narrow things down. And when team dynamics get complicated, things drag even longer — engineers end up doing the bare minimum and passing the ball to each other. That's not a small improvement. That's a step-change in how fast and how well we solve problems.

2. Design engineers who can now venture into verification territory

Within a couple of hours, a design engineer can fully understand a test flow and write a new test — without needing deep knowledge of UVM or C syntax. Or within a day, even a design engineering leader who hasn't written a line of scripting code in years can navigate a complex coverage scripting flow, make a targeted improvement for their specific need, and do so without disrupting any ongoing work.

This means a DE can close far more bugs before handing off to DV. More importantly, for complex issues, they can test multiple approaches, root-cause faster, and arrive at better, more creative solutions.

IP and Sub-Block Verification: No More Excuses​

One area where I believe AI will — and must — drive a fundamental shift is IP and sub-block level verification. In my view, this should now be a non-negotiable requirement across all programs. No sub-system or SoC lead should sign off on a design without block-level simulation — including IPs that have historically only been tested at the SoC level, such as clock and reset.

In the past, teams skipped IP-level verification for understandable reasons: some IPs were developed directly by the SoC team, making a separate IP-level environment feel redundant; the cost and effort of setting up that environment often outweighed the perceived benefit of catching issues that would surface anyway at SoC level; and modeling the behavior of certain blocks accurately enough to be meaningful took more time than the schedule allowed. So teams made pragmatic trade-offs. I've been there.

But those trade-offs came with hidden costs — bugs found late, root-cause sessions that dragged on for weeks, and the kind of back-and-forth I described above. The reason we accepted those trade-offs was not because IP-level verification wasn't valuable. It was because the cost of doing it right was too high.

AI changes that equation. The effort to set up test environments, write tests, model IP, sub-block interface behaviors — all of this becomes dramatically more tractable with AI assistance. The barriers that once made IP-level, sub-block verification feel optional are shrinking fast. That means the question is no longer whether to do it, but who should own it — the designer, the verification engineer, or both working in a new kind of partnership.

The Deeper Observation: Creativity Under Constraint​

People are often most creative when placed in difficult situations — I firmly believe that. But for execution engineers, time is always the enemy. Too often, engineers under pressure reach for a workaround. And once the problem is "solved," there's little motivation to go back and find a truly better way. The fire is out, the next fire is already burning.

This is not a character flaw — it's a structural reality. Engineers aren't lazy; they're rational. When the constraint is time, you optimize for speed, not elegance.

And if you think that's bad — it gets worse. (Here's the joke that isn't really a joke.) When there's a significant technical gap between leaders and their execution engineers, a whole new layer of dysfunction kicks in. The manager can't tell the difference between a workaround and a real fix, so they don't ask. They manage by schedule: "Is it done? Green? Great, next task." There's no space given for reflection, no culture of asking "could we have done this better?" — because frankly, the person setting the agenda doesn't always have enough technical depth to even know what "better" looks like. The engineer learns quickly: improvement doesn't get rewarded, shipping does. So they ship. Repeat.

With AI, those time constraints will be much more relaxed. Engineers will have the breathing room to ask why, not just how. And my advice to the next generation of engineers is this: don't just use AI to get more things done or to shorten your schedule. Use AI to learn — to explore domains you never had time to explore. Use it to brainstorm, to challenge your own assumptions, to arrive at creative and novel solutions you wouldn't have reached alone. And don't stop there — use AI to communicate your ideas better: prepare a compelling presentation, pitch your solution clearly to stakeholders, and explain complex technical decisions in a way that earns buy-in. In chip engineering, a great idea that can't be communicated is an idea that doesn't ship. That is where the real, long-term impact lies. Getting things done faster is table stakes. Thinking better — and communicating better — is the multiplier.

So What Does This Mean for How We Organize Engineering Teams?​

The AI impact is real — and it's coming big.

That brings me to the question I keep turning over in my mind: how should we restructure engineering talent in response?

There are two directions I see:

Option A — Go deeper in your domain. DE, DV, DFT, and PD engineers each become significantly more capable and productive within their own areas. AI amplifies specialists. Each discipline owns more of its scope end-to-end, but the boundaries between roles stay roughly the same.

Option B — Collapse the boundaries entirely. We move toward two kinds of engineers: architecture and thought leaders on one end, and full-stack execution engineers on the other — engineers who can take a design all the way from chip requirements to tape-out, spanning DE, DV, DFT, and physical design as needed.

Or perhaps there's a hybrid: some engineers stay deep specialists, while others evolve into full-stack executors. The real question is whether that's a deliberate strategy or just what happens by accident.

I Don't Have the Answer — But the Question Matters​

I don't have a clear answer yet. And I suspect the right answer will vary by company, by product type, and by the kind of engineering culture you're trying to build.

But I do believe this: while many companies are focused on asking engineers to adopt more AI tools, pushing for faster schedules, and shipping more products — those are tactical responses to a strategic shift. The bigger question is how we develop and organize engineering talent for a world where AI is a permanent co-pilot. How we answer that over the next few years will define who leads this industry. The teams that get this right won't just be more efficient — they'll be the ones who shaped the future, not the ones who were shaped by it.

What do you think? Are you seeing this shift in your own organization? And which direction do you believe is right?

From Chip Requirements to Tape-Out with AI: The Bigger Question Isn't Speed — It's People

I've spent 20 years in semiconductor design and verification. I've seen the back-and-forth, the politics, the long nights narrowing down a single elusive bug.

www.linkedin.com

 

[swka]

View attachment 4808

I've spent 20 years in semiconductor design and verification. I've seen the back-and-forth, the politics, the long nights narrowing down a single elusive bug. So when I say AI is changing how engineers work — I'm not talking about hype. I'm talking about firsthand experience — building, debugging, and solving problems with AI as part of the ASIC design engineering process.

Two Real Examples​

1. Verification engineers who can now root-cause, not just report

A relatively-young verification engineer can now go beyond simply reporting that a design isn't producing the expected output. With AI, they can root-cause the exact RTL bug — and the design team needs only 30 minutes to review and approve the fix, all within a single day.

Without AI, the same process could easily take a week of back-and-forth communication and multiple trial runs just to narrow things down. And when team dynamics get complicated, things drag even longer — engineers end up doing the bare minimum and passing the ball to each other. That's not a small improvement. That's a step-change in how fast and how well we solve problems.

2. Design engineers who can now venture into verification territory

Within a couple of hours, a design engineer can fully understand a test flow and write a new test — without needing deep knowledge of UVM or C syntax. Or within a day, even a design engineering leader who hasn't written a line of scripting code in years can navigate a complex coverage scripting flow, make a targeted improvement for their specific need, and do so without disrupting any ongoing work.

This means a DE can close far more bugs before handing off to DV. More importantly, for complex issues, they can test multiple approaches, root-cause faster, and arrive at better, more creative solutions.

IP and Sub-Block Verification: No More Excuses​

One area where I believe AI will — and must — drive a fundamental shift is IP and sub-block level verification. In my view, this should now be a non-negotiable requirement across all programs. No sub-system or SoC lead should sign off on a design without block-level simulation — including IPs that have historically only been tested at the SoC level, such as clock and reset.

In the past, teams skipped IP-level verification for understandable reasons: some IPs were developed directly by the SoC team, making a separate IP-level environment feel redundant; the cost and effort of setting up that environment often outweighed the perceived benefit of catching issues that would surface anyway at SoC level; and modeling the behavior of certain blocks accurately enough to be meaningful took more time than the schedule allowed. So teams made pragmatic trade-offs. I've been there.

But those trade-offs came with hidden costs — bugs found late, root-cause sessions that dragged on for weeks, and the kind of back-and-forth I described above. The reason we accepted those trade-offs was not because IP-level verification wasn't valuable. It was because the cost of doing it right was too high.

AI changes that equation. The effort to set up test environments, write tests, model IP, sub-block interface behaviors — all of this becomes dramatically more tractable with AI assistance. The barriers that once made IP-level, sub-block verification feel optional are shrinking fast. That means the question is no longer whether to do it, but who should own it — the designer, the verification engineer, or both working in a new kind of partnership.

The Deeper Observation: Creativity Under Constraint​

People are often most creative when placed in difficult situations — I firmly believe that. But for execution engineers, time is always the enemy. Too often, engineers under pressure reach for a workaround. And once the problem is "solved," there's little motivation to go back and find a truly better way. The fire is out, the next fire is already burning.

This is not a character flaw — it's a structural reality. Engineers aren't lazy; they're rational. When the constraint is time, you optimize for speed, not elegance.

And if you think that's bad — it gets worse. (Here's the joke that isn't really a joke.) When there's a significant technical gap between leaders and their execution engineers, a whole new layer of dysfunction kicks in. The manager can't tell the difference between a workaround and a real fix, so they don't ask. They manage by schedule: "Is it done? Green? Great, next task." There's no space given for reflection, no culture of asking "could we have done this better?" — because frankly, the person setting the agenda doesn't always have enough technical depth to even know what "better" looks like. The engineer learns quickly: improvement doesn't get rewarded, shipping does. So they ship. Repeat.

With AI, those time constraints will be much more relaxed. Engineers will have the breathing room to ask why, not just how. And my advice to the next generation of engineers is this: don't just use AI to get more things done or to shorten your schedule. Use AI to learn — to explore domains you never had time to explore. Use it to brainstorm, to challenge your own assumptions, to arrive at creative and novel solutions you wouldn't have reached alone. And don't stop there — use AI to communicate your ideas better: prepare a compelling presentation, pitch your solution clearly to stakeholders, and explain complex technical decisions in a way that earns buy-in. In chip engineering, a great idea that can't be communicated is an idea that doesn't ship. That is where the real, long-term impact lies. Getting things done faster is table stakes. Thinking better — and communicating better — is the multiplier.

So What Does This Mean for How We Organize Engineering Teams?​

The AI impact is real — and it's coming big.

That brings me to the question I keep turning over in my mind: how should we restructure engineering talent in response?

There are two directions I see:

Option A — Go deeper in your domain. DE, DV, DFT, and PD engineers each become significantly more capable and productive within their own areas. AI amplifies specialists. Each discipline owns more of its scope end-to-end, but the boundaries between roles stay roughly the same.

Option B — Collapse the boundaries entirely. We move toward two kinds of engineers: architecture and thought leaders on one end, and full-stack execution engineers on the other — engineers who can take a design all the way from chip requirements to tape-out, spanning DE, DV, DFT, and physical design as needed.

Or perhaps there's a hybrid: some engineers stay deep specialists, while others evolve into full-stack executors. The real question is whether that's a deliberate strategy or just what happens by accident.

I Don't Have the Answer — But the Question Matters​

I don't have a clear answer yet. And I suspect the right answer will vary by company, by product type, and by the kind of engineering culture you're trying to build.

But I do believe this: while many companies are focused on asking engineers to adopt more AI tools, pushing for faster schedules, and shipping more products — those are tactical responses to a strategic shift. The bigger question is how we develop and organize engineering talent for a world where AI is a permanent co-pilot. How we answer that over the next few years will define who leads this industry. The teams that get this right won't just be more efficient — they'll be the ones who shaped the future, not the ones who were shaped by it.

What do you think? Are you seeing this shift in your own organization? And which direction do you believe is right?

From Chip Requirements to Tape-Out with AI: The Bigger Question Isn't Speed — It's People

I've spent 20 years in semiconductor design and verification. I've seen the back-and-forth, the politics, the long nights narrowing down a single elusive bug.

www.linkedin.com

In my opinion, become a subject matter expert AND using that as anchor to broaden the skill to make oneself to be more well-rounded engineer has already been a golden career development for technical people. AI, like many other tools ahead of it, will help along this way, but the individual needs to really want to embrace that direction 1st.