Austin talks with Ravi Subramanian, Chief Products Management Officer at Synopsys, about the company’s recent major announcements. Ravi breaks down the billion-dollar deal with Amazon to create application optimized IP and the new partnership with OpenAI to build GPT Synopsys, a specialized frontier model for chip design. He explains the business model for custom IP, how AI agents fit into the EDA workflow, and why physics remains the ultimate ground truth.
This episode is presented by Crusoe. Try Crusoe’s managed inference for open models with $5 in free credits: https://semidoped.com/crusoe
Things we cover:
Application optimized IP vs. standards-based IP
The new royalty-based business model
GPT Synopsys and the OpenAI partnership
Agent engineers in the EDA workflow
Front-end vs. back-end chip design
“In AI we believe, in physics we trust”
This podcast is lightly edited for clarity.
Application Optimized IP with Amazon
Welcome everyone. I’m Austin Lyons from Chipstrat and with me is Ravi Subramanian, Chief Products Management Officer at Synopsys. We are live here in New York City after Synopsys’s Investor Day. And two big announcements yesterday. One was the announcement with Amazon for custom IP. And I think that was valued at over a billion dollars. And then the second one, and surprising and interesting one, was the announcement about the OpenAI deal with GPT Synopsys. So I want to get into both of those for our listeners and I’m also going to just go deep into AI for EDA. So first of all, Ravi, thank you for being here with me this morning.
Ravi: Great to be here, Austin.
All right, so let’s get into it. Tell me and remind listeners who may have not seen Investor Day, what was the announcement with Amazon all about?
Ravi: Sure. The announcement with Amazon was about application optimized IP, which is a key trend going on in the semiconductor industry. And if you look at how the building blocks for semiconductors called semiconductor IP have evolved, these are building blocks that allow customers to dramatically accelerate the time it takes to build their chip because they don’t have to design these blocks. So typically at the beginning of a chip product, a team is thinking, what are they going to make themselves? What is core and then what is context? What are they going to buy? Design IP is readily available off-the-shelf IP. And Synopsys is a leader in interface IP, which is the IP that connects cores, blocks to each other. Arm is a leader in processor IP. So we’re complementary in that way.
For the better part of history, the IP business has been standards-based. You may be familiar with USB, PCIe, et cetera, and on your channel, I know you have a lot of great analysis on that. Standards-based means there’s a standards committee. It’s working to develop a standard with industrial commercial members. And then once the standard is ratified, people can build products to those standards and you have an assurance of interoperability between those standards. What’s been happening recently over the last five years is the rise of custom silicon is growing. And that’s really first and foremost being driven by hyperscalers. And it’s becoming customized primarily because workload specific semiconductor design is becoming so important for them. For many of these companies, there’s really only one or two applications that drive all the revenue and the profit in these companies. So it pays to optimize the full stack, rack to chip.
So in that context, application optimized IP is IP that is optimized for the application in which the chip is living. So you may have a PCIe Gen 6, but you also may have an ultra low latency PCIe Gen 6 to get much, much faster time. For example, we’re here in New York City for people who are doing high frequency trading. It’s a very, very desired customization. So application optimized IP is something where you build once and you actually customize it and that is optimized for a workload. This is what we announced with Amazon, which is a multi-year, billion dollar plus deal to deliver application optimized IP, which typically would mean from the system level, they are driving the specifications, which come down to the actual IP level. So it may be connecting CPU with a AI accelerator, AI accelerators to memory. So you may have heard all the standards that are on your channel, PCIe, HBM, LPDDR, UCIe die to die, and Ethernet. And these are really the five key interface IPs and that’s what customization is all about.
The Business of Custom IP
Okay, interesting. There’s so much here. This is great. Okay, so first, let’s start with IP. So, for anyone who’s written software, it reminds me of just taking a library off the shelf to do some sort of function as opposed to rewriting everything by hand. I remember when I first started writing software, I was literally writing everything by hand and then once I discovered that you could get software libraries where people had already built it for you, I was like, whoa, this is way faster. I could just take Lego blocks, put them together and focus on essentially the application logic. And so it’s that’s exactly the analogy. Perfect. Okay, so it sounds just like that for hardware.
Now, you talked about having standards-based IP, which would sort of be like, hey, I need these components to talk to each other and there are standards bodies who define this communication in between blocks so that everyone’s components are interoperable. And that’s more of your traditional standards off-the-shelf IP. But then you’re talking about here, say making a AI data center with an XPU at the heart of it and now you want these interfaces to be custom so that they can be extra optimized for that one particular workload that now we’re running at giga scale. Okay, so a couple questions that I have there. First, talk to me about the business model for standards-based IP versus custom IP because obviously standards-based and I think Saseen called this factory one, build it once, sell it to hundreds of people. I can wrap my head around that. Now, the custom IP, that’s build it once, but it’s custom for that one customer. Of course, it’s very huge customers like Amazon with Tranium, Graviton and Nitro. But clearly that has to be a slightly different business model because you’re only selling it to them. So how does it work?
Ravi: So in what we have with Amazon, first from a business model. So let’s start with factory one actually. That’s where we have an NRE, non-recurring engineering work and then the actual license fee for the use of that IP. In that case, standards committees take about almost three years to get to a standard. And the two things about a standard are number one, achieve the functionality and performance required for that specific function, and then it doesn’t actually say anything about how you implement it. So that’s where the engineer’s creativity comes into how are we going to achieve a PCIe Gen 7 or Gen 8? What architecture is needed? What things are in the analog world? What things are in the digital world? And then what’s the total power consumption, latency, et cetera. So a lot of everything about how it should be implemented is not in the standard.
What’s happening now and the rationale for application optimized IP is we don’t there’s no three years. People want to actually take some of these standards ideas and take a pre-ratified version of a standard and do some things to begin start using it earlier. So in that case, what we have is first a license fee. Then we have a customization fee and Saseen explained yesterday, there’s a very large scarcity of resources in the IP design world. And so from an engineering perspective and how we look at staffing, we have very specific slots. For example, we have eight engineering slots for UCIe or three engineering slots for PCIe. We have to prioritize those resources and to define, okay, what is the business opportunity we’re going after. So that customization fee is really allocating that slot of engineers for these customizations for this customer. So that’s why Saseen called it a prioritization.
So the customers in terms of what they work with us, if you remember, there was a slide where Saseen was saying what was the difference between one and two. And in factory two, we actually begin with the system level requirements. Those system level requirements as you go down through what does it mean for the chip and how it’s communicating, translates into chip level specifications, which are really the IP specifications, but some of the customizations would come around latency, throughput, how many picojoules per bit. And through a variety of different figures of merit that they want to target. It’s still standards-based. It’s not a completely off-the-shelf non-standard, but it’s taking the standards-based approach, but really optimizing or customizing based on the workload that’s running.
A simple way to make this real is suppose you have ad server software that’s running. The response time to serve an ad is a key figure of merit. Typically, as a chip designer, you may not think about that first, but now because of workload specific requirements, your response time, you may recognize an image and then decide to serve up an ad based on an image. That latency completely determines how many ads you can serve across millions and millions of customers. That becomes a key driver for the latency in a PCIe, either a switch or an endpoint, et cetera.
And then the third element of the business model is royalties. So this is really looking at how do we participate with our customer to we do the customization, but we look at the economics for the customer across license, customization fee and royalty. And so this will be the first time Synopsys is actually driving to a royalty model. And with the agreement with Amazon and others we haven’t mentioned, that’s the direction for application optimized IP.
Differentiating IP and Compressing Timelines
Gotcha. Okay, that makes a lot of sense. A lot of follow-up questions. There’s so much goodness here. Okay, so first, one thought, with the standards-based IP, my first thought was like, hey, if you’re designing IP to a standard, it feels, I’m wondering how a person differentiates because there’s a standard and so it feels like anyone else could design to that standard. But what I heard you say was the standard defines how the interface should happen, how the communication should happen, but it doesn’t touch on any of the implementation details. So, even though there’s a standard, you can still differentiate from other people making standards-based IP based on your implementation.
Ravi: Absolutely. And, standards specify the protocols, the electrical interfaces. It doesn’t specify how much power it should take. It doesn’t specify whether you should do equalization in the analog world or the digital world. And it doesn’t specify the packaging that’s needed. Right? And it doesn’t specify anything about the system environment it’s going to live in. So, those are all opportunities to differentiate in that you can have the lowest power, lowest latency, you could have the smallest form factor, you could have a north-south very thin implementation of that IP, so it could fit in a very particular way on a die. Or, and so everything down to the actual shape of that IP is where you can differentiate.
Gotcha. That makes a lot of sense. Okay, so, and really what you’re talking about is like, which figures of merit are the most important when designing this IP? And even in the standards-based one, I’m wondering, do you have different implementations of a given standard? Like if someone comes to you and they have different requirements that they’re trying to fit it into?
Ravi: So, definitely, and maybe some of the biggest areas have to do with having low power. And what techniques are you using in your implementation to achieve low power? So, the same PCI generates standard, two different IPs providing the same functionality, but dramatically different power. And today, there’s so much pressure on getting lower and lower picojoule per bit that’s being pushed through. You see really creative implementations and, yeah, the best place to get a front row seat at that is to go to ISSCC, the International Solid-State Circuits Conference, every February in San Francisco, where all the world leading chip designers coming in with their chips, and they’re showing how they achieved amazing figures of merit, right, from a key IP building block all the way to a full chip. And it’s just amazing what creativity there is, but that is what the innovation that’s fueling circuit design today. And continually understanding how do you harness what is possible in terms of energy consumption, what’s possible in terms of data flow architectures and latency, how do you have your hardware and your firmware hardware interface to be able to have very fast reconfigurability of these IPs, a very, very rich source of engineering ideas and creativity.
Amazing. Cool. So, when these two different IPs are designed, one is super low-powered and one’s not, there obviously the other one must be prioritizing something else, or there’s a cost for that super low power.
Ravi: Yes.
So there’s a couple different design trade-offs that are made. And yet, I’m sure you have a certain portfolio, a few SKUs, but then it sounds like with the custom IP, the application optimized IP, your partner, in this case Amazon, is saying, hey, still those handful of off-the-shelf ones aren’t quite perfect. We think we could take it farther. And you’re starting at the highest level, probably like the rack scale or even the data center scale thinking and deciding what is the figure of merit, like as a product manager that’s prioritizing, what is the figure of merit that’s most important to us? It might be power, and what are trade-offs we’re willing to make? It might be cost or die area or something. So then that’s coming all the way down and then it’s getting customized. Now, you talked for the standards-based IP that there’s a licensing fee and NRE, which is that NRE like, does every customer pay the NRE or is that kind of like a we designed it once cost that gets amortized or what like explain that NRE.
Ravi: So, depends on the nature of what the implementation is. There may be an IP that’s not available at a certain foundry on a certain process node. Right? So, if you look at the whole spectrum, there’s the IP, there’s which foundry and process node it’s available on, and then there’s the, I’m going to say, kind of envelope for the standards compliance, right? And a good way to think about that is, a PCI standard, I know we’re keep talking about PCI, but or a UCI standard, actually, we should start with UCI. It’s a standard that’s not a standard.
That’s what I’ve heard. Yeah.
Ravi: In that every customer wants a different number of of ports. So, there’s some effectively NRE required. You need to be standards compliant. The standard really doesn’t say that you can’t have something with only two wires instead of six. So, that’s the type of NRE, right, that we’d have to do. You can say, well, hey, isn’t that a factory two because you have to do some customization? The way to think through this is, once customization is really a challenging our engineering scarcity, or the needs challenge our scarcity, we really need to look at how we allocate those pieces. UCI complexity much smaller than PCI or others. So, there, we have some engineering work we need to do, but typically you’ll see the NREs associated with, well, we don’t have it on this process technology. Or they want it, being able to talk to something else in addition to what there is. But, those are things which we can amortize, right, across the whole, opportunity for that IP on that node.
Sure, sure, that makes sense. And then, to the factory two, the application optimized IP, you mentioned the customization fee, which you explained that nicely, it’s more of the prioritization fee. And then, of course, the most exciting part, the royalties. Of course, this makes me think of Arm’s business model, and you actually mentioned Arm earlier, where you’re talking about interface IP and their processor IP. So, yeah, tell me about the exciting opportunity there with the royalties, because obviously, with the licensing fee, you guys get paid up front, presumably, for each like design start, but with the royalties, once the design actually gets manufactured, that’s when you collect the royalty. So, it feels like there’s lots of upside, especially for a customer like Amazon, who’s deploying millions of Tranium chips.
Ravi: Indeed. So, Amazon as a lead partner will be lead in driving the specifications of what gets built. But there’s a good story here to share. If we rewind history and go back about a decade ago, when Arm was a mobile processor company and they wanted to enter the data center market, Arm and Amazon entered a relationship, which was really about application optimized Arm processors for the data center. And with AWS deeming a lead customer at the time, really drove the evolution of that IP into the data center world. It’s a very similar analogy here. Right? So, indeed, the opportunity for royalty is is very good, but if we look at the economics of what we’re investing, significant investment, right, to get that return and and really make the economics work work for both parties, really look at a model. the type of chip, the volume of chip, and what’s the IP content.
And so it’s pretty standard in terms of the model used for royalty, it’s well understood. But it’s the first time now with Synopsys, by spending actually in the silicon stream. We announced Amazon yesterday, and as Sasin mentioned, there are other companies already that have we’ve closed these business with and we’ll look forward to sharing those details.
But, it’s really driven we see by one major thing and and why it makes sense for these customers. People want high quality IP available within a specific time window. And today, meeting that time window is so critical. And if you miss a generation of what we call application optimized IP in a year, then you miss a generation of your chip and what you can do. And in the high stakes game where companies are introducing new chips every year, and the whole merchant to using your own custom chip is the stakes are getting bigger and bigger. The pressure we see on these teams trying to reduce the time of a particular generation from 18 months down to 12 months, and making sure they get to a very specific market window. And and so that is the challenge and so the if you will, the commitment is to be able to deliver high quality IP on time.
To get that quality, some of the customization includes, well, you should verify the IP in the context of the system. So what are the test chip starts changing in its definition, so you can bring up the chip much faster. You have a team to support the bring up of the IP at the customer. Don’t stop at the door, hand off the IP and say, you know, you’re on your own. So it starts really integrating Synopsys success with the customer success of getting that chip into a system. And so you see there’s a lot of alignment of interest now that Synopsys should be aligned with the customer to get that working in their product.
The Chip Design Workflow
Yeah, yeah, that makes sense. And you also make an interesting point where this gives Synopsys, traditionally an EDA company, an opportunity to be part of the design at the architecture level, the whole rack system, maybe the whole data center level, all the way through to system validation.
So, of course, that’s EDA, that’s also IP. There’s probably opportunities, you know, all the way down through simulation.
Ravi: Indeed.
And then when you talk about making a test chip, Synopsys then is doing the front-end design, back-end design, and are you’re actually manufacturing the chip?
Ravi: We we do hundreds of test chips a year.
Okay.
Ravi: Right? From our just existing IP business and that’s just part and parcel. A key reason for Synopsys leadership is every single IP is silicon proven.
Nice.
Ravi: And you will see LinkedIn posts with eye diagrams showing, you know, we’ve got our first, you know, so many gigabit per second IP out there. And that is what allows customers to trust that, okay, this is going to come up and it’s going to come up right. Now the challenge is not just that the IP should come up, the IP should come up in the context of the system. The customers have been living with this challenge more and more as the systems get more complex. And we have to participate in that success because that’s the window of time.
Yes, yes.
Ravi: And it ranges all a number of things. Yesterday we shared at our investor day Etched, which is a company that’s building a new type of processor. After they got their chip back, it took 44 days for them to get the workload running successfully. They did all of that with Zebu emulation. We have IP ready on emulation, that’s what we call IP kits. So, all of that allows them to really compress the time it takes so that as soon as the chip is back, they’ve done all this validation before. So, they have high confidence of how fast they’re going to be able to get the workload running. But that’s IP coming together with hardware assisted verification, coming together with system validation.
Nice, nice. Great opportunity. And so, I like that you frame it around compressing the time and just ensuring that your customers get to market on time because that’s what it’s all about with this with these data centers and and, you know, the race to the next biggest model and so on and so forth.
So I’m going to use that to shift us into AI for EDA. So, you know, compressing time is what it feels like it’s all about. We know Richard Ho and OpenAI, partners of Synopsys, had the jalapeno chip, which everyone was very excited about how quickly they were able to shrink down the front-end design.
So tell us about your Synopsys’s agent engineer portfolio and maybe for people who aren’t as familiar, like, tell us about like the front-end design and back-end design and where agents using Synopsys tools fits into the agent engineer portfolio.
Like, help us understand exactly where what the agentic AI is doing and then where is the handoff to the Synopsys tools?
Ravi: Sure. So, maybe the best place to start is if you look at the stages of of chip design, on the front end, you’re actually, you have a specification and you’re trying to write the description of the function. This is typically done in RTL hardware description language. And so it’s very much like writing software. You have a large piece of software that describes the chip. Each of those blocks that are there that are and that are ultimately connected to create the functionality of the chip, the design and the verification is the writing of the RTL and the verification that the functionality is correct.
Verification today also goes into, for example, if you’re in a robotic or a automotive application, is the RTL safe? Means does it fail safely? So there are a whole bunch of verification associated with that. Is the RTL secure? Do you have a threat set of threat scenarios that test that RTL, whether it’s a block, a subsystem, et cetera. So all of that verification goes on taking a specific design under test and then really challenging it. Functional verification requires getting enough coverage. And a good way to think about coverage is, if you have, you know, a four-bit circuit, you’ve got two to the four states. If you have a billion gate circuit, you got two to the billion states. And it’s going to be impossible to cover two to the billion states. So the notion of coverage is to say, how many of the states that are important have you actually tested? And it’s impossible to test 100% of them. So you need to be able to explore the state space to understand, well, you know, you’re running the simulation, but it’s not giving you any more coverage. So it’s waste simulations. Don’t spend more time simulating that. So in the front end, it’s all about design and verification of the functionality and, you know, any other capable features such as safety or security.
Then it’s about, well, I’m going to implement this. So is this RTL actually the lowest power? Two individuals can write RTL completely separately. Each one thinking about their own figures of merit and come up with completely two different languages with two different powers. So, how is this RTL going to translate into power, into performance, and into area? So, in the front end, people want to be able to really get to a conclusion where I’ve got my RTL defined for all the blocks, and I’ve got a good understanding of the power and performance and area. The minute you start getting subsystems, it’s not just a power consumption of one or the other. In many chips now, they’re turning on and off different domains when they’re not using them to be able to minimize power. Or they’re putting thing into just dripping or sipping current just to keep it at a quiescent pace until it’s needed again. So many, many things are explored in this front-end phase.
And then it comes down to, okay, actual implementation, where you’re deciding, you’re starting to use very specific rules about how to build things for a specific foundry. And look at the actual synthesis placement routing and the actual implementation. And that gives you a view where do I actually achieve the performance because of the distance between blocks, the wires between blocks? How should you think about clocking? How should you be thinking about the communication of signals? But on physical placement, it looks like, oh, I’m putting this software closer to this because there’s so much more data that affects power.
And then finally, there are set of tools around manufacturing and manufacturability, which is really guiding the a customer tapes out, but you tape into a foundry. So, foundries have a tape-in process where they determine, are they going to accept the database you sent them and say, yes, it adheres to all the rules that I require in order to actually start designing this. So, that’s the front end, the implementation, and then the manufacturing piece.
AI for EDA: The Agent Engineer
Ravi: Now, AI in chip design in Synopsys view is really about exploiting the power that intelligence brings in terms of the capability to move from automating to assisting to then starting to create things that are more autonomous. So, EDA, the A and EDA is automation. As workflows get more complex, many of the tradeoffs between steps in a workflow are not so obvious. So, assistance can start bringing knowledge about different things, different pieces of information in the workflow to the designer to think about how can I further optimize. In some cases, ultimately it’s assistance because it is it is a co-pilot with you, if you will.
And then autonomy starts the process of starting to use reasoning and some decision-making to relieve the user of making those. The user is still a human in the loop to check the results. But the decisions made on how to get to the fast the best solution starts becoming autonomized. And then finally, in more complex things, you have more long-running jobs, which are not about time, but are about outcome. And there, you want to basically combine reasoning and and and the autonomy to be able to sequence how it’s doing work, taking advantage of calling the tool. So, that’s our spectrum and in Shankar’s presentation yesterday, he had a whole evolution of how this is going to autonomy.
With Synopsys, the way our autopilot platform is set up is really we spent almost, I’m going to say 18 months, really understanding there is how we think about selling AI in EDA. There’s how people are going to consume it. So, there are a number of things we were testing about how people want to consume it. And one thing came out really clearly. People want to think about AI in a similar way about they think about, I have a budget and I’m hiring verification engineers, design engineers, implementation engineers. They have skills. If I can think of AI as it’s coming to me with a certain set of skills, then I can easily relate to how I’m going to use it in my work.
And what we’ve seen in many of these companies, they’ve started off with, well, this year, my MBO is to learn about AI. The next year, my MBO is to find a pilot project and try out AI. And then the third year, start using AI in some part of a chip development effort. Of course, that was earlier. Now, time scales have compressed. Everyone wants to they hear about their colleagues and what they do and they go, I want that.
So, that immediately drives to a different paradigm and our platform is really thinking with the concept of super agents which are really long-running agents. Then you have the task agents and then you actually have the tools. So, if you look at agent engineer, the notion we introduced about a year ago, making agent engineer real for verification. There are a set of tasks. You can that agent engineer based on debugging something or verifying something, basically represents to the user, these are the type of skills I can get, these are the tasks they can do, and they can call the Synopsys tool. And that’s across the every stage in the EDA design process, chip design process, but also in the simulation and analysis process for mechanical, thermal, computations with dynamics.
And we’re not done yet. We’re really thinking about what’s the best way and the easiest way for customers. How can I adopt this on my team? Can a verification engineer say, I’m going to check out 20 verification agent engineers today. So, engineer paired off with agent engineer and the agent engineer brings a set of skills. And this engineer and this engineer says, I’m going to have that focus on root cause analysis for all the bugs. And then I’m going to review what the fix is. And so the nature of each of the original EDA jobs starts changing to be a co-working with the agent. And every day you’re coming in, you may be doing a very taking a agent engineer for verification, but doing very different things with it. So, we think the engineering landscape is going to dramatically change, but it’s going to make engineers, I agree with Richard, super engineers. It’s going to make them much more powerful in what they can do. And the long-term vision for us is we see so many companies in so many industries wanting to build their own chips. And in order to be able to do that, we need to make it easier to build chips, but we also need to have the ability for many industries to create those chips. And we think AI has a very fundamental role to play in driving the growth of the world.
GPT Synopsys and the OpenAI Partnership
Yeah, definitely. So, okay, I have a thousand questions, but I’m being told that we only have like five minutes left. So we’ll have to do a follow-up to dive into this. But that’s very helpful to understand the front-end design, the back-end design, the design for manufacturability, useful to understand, you know, Synopsys tools, and then agents that can do tasks with those tools, and then, a higher-level agent that can essentially sort of supervise or help take a task end-to-end.
And then, of course, the human at the top who can come in each day and think about the outcome I need to accomplish today and which agents am I going to use. So let’s talk about the GPT Synopsys announcement and then how does that fit into using agents? Like, where do I use GPT Synopsys?
Ravi: Sure. So, starting point is if you look at what we announced with OpenAI, it’s really the alignment between the two companies that for being able to apply frontier models and frontier intelligence to chip design, it requires a strong collaboration. And the leaders collaborating to create leadership is really the theme. And we are both aligned on really enabling many more industries to be building chips. So, today, GPT Synopsys, as we announced, is a specialized frontier model, specialized for semiconductor design with Synopsys tools. So, the way the model is, you could think of the autopilot platform that was introduced or a customer’s platform. Those platforms essentially have compute and LLM optionality typically, which means they can pick whichever LLM they want and they pick the compute resources.
What we see with customers is the application of AI, they want to get good quality of results, which means models really need to understand chip design. And second, compute is becoming a limiting factor. It could have way more licenses, but they if they didn’t have the compute. And Saseen shared yesterday what we’re hearing from customers in terms of their need to have more licenses to be able to drive the ability to use AI across certain parts of the chip world.
So, where the GPT Synopsys fits is each of these agentic platforms have an LLM optionality. GPT Synopsys can be that LLM. And the way with OpenAI, we decided how are we going to bring this to the world is it’s going to be a service where OpenAI provides the specialized frontier model that was carefully developed with Synopsys. Set of compute needed to run that. And the forward deployed engineers to be able to make sure our customers could actually leverage that. Synopsys brings the tools, the expertise, and then the skills that are needed to essentially make GPT Synopsys an expert user of a Synopsys tool. What that means is the productivity of the user is significantly enhanced because they’ve got an expert tool user there. They don’t really need to explore so much. You can explore much faster with it.
And that’s how we’re bringing it to market. So customers may use OpenAI’s cloud compute, their compute resource. customers may want that model resident on premises so that OpenAI would essentially have that running on their own premises. Right? So one of the key things and and you probably are hearing, you know, spending more time thinking about, well, what is AI and how do customers want to consume it? is a significant investment for us in I’d say using the the rule the Lord gave us two of these and one of these. It would be wise to use that in that ratio. And and really understand how can it be easier to consume this? And we’re really excited with the early semiconductor companies we’ve been working with. This has been long in the making. But we all shared a vision about, you know, what do we need to think about everything from what the engineer needs to security, to protection of data, movement of data, and then how do we challenge solve those biggest challenges including computing?
In Physics We Trust
Yeah, yeah. So I’m thinking of GPT Synopsys as like a turn key option where I get a great frontier model fine tuned using Synopsys tools and with the compute or get that compute on premises of course.
And for deployed engineers because nothing is actually turn key and so they can help ensure success. So I guess last question and, you know, we could do a follow-up on this probably alone.
But I know we’re running a short time. So then the question that everyone’s asking is where’s that layer between what the AI can do and what Synopsys can do?
And there was a saying yesterday, it was in AI we believe, in physics we trust. Maybe explain that in like 30 seconds and help us understand like why AI isn’t the solution for the physics and the Synopsys components.
Ravi: Sure. So I think there’s fundamentally two things when we think about building a product. And that is what’s the ground truth? And the ground truth is what you see when you have the physical product in front of you and it is operating in the world that it is meant to operate. Our point here is the ground truth is based on physics. And not just one equation.
Just like the ground truth in, you can say the ground truth in how you simulate a crash of a car, depends on so many variables, even though you can say, well, hey, it’s just the motion of the car crashing into an object, how does the deformation happen, etc. LS-DYNA, a tool from Ansys, the number one crash simulator in the world. Why is it trusted? It’s trusted because the ground truth is matching what’s in the simulation. So, and that is over decades of how should the simulation evolve. It’s not just taking one equation from a physics book and implementing it. Similarly, when you go to doing semiconductors, the device equations for a transistor, they evolve transistor to transistor. When we went from planar to FinFET, FinFET all the way now to gate all around, and then moving to CFET, what are the things? Number of equations grows by, you know, 200 X. And so the physics to accurately model what is being built is changing. It’s not static.
And many people say, well, you know, some equations haven’t changed in hundreds of years. But the application of those equations to be confident you can build a product is not there. So, in AI we believe is the power of AI and what it can offer is what we strongly believe in. But in physics we trust is because at the end of the day, the ground truth to have the confidence, not hallucinate and be deterministic in your outcome is really what defines is a product going to be successful or not.
Yeah, yeah, makes sense, especially the stakes are so high, hundreds of millions of dollars to manufacture a product. So you obviously can’t get it wrong.
Indeed. Okay, well, we’re going to stop there. Listeners, I hope you learned a lot and enjoyed this. We have to follow up because again, I still have like a thousand more questions.
But this was a great start and big news, exciting times for Synopsys. Thank you.
Ravi: Thank you, Austin. Great to be here.
