How llmda.ai Coaxed Me Out of Retirement, an Interview with Kurt Shuler

Arteris is one of the most impressive companies SemiWiki has worked with over the last fifteen years. We have collaborated on one hundred and seventy-three articles/podcasts that have garnered more than two million views/listens. The success of Arteris can be easily tracked to the executive team and Kurt Shuler was the executive we interfaced with. It was a pleasure to catch-up with Kurt since his retirement and collaborate with him once again on a new venture.

You retired to Spain after a long career in semiconductors and an exciting success at Arteris. Most people stay retired. What happened?

I blame an old friend from my Texas Instruments days.

I was thoroughly enjoying retirement in Valencia, Spain. I was investing in and evaluating startups, building furniture, learning to play bass and speak Spanish. And I have two kids in middle and high school, so I was never bored. Then, out of nowhere I got a message from a friend I’d worked with at TI years ago. The message was, “Hey, you have to look at this company. They’re solving the problem you’ve been complaining about for twenty years.”

My first reaction was skepticism. Right now, everyone with a large language model and a pitch deck claims to be revolutionizing chip design. But this friend from TI knew exactly what problem I’d been complaining about, because he’d heard me complain about it for two decades. So, I decided to take a look.

For context, my path here is a little unusual. I started as an air commando in Air Force Special Operations, then went to MIT Sloan and crossed over into tech. This includes Intel, Texas Instruments, a couple of startups that got acquired (Virtio by Synopsys, Tenison by ARC), and then fourteen years leading marketing at Arteris, the network-on-chip IP company, through its IPO. I spent my whole semiconductor career around SoC integration, which means I spent my whole career watching what happens when the pieces don’t match.

One conversation with Nagesh Gupta and Mahesh Umasankar, the founders of llmda.ai, and I knew this wasn’t another “generate RTL faster” company. They were going after the thing that kills schedules. I was compelled to sign on as a strategic advisor.

So, what exactly is this problem you complained about for twenty years?

It’s the late-stage fire drill. Anyone who has shipped a chip knows it.

At Arteris I had a privileged, and slightly cursed vantage point. The network-on-chip touches every block in the SoC, so when any team’s spec drifted out of sync with reality, the wreckage tended to surface at integration. And when it surfaced, our phone rang.

The classic version goes like this. The customer’s project is humming along. Tape-out is in sight. Then validation trips over something small, say a register definition that the software team read one way and the design team implemented another way. Nobody was careless. The document was correct when it was written. But the design moved and the document didn’t, and now you’re debugging a mismatch in real silicon or scrambling months before tape-out. Schedules in this industry don’t slip by weeks; they slip by quarters.

What made it maddening is that I watched this for twenty years across every company, every geography, every process node. The implementation tools kept getting much better. But the fire drills never went away. Industry data backs up the gray hair: roughly three quarters of chip projects fall behind schedule, only 14 percent of chips in 2024 achieved first-silicon success, and the Wilson Research/Siemens studies consistently rank spec and documentation errors among the leading causes of functional bugs. A six-month slip costs about a third of a product’s lifetime revenue. That is not a tooling problem. That is a truth problem.

Why does this keep happening? The specs were presumably right at some point.

They were. Specs don’t start wrong, they rot.

A design is a living thing. Decisions get made in hallway conversations, in Slack threads, in a late-night ECO. The RTL moves on, and the spec, the user guide, the test plan, and the programmer’s reference manual fall behind at different rates. Each team keeps its own documents locally consistent, but the global picture quietly drifts apart. Nagesh has a quote I like: the question is not whether there will be drift, the question is when you’ll detect it. The cost of the fix is a function of how late that detection happens.

Then you multiply by scale. Even a modest SoC has fifty-plus people split across architecture, design, verification, physical design, board, and embedded software, usually spread across time zones, languages, and company boundaries in the supply chain. And the hardware/software interface is the killer part. Something like 84 percent of ASIC projects now include an embedded processor. That means tens of thousands of registers, and a tiny difference in one definition is all it takes.

Here’s the part I saw up close as the marketing guy who owned the datasheets and integration guides: lead engineers and architects burn up to 40 percent of their time creating and maintaining documents, and the documents still go stale. We were paying our most expensive people to do work that was both hated and, structurally, impossible to keep correct by hand.

Let’s talk about the founders. Who are Nagesh and Mahesh, and why did you believe them?

This is my favorite part of the story, because I’ve sat through a lot of AI pitches, and the difference here was that these two didn’t start with the technology. They started with the scar tissue.

Nagesh Gupta has spent about thirty years across HP, Cadence, Xilinx, and Lattice. He’s a serial entrepreneur with two exits: he founded Taray, which Cadence acquired, and Auviz Systems, which Xilinx acquired. He has lived this problem from the system and customer side his entire career. Mahesh Umasankar is the silicon execution side of the pairing: Intel’s FPGA group, Samsung, VMware-Broadcom, deep in CXL and hardware/software integration. Mahesh is the guy who has been on the receiving end of a bad spec at two in the morning before a tape-out.

So, you have two people who watched the same failure mode for decades from opposite seats. When generative AI matured, they didn’t see a chatbot. They saw the first technology that could hold an entire project’s artifacts consistent with each other, and they decided to build exactly that, and only that.

When I met them, they could finish my war stories before I did. That’s when I believed. There’s also a personal symmetry I enjoy. An old TI friend connected me to two founders who, like me, had spent twenty-plus years quietly furious about the same thing.

So, what does llmda.ai do about it?

The first thing to understand is what llmda is not trying to do. The design and implementation tools are not the problem. Today’s EDA flows are phenomenal at building what you tell them to build. The problem is the connective tissue around them: the specs, documentation, and collateral that tell the tools, the teams, and the customers what “correct” means.

llmda’s first product, llmda Spectra™, is an agentic documentation platform built specifically for semiconductor, hardware, and embedded software teams with the engineer always in the loop. It reads your actual design artifacts, the specs, register maps, RTL, and prior document versions, and drafts accurate technical documentation in minutes instead of weeks, generating 80 percent or more of a document automatically. Just as important, every section is traceable back to its sources, and the platform keeps documents consistent as the design changes underneath them. That last part is the whole ballgame. Anyone can generate a document once. Keeping a family of documents continuously true to a moving design is the hard problem.

And it slots into how teams already work, whatever their input and output formats, whether they’ve adopted AI design tools elsewhere. This is the way I think about it: Spectra hands back the 40 percent of time your best engineers spend on documents, and it converts documentation from a liability you discover late into an asset you can trust.

Couldn’t you just do this with Claude or ChatGPT?

I get this question constantly, and I’ll start by being honest: general-purpose LLMs are remarkable. I use them every day.

But a general-purpose LLM is like a brilliant intern with no memory of your project and no stake in consistency. It will happily write you a beautiful, confident, wrong register description today, and a slightly different beautiful, confident, wrong one tomorrow. For a blog post this might be OK. But for a programmer’s reference manual that a customer’s firmware team will code against, that’s how you manufacture the exact late-stage fire drills we’re trying to kill.

We recently spoke with the AI group at a major semiconductor company that had spent about six months evaluating documentation approaches, including building their own solution on top of generic models, which they priced at a couple million dollars. Their conclusion was blunt: generic LLMs alone are not the answer for engineering documentation.

The difference is the harness. llmda’s value isn’t text generation, it’s everything wrapped around it: models trained on hardware semantics, direct awareness of design artifacts, persistence across the project’s life, human-in-the-loop review gates, and continuous consistency checking across the entire document set. A point solution writes words. A purpose-built platform maintains truth.

Stepping back, why does this matter more than the latest AI design tool announcement?

Because speed without truth just gets you to the wrong answer faster.

Almost all the industry’s AI energy is going into building faster RTL generation, verification copilots, and debug assistants. All of it is real and useful, and I’m glad it exists. But every one of those tools assumes the artifacts feeding it are correct. If the spec is wrong, an AI-accelerated flow doesn’t save you. It accelerates the rework. Given an incorrect specification, today’s tools will build the wrong thing efficiently.

The economics make the priority obvious. Slips are measured in quarters. A six-month slip costs roughly a third of the potential revenue, and a post-tapeout fix runs from millions to nine figures. Trustworthy design artifacts are the foundation under every other AI investment a team makes. That’s why I think this is a bigger lever than any single tool, and it’s why I came out of retirement for it.

Any final thoughts?

Just that I find the whole thing slightly funny. I complained about this problem for twenty years, retired, moved to Spain, and then one message from an old TI friend un-retired me. My wife has opinions about how retirement is going.

If any of this sounds familiar, two things are worth your time. llmda’s webinar on engineering documentation goes live June 16, and the team will be at DAC in Long Beach in July, including a “Build versus Buy” panel that should be a lively one. Everything is at llmda.ai, and you can follow llmda on LinkedIn. If you’ve shipped a chip, these topics should resonate.

Build the right thing, fast and correct. That’s the whole message.

Also Read:

WEBINAR: Engineering Documentation is a Critical Source of Truth – Do You Know if it’s Accurate?

Podcast EP349: llmda.a’s Unique AI Fabric for Embedded Systems Development with Nagesh Gupta

Learn How llmda Uses Agentic AI to Generate Hardware Docs & Keep Them Consistent