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

Episode Date: June 5, 2026

Daniel is joined by Nagesh Gupta, CEO of llmda.ai. Nagesh has built a career spanning multiple aspects of system design and development at companies including Hewlett-Packard, Cadence, Xilinx, and Lattice Semiconductor. He is also a serial entrepreneur. Nagesh founded Taray, Inc., which developed memory interface generators… Read More

Hello, my name is Daniel Nenny, founder of Semaiwiki, the Open Forum for Semiconductor Professionals. Welcome to the Semiconductor Insiders podcast series. My guest today is Ngeesh Gupta, CEO of Lambda AI. Ngeesh has built a career spanning multiple aspects of system design and development at companies including Hewold Packard, Cadence, Xilinks, and lattice semiconductor. He is also a serial entrepreneur. Nogesh founded Tare, Inc., which developed memory interface-generating, for Xilinx designs and was later acquired by Cadence.

He also founded Avis systems to accelerate vision and ML algorithms for data center and embedded applications. Avis was acquired by Xilings. About two years ago, Nogesh founded Lambda AI. His expertise spans startup development, product management, product development, plus chip and hardware system design. Welcome to the podcast, Nogesh. Thank you, Dan.

Great to be here. First, I want to ask you, why did you? Why did you start Lambda AI? You know, Dan, I've been in semiconductor since the mid-90s. And, you know, my first job was out of college at HP, verifying, designing, and architecting peer-risk processes. This later evolved into like Intel 64-bit architecture. So from there, I went on to become the founder of two companies,

one that was acquired by Cadence and Xilings was the other company. When I got back into running systems and solutions group at Lattis Semicter, it felt a bit of a deja-woo. And the reason I say that is chip design was still taking multiple years to do, and it was still going through iterative loops due to various reasons. For example, hardware design that starts with chip design,

and then PC board, and then finally embedded systems, it has pretty much been the same. The complexity has increased many folds, and the complexity is dealt with using point tools, that have done wonders to enable complex chips and systems to be designed, but somehow there was something that was missing. It's still taking multiple years. It is still taking too many iterations, and I wanted to change the status quo.

That's why I left lattice semiconductor to found Lambda. Interesting. So can you tell me more about the problem you're solving? Yeah. So, you know, if you look at chips and hardware and embedded software, they've multiplied in complexity. And to address this, synopsis, cadence and seamens and many, many other companies, they've innovated significantly in tools. And these are tools for simulation, tools for synthesis, place and route. And there's like quite a few other vertical kind of domains, which are involved in

creating the whole embedded systems development. And these are the tools that have been like really optimized that is what is really enabling us to create these complex chips and complex systems. Still, if you look at it, Wilson Research and Siemens actually do the study, and according to the study that was published in 2024, only 14% of chips were successful after the first tape out. And 80% of projects in embedded systems, they go through rework. And when we talk about rework, rework always happens because there's always space of design and then it goes through verification and rework always happens. But rework at later stages of the project cost about 100x more and it significantly delays the projects. For example, you know, there's been like

multiple studies that say that, you know, if a product is delayed by greater than six months, 33% of the lifetime revenue for the product is lost. And so, When we looked at the statistic, we said, OK, the tools have like fairly improved over time. And obviously the design teams and the whole teams that are designing the semiconductors, designing embedded systems, they've all grown. And people are really smart. The smartest people are actually in this field trying to design these embedded systems. Still, we are going through multiple years and we are going through iterations.

We are going through delays. So there was something that was missing here. And this is what we really wanted to go and solve. It's like, why is this still being such a big problem? So what we found out is that a lot of effort has been put into optimizing tools for specific functions, whether it is simulation, synthesis, place, and route, and so on and so forth. And this is kind of, you know, what we call is vertical optimization. But there's kind of never been an effort to optimize horizontally.

And when we talk about horizontal optimization, this optimization that is starting, that is starting from the product definition, going through like, let's say the SOC design, and then from the SOC design to the hardware design, and hardware meaning the PC board, and from the PC board to create the embedded software on top of it. So that is like a lot of things going through,

starting with your SOC design, going through the PCB design, and then into your embedded software, and so on, so forth. That's like a lot of things. And that is what we call us horizontal optimization. And that's the reason why, you know, you see a lot of these problems that are happening are because there's never been horizontal optimization going from start to finish. And how do you ensure that every group in your team, your large embedded team is working towards the same goal, the same product features that were initially set up? And this is very loosely done today.

And there's a major reason for the delays in projects. and that's the problem that we are going to solve. Okay. So what is the impact of outdated or inconsistent information on a typical embedded system project? Yeah, that's a great question because the impact really depends upon when the issue was discovered. So for example, you know, like let's say the designer is writing some code. And while reviewing the code, the designer discovers that there was something that was quite a mess and it was not quite solving. what they had intended to actually write the code for.

So that is probably the lowest impact. So in that case, the designer has written some code. And at the end of the day or end of the week, the designer is reviewing the code and finds out that there's an issue. Now, let's say that goes into verification. So there's like a release of the code that the designer has completed. And that goes through verification. And if verification has good coverage, 100% coverage

from a functionality perspective, 100% coverage from a core perspective, let's say verification forms. So then the impact of this particular bug was like about, let's say about a month or a couple of months in this case. Now, the problem occurs if all of us know that, you know, getting to a 100% functional coverage, for example, has been extremely difficult.

You can get to good code coverage, right? There are tools that kind of tell you the code coverage, but then functional coverage has always been kind of like a missing link because you get to as good a functional coverage as you can define the functionality in your verification test cases. So if this was missed during verification, then it goes on and goes on,

and it probably comes up when you're bringing up your chip in your validation phase. Now, if it comes up during the validation phase, this is basically, remember that validation is happening after your tape out, after the physical chip has come back. So first of all, it's like 10x, 200x more difficult to debug anything and kind of, you know, figure out the issue when you're in,

validation phase and of course you know the impact of something going something being discovered after the tape open when you have the physical chip is anywhere in the range of three to six months because let's say you know you can actually first of all it's like the debug of the issue which can take a significant amount of time then can you like actually patch the software in order to fix the issue and if you cannot patch the software then you have to like go back into doing a re-tape out and the re-tape out depending upon how you're going to fix it is going to be anywhere from multiple tens of millions of dollars in the current technology and a amount of time that it's going to take us like at least six months. Right. So how does Agentic AI fit into your strategy?

Yeah. So agentic AI, so the whole concept of AI has been like such an amazing technology that it is making an impact everywhere. And when we started Lambda, that was the primary premise. It's like, you know, to kind of figure out how is AI going to help. us solve some of these complex problems in chip design. So to us, it was not just about making one task simpler. For example, just making like, let's say, development of RTL, code generation being simpler, or development of the verification test benches.

For us, it was about how do we solve this problem in a much more impactful way, something that ensures that it's not just about building it fast, but it's about building the right product. And that's what we use agentic AI for. And Lambda is basically natively agentic. So we have developed several complete platforms, which is all based on multiple agents that perform various tasks.

Interesting. So what are you hearing from your customers? What are their primary needs? Yeah. So customers are actually delighted that Lambda is solving this problem. So every customer that we talk to, this problem has been there for so long. and we are really making it beginning to make significant impact to the customer needs.

So let me give you an example. So as we all know, Lib Bhutan has taken over as the CEO of Intel recently. And one of the things that if you look at the press recently, you know, Lib Bhutan talks about B0 tape out and tape outs when chips are being taped out, and A0 is basically the first tape out. And then if you're just changing metal masks, then you go into A1, A2, A3 and so on, so forth. and then the next full tapeout is called B0. Now complex chips such as processors and so on so forth,

it is typical that people go through multiple tape outs and multiple full must sets before they get it into productized release. Now Libbu actually gave this goal to the team saying that B0 has to be the last tape out. Now that is from these complex processes such as what Intel is developing, B0 is a tape out that needs to get into production. So that by itself is like a significant goal. Now, what we have also heard from our customers, there's a lot of push to go from A0 to the production release. And that's not easy to achieve. And that's basically what customers are beginning to use us for. And we are actually

getting into some of these initiatives in various companies where the first tape out, how do we enable our customers to take the first tape out, ensure that all the features are correct? directly being implemented, ensure that the data is consistent between all the different phases of the design, and that goes out to production. So that's like a significant goal here, and that's the kinds of initiatives that customers are beginning to use us for. Right. So there are other tools available that seem to address some of these issues.

Claude, for example, we're seeing a lot of clawed information. So how is Lambda different? You know, what is your unique value proposition? Yeah, that's very true. I mean, Claude is great, actually. You see a lot of the progress that has been done over the last couple of years has been because of these LLMs. And Claude is definitely being at the cutting edge. And there's also, of course, several other LLMs. But if you see, you know, we also use cloud, by the way. We use cloud. We could in fact use any of the other LLMs which are available, some of which are open sourced. And these are very effective in solving points. problems. So if you want to like actually go off and have Claude do a write-up for something, you give it like, you know, good prompts and you give it enough data. And Claude is great. You know, it can give you good write-up to get started with. And one of the interesting things that we hear from our customers is actually with the advent of these LLNs and

you know, all the engineers having access to Claude and so on, so forth. What's happening is that, you know, everybody tries to like actually go into the LLM, try to solve the problem. And And now the managers and the executives are basically looking at like 15 people trying to come up with like, you know, 15 solutions for the problem. And then, you know, they have to figure out what's right and what's wrong and so on and so forth. So very good at solving point problems. And now the real question is like, is this going to be what you want to use for production? Is this production quality? So here, let me give you an example.

We have just, in fact, you know, released a product called Lambda Spectra. and this product automates the generation of technical documents. Now, you can say that technical documents can easily be generated with cloud, but there's a difference. For companies, documents are part of the product delivery. In other words, these are not casual one-off write-ups, but these are actually delivered along with the product, and this has to be production quality.

And so what does it mean? So it means several things. First of all, it's got to be consistent in the sense that all the documents that are coming out of the company, need to have like a consistent look and feel. And then there is like a need from a perspective of accuracy and precision of the data, how much data to be presented and what is the level of accuracy and how do you ensure that the data is 100% accurate and how do you ensure that you're going to get the same results

when you keep producing these documents multiple times. So in order to do this today, companies have like a very thorough review process. They have like a sign-off process and they maintain the documents through versioning. They have this concept of what they call this incremental editing, making sure that, you know, when there's a small change, there's just that change and not wholesale rewrite. And there's also, you know, something like this actually is collaborative process. It requires a distributed team to work on different aspects of the document and then ensure that all of this is correct before going through a release.

And this is not like a casual, okay, let me give you some prompts and then, you know, let me get a document out. This requires like an agentic platform-based approach. And that's kind of what differentiates what we do at Lambda as opposed to like, you know, what can be done using Cloud or any other LLM. And this is where, you know, we use Cloud in the backend also, right? So we have basically on top of the LLM, we have implemented several different layers. So for example, we have like an LLM orchestration layer. And then on top of the orchestration layer,

we have like a platform layer. And on top of the platform layer, is that our products are built. So there's like about three layers that are missing when you directly try to interact with Cloud. So can you tell me a little bit about your product roadmap? What will we see next from Lambda? Yeah.

So what we have done at Lambda is we've taken the approach of building these layers that I just talked about, right? I mean, so these, the layer for LLM orchestration, and then the layer on top of the LLM orchestration, which we call the platform layer. And these are like, you know, very important technologies. And this is kind of what is critical in order to deliver enterprise level products. So now what we have done over the last year and a half is basically,

we've spent a lot of time in developing these infrastructure, structural layers. And on top of it, now we have started building out the products. So now that, you know, we've laid out this foundation, Lambda Spectra was the first product. And this is a product that actually enables customers to automate the generation of consistent technical documentation. So this product was launched a couple of weeks back. In fact, there is a webinar as well that is coming up. Now, what we have done is like, you know, with the creation of this platform, We are now in a position to launch multiple different products, and we'll be doing that over the next few months. So tune in and you'll be able to see more exciting products coming out of Lambda.

Great. And last question, Degas. How do customers engage with your company? Yeah. So, Dan, we recently launched our website, lambda.a.i, that was along with the product launch, the company was launched, and the website has been launched. The website provides links for various white papers that customers can reach out to sales at lambda.a.i, and they can schedule a demo. And like I just said, we also have like a webinar that is coming up.

So several different ways to reach out to Lambda and learn about the products that we are developing. Great. Thank you, Nagash. Awesome. Thank you, Dan. That concludes our podcast. Thank you all for listening and have a great day.