AI's first breakthrough in chip design is usability
When you look at LLMs, the first area where you see a major impact is usability: they make notoriously difficult tools easier to use by orders of magnitude.
Juan Carlos Rey runs Calibre as general manager and serves as chief technology officer for electronics design automation at Siemens, the software engineers use to verify and sign off the integrated circuits headed for manufacturing. In plain terms, Calibre is the last careful reader before a chip becomes silicon: it checks that a design obeys the physical rules of a factory etching features measured in angstroms, and it flags the errors that would otherwise cost tens of millions of dollars once a design reaches production. Rey has shepherded this tooling for more than two decades, through the move from two-dimensional layouts to 2.5D and 3D integration, and he frames the work as a continuous learning experience where the underlying technology reinvents itself roughly every twenty-four months.
He has spent more than forty years in high technology and roughly the last thirty in semiconductors, joining Mentor Graphics in 2001 to direct development of its Calibre product line and staying on through Siemens' 2016 acquisition of the company. Over that stretch he rose from senior engineering director to vice president of Calibre engineering and, most recently, to senior vice president and general manager of the Calibre business, overseeing both its design and manufacturing portfolios. His view of the company is long: Siemens is more than 125 years old, an anniversary he marked at the opening celebration in Cairo, and he points to its record of weathering decade-scale disruptions as evidence that a large engineering organization can still adapt and thrive.
Rey argues that large language models changed the game less by raw speed than by usability. For six decades chip tools chased performance and accuracy, and suddenly the biggest gains came from making famously difficult software easier to learn and operate. He is careful about where approximation is allowed. Surrogate models that run orders of magnitude faster are useful for exploring configurations early, he says, but final sign-off still demands tools that are provably accurate and safe, which is why hallucination stays a central concern. He holds a contrarian line on technical debt, expecting AI to reduce it rather than inflate it, and he keeps returning to domain expertise as the foundation everything else complements, with agentic workflows now orchestrating specialized agents to find, strategize, and fix verification errors.
What animates him is building things customers genuinely value and staying at the leading edge long enough to catch the next trend before it is too late. He is unworried about a shrinking need for engineers, since his teams are busier and more productive than ever, and he sees clear room for junior talent whose defining trait is a hunger to keep learning. His deeper caution is reserved for hubris: he remembers the internet being promised as the cure for every social ill, and he grows wary the moment technologists claim to solve human problems by decree. The problem he most wants to solve is a physical one, designing chips that deliver far more computation using far less power, so the machines of this era can keep growing without exhausting the world that runs them.
Read full transcript of interview
In this conversation: Josh Rubin (Host, CTO Studio) and Juan Carlos Rey (General Manager, Calibre and CTO, Electronics Design Automation, Siemens EDA).
My title is general manager for Calibre in Siemens Electronics Design Automation, but I'm also the CTO, the chief technical officer, for electronics and automation at Siemens.
Calibre you've been working on for a fair bit of time.
A long time. More than two decades.
Why have you stayed so long in this space?
Well, because it has been a continuous learning experience. Technology has been evolving. At the beginning, at just the Moore's law pace of a new technology node every 24 months roughly, that required a lot of reinvention and multiple different angles. And that has only been accelerating over the last few years, with multiple developments that are happening both on the technology and how to manufacture chips, as well as the technology on how to design chips. That is super exciting.
So on the one side, on the manufacturing of chips, you're dealing with material science, the technology to get down even deeper into the nanometers. But on the design side of this, what kind of new tools and new software has AI brought into that workflow?
AI was recognized very early on for its capabilities to help accelerate the core algorithms that are used for both the design and the manufacturing software, the software that is used for both design and manufacturing of the integrated circuits and electronic design systems in general. Very specifically, what we call AI inside, the earlier versions of machine learning, in multiple different flavors, have already proven value in improving either the performance of the tools or the accuracy of the tools overall.
Have the LLMs been a specific sea change in the kind of AI tooling that you're using to approach this tech?
It really opened the minds of everyone. Because while the focus over the last six decades, since semiconductors started evolving at a very fast pace, has been on improving performance and improving accuracy, when you look at LLMs, the first area where you have a major impact is in usability. In improving usability of the tools by orders of magnitude, by making things easier to use, by being able to do a lot more work faster, in multiple different angles where things were not really explored yet before at the level that they are being used today. If you look at it, the usability aspects to help use these very complicated tools were essentially relegated to creating a series of good graphical user interfaces, trying to make the languages that are used to execute the tools easier to use, and getting things to be connected to each other. That was the play. Today there are completely different angles: how you learn from the things that you did before, how you make sure that the tools can execute in a more automated way in entire flows. So first LLMs, then agentic flows, play a major role in completely new directions. They also play on the previous directions in a completely different way. There is a lot of discussion, and good proof points already, on the creation of surrogate models. These surrogate models tend to be unable to deliver the accuracy that is required to ultimately manufacture and design the chips. But while they do not have the level of accuracy that is required, they operate orders of magnitude faster. And by being orders of magnitude faster, you can use them in different spaces, when you're doing design space exploration, for example. So there is an entire new level of usage of the tools, and directions on how to do software development, that help the community.
When you talk about the acceleration, the speed it allows you to now have, there's that old axiom of it can be cheap, fast, or good. Is it good enough in the chip design phase, in the software that AI is obviously helping speed up? If you're a greenfield project, if you don't require manufacturing a product at the end of it, it can be good enough. Is the AI design good enough to avoid the kind of errors that could cost you, I imagine, tens of millions of dollars once you put it into production?
I guess that will probably need to be proven by enough experience of the people. But there is no question that AI can help in the direction that I was explaining a moment ago. To create any electronic system, you have no option but to be super accurate, super safe, and it is very difficult to use AI tools to completely replace the tools that are used in that space. Those tools, we don't see in the foreseeable future how they are going to be replaced. However, there is a niche that happens before, a niche where you are not designing the complete system and signing it off for manufacturing. It is the initial stages, the stages where you need to evaluate very different configurations and you are uncertain which configuration is going to be the best one. At that level, you're okay with having a close enough approximation to reality. Of course, if that close enough approximation to reality is completely wrong, then you have a major problem. So the issue of hallucination, and issues related to having robust tools that are industrial-level proven, is central. Once you fix that issue, how you can apply them to help you converge faster into the final system, there is a lot of usage.
You have enough years of developing systems to create the testing environment, pre-LLM, pre, not pre-machine-learning obviously, but these testing environments now, when augmented with AI on the front end, create more tests for you to experiment with. Is that where the acceleration comes from as well?
Yes, in many cases they do. That is one of the many aspects of usability of what I was mentioning. In this case it would be mainly the usability for the software engineers that are creating the tools, in our case. But it is one of the many aspects. What I need to reflect on a little bit here is that we, in our space, are very much an engineering company at the core. So our engineers need to be experts in how our tools are going to be used. Our tools are used to help create electronic systems, so we need to have people that are experts in that domain. Then we have software engineering, that is used as the way to create those tools, so our teams need to be experts in software engineering. Now, we are working in a field that is on the leading edge of technology. We are always working on the most advanced semiconductor manufacturing nodes, 14 angstroms, going to 10 angstroms in the near future and beyond, moving from 2D to 2.5D and 3D types of integration, having to face, every time that we move into a new technology, new physical problems. All that is within that domain of expertise that I was describing. Then, when implementing solutions in software, given that all those new technologies bring new levels of complication from an algorithmic point of view, our engineers need to also be experts in software engineering. AI is part of software engineering at the core. So our engineers need to become experts in AI and be on the leading edge of AI tools in that space. And so, when we're talking about the usability aspects, you're referring to one aspect that helps the engineering teams do their work better. There are many other aspects related to usability: how you learn to use the tools faster; once you learn how to use the tools faster, how you make optimal usage of them; how you move from doing a basic design that seems quite intuitive but perhaps is not optimal, to delivering the type of work that expert engineers produce when they have many years of expertise. So there are all those other angles that are being explored and are creating a new breed of tools and solutions.
This sounds like something that excites you in particular, the discovery of the usability. This new technology comes out, there's this new thing, and you're on the cutting edge, and your teams are on the cutting edge of figuring out what this is supposed to be.
There is a lot of talk about people being worried about AI. I think that we all need to be worried about societal implications and so on. That is a completely different direction from what I am talking about. I am very excited about all the opportunities that this brings. People are worried about the need for fewer engineers. We are not seeing the need for fewer engineers at this time. Our engineers are much more productive now than before, there is no question about that, but they are as busy as before. Everyone is working very long hours. And why are they working long hours? Because they are more productive, they can do more, and they are very excited about the usage of the new tools. There are many things that happen typically when you are developing any new system, when you are doing any new engineering development. There is this concept called technical debt that you incur typically, and it's mostly used in the software community but it happens in any engineering domain. You create a system and you end up delivering it on a schedule and on time, and you always say, 'Ah, I wish I'd had another week, another month, another two months, because then I would do these additional things.' That is one of the reasons for technical debt. And that typically gets recorded, for future improvements and new generations of products. If anything, I would expect a reduction of technical debt as one of the major implications of the usage of AI.
You think reduction in technical debt? Because I often hear from people that technical debt explodes, because you can generate so much.
I expect that it will be a reduction. If you have a series of specifications, you need to deliver to those specifications. You know that you have delivered to those specifications, but you know that you can do something better to some extent. So you accomplish something sooner than before, you are still within that envelope, and you should be able to actually do more than that.
That feels like a good engineering org will use these tools well, and a bad engineering org, of course, they're going to amass more technical debt. They were going to anyway. So best practices haven't changed for you, have they?
Not at all. Best practices need to continue being improved. And the way that we approach best practices is that we developed early on a concept of continuous quality improvement, which best practices is at the core of. So we are continuously focusing on how to improve over and over again, and we don't see at this moment radical changes to the best practices that we use, which essentially consist of a series of hierarchical approaches to the solution of a problem. They consist of starting early on with specification and test, and how to validate the usage of the system, how to make sure that the best quality is delivered. All that is at the core, and not big changes to the concepts. There are, however, as we mentioned before, changes to how you accomplish the tasks to deliver under those best practices. You were mentioning the issue of test case generation, for example. Major help in that space.
Digging in a little bit into what you were talking about: there are people who say we don't need fewer engineers, people are working harder than ever before. AI, in some of the pitches out there, is supposed to make us not have to work as hard. But I'm increasingly hearing from people, 'No, I'm far more productive, I'm working more than I was before.' And that leads to its own issues. One thing I'm hearing often is cognitive load. Humans, unlike AI, where you can throw more compute at a problem, there's a set amount of cognitive load anybody can take on. With these tools, how are you accounting for that with your team? How are you keeping them healthy, motivated, productive?
I wouldn't say that there are concerns about motivation. As I mentioned, we are an engineering organization at the core, and people get really motivated by finding new solutions to problems, being able to solve problems faster, or getting better results overall. All that is at the core of the motivation. What I would say is that things are changing super fast, and we all need to accept that and find ways to adapt to those changes, make sure that we are learning continuously, and go through this rapid-change age that we are going through. It will continue for quite some time, until we get more clarity regarding where we are going.
ROI is a big question for a lot of people at a lot of different companies. You guys are in a great position, we need more chips than ever before, there's a need for more compute than ever before, and these AI tools are allowing, according to your own data, operating seven times faster over here, 100x faster and more productive over there. Is that leading to a solid ROI in your own processes and as a company?
At one level, the response is simple: the ROI is there. It is at the core of what we need to measure as any financially responsible organization, and so we do know that the ROI is there. On the other side, everything is changing. The business models for the people that provide the LLMs, the business model of the people that provide the general tools for AI, keep changing. So all that needs to be continuously re-evaluated.
Siemens is a massive company with an incredible engineering reputation across the world. I don't know that an org of this size would ever be described as nimble, but you have to be now. And how, with an engineering org of this size, are you staying nimble?
Well, I will respond to this in truly general terms. And the reason why I would respond in general terms is because I represent a large portion, but still small on the overall size of what Siemens is, both in number of people as well as in revenue. So what I will respond is this. Siemens has a track record of going through major transformations over the decades. There are good examples of that; we would need to go a little bit into the bibliography and what has been published in that space, but there are great disruptions that happen within decades. We're talking about a company that is more than 125 years old. And the reason why I say specifically 125 years old is because I was at the celebration of Siemens' 125-year anniversary opening in Cairo, in Egypt. Certainly in Germany and in Europe it was older than that. So what I can tell you is that, very clearly, the company has always adapted, always succeeded in weathering the major changes, and always thriving, always growing. So I base my response on the track record.
How do you stay nimble? You've been working in this field, in this space, a long time. There are a lot of people that take a look around at what's happening and say, 'Not for me.'
By communicating a lot with smart younger people that are extremely enthusiastic, that bring a lot of new ideas to the table, and by finding a lot of personal motivation to work in that environment.
What drives your personal motivation? What is the thing that gets you up in the morning?
Well, first of all, to succeed. And to succeed by doing things that are extremely useful, that are very valuable, that are proven by our customers using them and being happy when they are using them. That is the biggest motivation that I have. But along with it, the recognition that the only way to achieve it is to always be on the leading edge of engineering, and the software engineering that is related to that. So I am always looking forward to understanding new concepts and applying them in a way that is successful.
What are the biggest challenges that you're dealing with right now?
The biggest challenges are precisely along the lines of growing, in an environment that fortunately is growing everywhere. So identifying those opportunities. We are seeing right now this complete revamping, as you mentioned before, of the semiconductor industry and electronics overall. We are seeing the tremendous need of making things a lot more efficient today, the major need of reducing power in these very large systems, the major need of being able to do much more complex electronic systems, and being able to deliver on time. All that is a big motivation for me.
What kind of people are you finding that thrive in this environment? If they gave you an unlimited budget and you could hire everyone you wanted to, who are you going out there to hire?
Given the domain and the space where we are, I really look for people that have an engineering mindset. And what I mean by that is that they care about a certain domain, and they care about knowledge in that domain in depth, or in some cases in breadth, or a combination of both. In addition to that, that they are interested in using software engineering as a way of solving those problems, and, as part of that, incorporating the latest developments, in this case any AI development that is going on out there that is going to help us in that effort. So that is what I keep looking for, and it starts with domain expertise; and if there is no domain expertise, a strong desire to gain that domain expertise fast enough.
Are there particular personality traits that you look for? Curiosity, raw intelligence, is obviously something that people look for, but what differentiates one expert from another in terms of their ability to take on and have that engineering mindset?
Well, that's definitely a very interesting question. I really think that when I look at the key experts that we have in the company, who are fellow-level people, you find so many different types of personalities that it is very hard to pinpoint a single one. Key experts, by nature, are people that are proven to have solved very tough problems and been very successful in the final outcome of the things that they produce. And, as I said, you have from people that are very much introverts to extroverts, that are very deep thinkers in a narrow area but with broad exposure to other areas. If anything, I would say that formation is very important, because it is that combination of breadth and depth that is necessary to be at that level, and I would say that all of them had a good portion of that. But in terms of personalities and characteristics, it is hard to pinpoint. In such a small group, you find such a large diversity of personalities.
Are you looking for more individual contributors, solo players out there, or people that work better in a team dynamic? Is the brand of engineering that you do here, and the kind of org that you like to have, more of a team sport?
Well, it depends. I would say that team sport is a very important characteristic, and it is necessary, at that level, to have a good breadth of skills to play well with teams. But it is always possible to have extremely successful individuals. They tend to be in a much narrower and deeper area, as opposed to areas that require a large combination of skills.
With the AI tools that are bringing so much automation into the space, yes, it's speeding things up, but there's a concern in a lot of different industries about almost a mental debt. Suddenly we lose the ability to think through, like a junior person is not coming up the same way that the seniors came up, and they lose some of the expertise coming into it.
That has always been a big concern. In order to have a successful, thriving, long-term solution, that is pretty much a requirement in many spaces. That issue is always a concern, and that is where, definitely, there is a need for teaming up and a need for compensating in other ways. So it's at the center of the general thought in that space.
Where do you fall on the junior engineer question, which is another fairly hot topic? People are talking about, 'I need experts, I need people who are comfortable with these tools, but I'm really only looking for mid-level and senior people, and I think AI has replaced the juniors.' Is there still a place for junior engineers in your organization?
Absolutely. We see junior engineers as the way to help create a healthy workforce that is efficient and effective, both things. And if you look at it, what I would say is that curiosity and interest in learning, given that you were asking before what characteristics I'm looking for, when looking at junior engineers, a desire to continue learning is fundamental.
And how else can you address the talent gap? You can either make the person you want or find the person you want. Often you have to do both at the same time.
As you said, everything is changing all the time, so the talent gap keeps changing.
How do you approach that issue?
Well, as I mentioned, domain expertise is fundamental. So the way I see it, in an organization like us, which is well established, that has decades of history and usage of the tools just in electronic design automation, the area that I represent, the growth is more organic. What I mean by that is that there is a key domain expertise that is distributed among the corporation. And then what I see is the new and junior engineers' ability to gain and expand their domain expertise into the specific space where we are working, as the key direction. But I see it as an organic growth. So then everything that we're talking about as new is an add-on that needs to complement the domain expertise that I was mentioning.
Expertise is not the end, it's the beginning of the journey for these folks. Expertise is ongoing.
Very much. And what happens is that, both on the manufacturing space as well as on the design space of semiconductors, we're not talking about a single expertise. Each one of the solutions in this space is the combination of multiple individual problems that need to be solved, and each one of them has quite a bit of depth in the knowledge that is required. So that's the reason why I put so much emphasis on domain expertise.
What problem are you most excited to solve for right now?
We are always under the daily pressures of the areas where we have shorter-term goals and objectives, and that is what tends to keep most of the time. But I think that the problem that is more concerning is the issue of using, more and more efficiently, all these skills that are developing, that are coming up, and how to provide effective and efficient solutions overall. And it is related, going back to the general topic of AI. I know that I am answering in way too broad terms, but it is very much along the lines of this continued development and introduction of new capabilities to solve problems, and being at the leading edge and not disregarding some things that are new that seem to be perhaps out of scope and in the end can have a major impact.
So it's not that much of a problem in itself; it's the concern about missing some big trend and being too late.
Well, there are so many people that are solving problems that are only problems for AI. The number of startups out there right now working in the AI space are there to solve a problem that was introduced by AI being introduced into everything. Like, 'My company is here to solve more efficient agentic workflows for you.' My problem over here is solving a real problem; you're trying to help me solve a problem that didn't exist before this thing was introduced. So are you finding, and I hope the answer to this is yes, that these AI tools are solving actual problems? And it sounds like they are. Or are your engineers spending more time solving problems that are AI-specific? 'I just have to solve this hallucination issue, I've just got to solve this agentic-call issue.'
No, it's the former. We already have lots of proof points on how AI has helped us, over more than a decade, to solve problems either faster or more accurately, when we call it AI inside. But then, as I was mentioning right at the beginning, this ability to expand into other domains is helping our customers solve their problems faster, not because our tools are faster, but because the work that they need to do is done faster. What I mean is that, moving from a specification, to the configuration on how to solve the problem, to the space exploration that you need to do, several different vectors there, it was not just about getting the tools to run faster. So there are already very good proof points on how AI helps in those spaces.
Where we've gotten time back, it has allowed us to identify problems that we can now solve. What I mean is, historically in software development, you could think, 'If only I could do this.' Well, that's going to take six months and X amount of dollars, and we could probably do it, but we don't know if at the end it will actually work. Versus now, with some of these AI tools, they can run the simulations, they can run the tests, they can build the MVP fast enough to determine, 'Oh, this could actually solve the problem that we're working on.' Is that kind of acceleration the value?
The acceleration comes from multiple different angles, and it goes into different stages. Take copilots, for example, the first phase of this major new development. Copilots are already proven. They help you in the way that you set up the tools. Before, you needed to go to the manuals and learn every detail and go into a lot of specification; now you can have interfaces that bridge that gap way faster. And that is just one example that, by AI speed today, is already old. Now we have proof points for agentic AI implementation that didn't exist three years ago, for sure, in this space, where you are creating agents to do the type of work that you are doing, and, in addition to that, having other agents that are directed by the agents that you are interacting with to do the work, having a multiplication effect on the activities. What I mean is that when you do, for example, a physical verification problem, you identify the errors, you need to define a strategy for fixing the errors and then implementing the fixes. For each one of those things, you have a series of different activities and tools that you need to implement. And then you can develop agents for each one of them and orchestrate the solution with a higher-level agent. Those are entirely new ways of even thinking about how to solve the problem. So yeah, AI is a major help in all those directions.
Outside of the Valley, people are a lot more nervous about the tech than they are here. Do you think those fears are justified, or do you think they're overblown, or is it a lack of understanding?
I believe that whenever people that are in technology, like I am, start messing around with societal issues and with implications about how things are going to be magically solved, I immediately get very concerned. So I believe that there is a reason for being concerned in that space, and we all need to be very alert. There is a lot of hype out there. If we are talking about domain-specific technical solutions, I'm not concerned about that. It's a problem when people define people as the problem, as opposed to actual technical issues as the problem you're trying to solve. When one bleeds into the other, it gets complicated and messy.
Yes. And I am very concerned about the hype. We lived it with the internet, it was going to solve all the problems in the world. And then we saw the social issues, and how bad governments interfere with the daily lives of individuals. We don't want to get there, and that was also enabled by the internet.
So chip design, and attacking Moore's law, and finding new ways of developing new processors, is incredibly important right now. The people that complain about data centers are complaining about energy consumption. It's redoing those chips to use less power that will make them more environmentally feasible, cooler, extracting less water. The technical infrastructure that you're developing here will hopefully make this technology sustainable. Is that ultimately one of the technical problems that you're out there solving for?
Absolutely. That is at the center of the major pillars of what we're doing. This is all about, in very high-level terms, green technology, because we need to make sure that we don't exhaust the resources that we have. You already mentioned all those concerns. So at the center of the things that we do, essentially related to producing more results with less power, is absolutely central. And we're talking about investigating methods, and finding methods, that produce orders-of-magnitude reduction in that space, that are necessary to continue on the pace of innovation that we need. So yeah, very much.
Be part of the
conversation.
Whether you're a CTO who wants to be featured, a company looking to sponsor, or an engineering leader wanting a seat in the room — there's a place for you here.