Good afternoon, and welcome to Rosenblatt Securities' fifth annual Age of AI Scaling Tech Conference. My name's Kevin Cassidy. I'm one of the semiconductor analysts at Rosenblatt, and it's my pleasure to introduce Steven Woo. Steve is Rambus's Fellow and distinguished inventor, and is a technology innovator with over 15 years of experience in the hardware and software performance solutions. We have a buy rating on Rambus and an $80, 12-month target price. We're bullish on Rambus for the company's leadership in DRAMs, and particularly server DRAM module companionships. In our view, DRAMs are the unsung hero in the AI revolution. Larger AI models need more DRAM. It's as simple as that. I'll kick off the fireside chat with a few questions, and I'll take questions from the audience.
To ask a question, click on the quote bubble on the graphics you see in your upper right corner, and I'll read those questions to Steve. Again, thank you, Steve, for participating. This is your fifth year of participating and always a crowd favorite.
Thanks very much. It's great to be here, and thanks very much again for having me.
Steve, I thought I'd kick it off with questions I get from investors. Last year we kicked it off with questions I got about, well, what about, isn't HBM, isn't the Grace back then, Grace Hopper, going to take market share away from DRAM? Dual in line DIM DRAM, and you showed that a server uses a CPU on one side and using DIMs and a GPU on the other side using high bandwidth memory, and it's kind of a parallel universe. Now the questions are coming up. Now that AI inference systems are ramping into volume production, the question is, what happens when we have training systems versus AI inference systems? That seems to be the trend for 2025.
Yeah, that's a great question. Let me kind of take a step back and just sort of the distinction between training and inference. Training is, it's really how you make a model smarter, right? You want this model to be very, very good and an expert. Inference is how you use it to answer questions and ultimately to make money, right? If you think about certainly the largest models that we're all familiar with, things like ChatGPT, Claude, things like that, those are all really trained in large data centers across many different GPUs. That's one of the keys is that you require a lot of GPUs, in part because there's a lot of data and you can't really fit it all on one GPU. It's a parallelizable problem. We can kind of do that training across many of these engines.
It's the showcase hardware, by far the fastest hardware that's out there in terms of the GPUs and the memories. What's interesting is that the data sets are very large, and so not everything fits in HBM. What we see is that HBM is used in conjunction with DDR memory or LPDDR memory on CPUs. You'll see this kind of collection of hardware. I've got a slide in a minute that'll kind of go into the details a little bit more, but that's kind of the distinction on training. On inference, we really want to do inference everywhere. It'd be, we do some of it in the data center today, but you really want to be able to do it on your home PCs, laptops. It'd be great to do more of it on phones and things like that.
When you think about inference, you really are thinking about doing inference everywhere. That may mean I have to pare down my trained models in some way to make them fit on these things. For the kind of memory that is supporting inference really everywhere, you get all kinds of memory. It could be DDR, it could be LPDDR, GDDR, and even in some cases, just doing an on-chip SRAM, although that is much more rare. You get a little bit of everything on the inference side, and training is really where the very heavy-duty kind of work is going on.
Great. Yeah. When you're describing the HBM versus RDIMMs, what are the trade-offs? Is it more HBM you need, then do you have to have a comparable amount of RDIMMs? I guess how do the workloads get split up?
Yeah, so I've got a couple of slides that first I can talk a little bit about the workload, then I'll show you sort of how it ends up mapping onto real hardware. I get asked this question a lot about how does an LLM work? Like ChatGPT, what really happens? When it comes time to do inference, what happens is you type in a question. You might be sitting there at your computer and you might say, hey, are dogs mammals? The first part of how we reach an answer is called the prefill phase. What happens here is that the system takes a look at the individual words or tokens that compose your question, and they start to fill this thing called a KV cache.
The KV cache, it's short for key value cache, but that's going to be used to construct the answer. Really what's going on here is you're trying to figure out the context of what's going on. What is the person asking about? You're trying to think about what words or collections of words might actually be relevant to that answer. This stage tends to be very computational, but it also tends to be short in terms of the execution time. By far, the majority of the time is spent producing the answer, what's called the decode phase. What happens is it's very iterative, and one at a time, this KV cache gets queried, and it produces the first token or the first word in the answer.
Then we iteratively go back and say, well, starting with this word, what's the next best word in my answer? You go back to the KV cache, produce the next word, and so on. Some answers are very, very long. If you've ever played with ChatGPT, you know it can produce paragraphs of information. This process of decoding can take a long time. It turns out 80%-90% of the time is typically spent in the decode phase. This decode phase is very bandwidth intensive. The way to think of it is, if I'm spending most of my execution time in the decode phase, and the decode phase is very bandwidth intensive, then overall, the whole thing is bandwidth intensive. The one thing that is interesting to know is that the key value cache is big.
We would like to put it all on HBM, but we can't. Typically, there are people who will put 20%-30% of the capacity of the HBM for the key value cache, but that only stores a small portion of it. We actually need a lot more memory somewhere to store the rest of it. It becomes this process of pulling the relevant parts from memory that's a little bit further away. In this case, that would be DDR in many cases, or it could be LPDDR. You pull that into the HBM and use it to construct the answer. The way to think about this is there's now two almost tiers of memory. The memory that's close to the GPU, that's very fast, that's the HBM, but you don't have enough capacity.
You need some much larger capacity memory that's as close as possible to the HBM that turns out to be in the CPU. It has to be very high bandwidth because we're constantly moving that data back and forth into the HBM memory for it to be processed. If we take a look at kind of a modern system, this is a system that's sold by Supermicro, and you can see it's a rack full of a bunch of these 4U boxes, and the boxes are shown here. At the top in 2U of that space is where you typically put the HBM engines. Or, sorry, the GPU engines. The GPU engines are really where a lot of the work is done. The bottom 2U is where the CPU is. I think I accidentally have the arrows switched here.
These pipes that are going into the chassis, they are water cooling or liquid cooling. Liquid is actually flowing through here to cool all these components. What you'll notice about here on the GPU side of things is you'll have eight of the high-end NVIDIA GPUs, and they're packed with as much of the state-of-the-art HBM memory as possible. Today, that's HBM3 memory and this one for this particular case, you have an x86 kind of dual socket CPU, and then you can just pack, you can just pack it with memory. In this particular case, we can have up to 8 terabytes of DDR memory. You can see it's 8x the capacity of the HBM memory.
All total, there's about 9 TB of memory that you can get in this box, of which most of it is attached to the CPUs that are a little bit further away. What we'll do is we'll just shuttle data back and forth from the CPU's memory to the GPU's memory and back. Again, you're really trying in the case of LLMs to keep the key value cache, the relevant parts as close to the GPUs as possible. The real trade-off here is just you're trying to get as much of that super fast memory just as close as you possibly can to the GPUs. In practice, the way we're constructing our models and the key value caches just keep getting bigger and bigger. We're going to need this other kind of what's called offload memory next to the CPUs. That's really the place where DDR dominates today.
If I could even expand on other sessions we've had or things, conferences we've talked about, just maybe again for investors to understand that a solid-state drive, when you say this has to be super fast and it has to be as fast as DRAMs, solid-state drives relative to a DRAM, what are the speeds? SSDs don't really play into this.
Yeah, I think that's a great point. Kind of if you can't use DRAM, then your next choice is to use a solid-state drive, but that's going to be, it's going to be three orders of magnitude slower. The bandwidth is much lower as well. You really just can't service these kinds of applications out of an SSD because the performance just takes it completely out of the running for being used.
Yeah, all of this is for the response time for the user that is using the LLM. I use Perplexity and I put it in and if it takes 20 minutes, it doesn't do me any good, right?
That's right. In fact, there's another interesting aspect to it to where as humans, we can only kind of read the information so fast. As long as you can kind of keep up with what we can consume, life is good. The more interesting challenge though is when you have machine-to-machine communication, machine-to-machine kind of learning in the case of digital twins or trying to train robots and things like that, those things can go faster than humans can perceive the answer. In that particular case, you're just trying to go as fast as you possibly can. Again, even with humans, an SSD is not going to be useful, but if it's not useful for humans, it's definitely not going to be useful at the speeds that machines can communicate with each other.
Right. And maybe if I'll just make one other point, as long as you have a nice clear graphic here, that these two CPUs that you have on the right-hand side are each using eight sockets or eight channels for DDR memory. As we go to next generation, like Granite Rapids, what happens to the number of channels there?
Actually here, what's going on is each CPU has actually got 16 DIMM sockets, if you can believe it. I mean, there's a very large number of DIMM sockets. Is it 16 or 12? Maybe one, two, three, four, eight, 16. Each CPU has 16 DIMM sockets, and then each DIMM socket supports two channels. Really, there's 32 channels of DDR5 memory feeding each of these CPU sockets, these black sockets right here.
Oh, okay.
Yeah. The idea here is you're really just space constrained. You're packing just as much as you can get into each CPU. What we're seeing is the demand for memory capacity and bandwidth is so high in the CPUs that they're going to remain space constrained. They're going to fit as many as they possibly can onto that motherboard. You can see there's just no room on the edges here. I mean, that's just fully packed.
What is it that has changed in the DDR5 standard versus DDR4?
Yeah, a couple of things. In DDR5, there's more bandwidth. There's double the bandwidth or higher depending on the speed that you're running at. The capacities are higher as well. The other thing that's really interesting from a module design standpoint is these modules here, which are shown on the right. In DDR5, these modules have kind of a left half and a right half, and those are independent channels. In DDR4, the whole module formed one channel. Channels are great because they're independent resources that you can then provision. You can kind of loan them out to certain cores and things like that. Those resources are independent. They don't get interfered with by other cores that aren't using them.
The other thing that I think is really interesting is as we've gone faster and as we've supported higher capacities, we've needed to have more power that's being supplied to the modules. DDR5 modules now have additional silicon compared to DDR4. There's a power management IC, which delivers very high-quality power. There's other things. There's an SPD hub for management of the DIMM, and there are temperature sensors as well. This is all just reflective of the fact that as the performance demands have gone up for memory, in this case, DDR5, we need more silicon to kind of deliver what's really needed in the system.
You have also announced an MRDIMM. Can you say what the difference is as you go from a DDR5 RDIMM to an MRDIMM?
Yeah. Along that same theme of needing more capacity and more bandwidth, the industry introduced a new standard called the MRDIMM. Here I've got a picture of it. On the right is your standard, what we call a registered DIMM. Now, what we have here, there are some interesting chips on it. I mentioned that there's a power management IC and an SPD hub and temperature sensors. Really, one of the most important chips, I think, is this registered clock driver. What it does is it takes commands from the CPU and it fans them out to the DRAMs that are on the module. If you take a look at an MRDIMM, it's got many of the same kind of structures. There's an RCD in the middle here. There is an SPD hub and a power management IC and some temperature sensors.
The new addition are these 10 what are called data buffers or MDBs. Basically, they're MRDIMM DBs. What they do that's really clever is normally in a registered DIMM, one DRAM will be transmitting across the data wires back to the host. What happens in MRDIMM is two different DRAMs are transmitting across the same data wires, and they're being combined and multiplexed into one data stream that's twice the data rate of any of the individual DRAMs. What we do here is we really are increasing the number of transactions that we're servicing at one time, but we're multiplexing the data back on the same data wires. From the host standpoint, it looks like, wow, now I've got twice the bandwidth going in and out of this module.
From the DRAM maker standpoint, it's great because they've actually made no changes to the DRAM. It's the same DDR5 DRAMs. Making a new DRAM is a long pole in the tent. If you can leverage the same DRAM that's out there and you can find a way to provide more bandwidth on the module back to the host, it's a win. That's exactly what MRDIMM does. Rambus is actually the first company to produce an MRDIMM chipset. We introduced it last October. We also introduced a new PMIC because you're going to be consuming more power as you transmit more data. We're very happy about that. Based on the current platform schedules that we've seen, we're anticipating that it'll launch in 2026, and the volumes will ramp after that into 2027. The data rates we're going to see are going to be very high, much higher than an RDIMM can reach. It is going to start at 12.8 GB per second transfers. Very, very high data rates.
Right. I guess, again, a limiting factor on this is a CPU that has to be able to use this MRDIMM.
That's correct. Yeah. It's got to be something that can absorb the very high data rates that are there. What we've seen is the bandwidth demand has been going through the roof. What's great about this is the bandwidth demand has been growing faster than the industry is used to producing new kind of DDR DRAMs. In this particular case, the MRDIMM architecture is a great way to kind of continue to leverage the infrastructure that's there to provide more of what the hosts need.
Right. And maybe even to, like you showed in that CPU picture, there are 32 different channels. Would every channel have to switch to MRDIMM, or would it be a mix and match? Or how would that configuration happen?
Yeah. I mean, really in practice, you're going to do all the DIMM sockets are going to be MRDIMM. I mean, technically, it's theoretically possible to do. Once you start needing a lot of bandwidth, you're going to switch all the sockets over on your platform because there is really, it becomes a management difficulty from the host side. Some of the channels do one thing, some do another. Just what we've seen in the past for this type of thing is people will tend to move all the sockets over from one technology or the other.
Even when we're talking about DDR5, I remember when it first came out, there was going to be six or is it eight different iterations, speed upgrades. Where are we now in that upgrade cycle? What would MRDIMMs be? What generation of DDR5?
Yeah, yeah. The industry has defined kind of the speed roadmap and they have defined all the timing bins according to the kind of initial definition of the part. What always happens is the industry starts to say, could I just squeeze one more, two more generations out? That is just always how it is. People become smarter and they become more experienced dealing with the technology. In practice, there is usually one or sometimes two extra speed grades. What starts to happen also is you realize, okay, I am working so hard to get just the next little bit of performance gain. They start to fall back and say, with MRDIMM, I can actually use a slightly slower speed bin for the particular DRAMs.
Since I'm multiplexing two of them, the end result is I get to a data rate that's much higher than I could ever get to with the high end of one DRAM. Right now, the industry is kind of, it's working through the speed roadmaps and things are defined. The platforms are adopting them and all that. What MRDIMM really does is it gets you to a place that you just can't get to with an individual DDR DRAM.
Okay. Again, training and inference would be used in both.
Yeah. Really, inference is a part of the training process. That is really why on the largest kinds of systems, you can kind of use that hardware either for inference or for training. We anticipate that, yeah, it would be used in both kinds of systems. The demand for bandwidth and capacity, like I have mentioned on these KV caches, it is phenomenal how much memory they want. I mean, you really cannot give them what they would ideally like. You are trying to just do the best you can to give them just as much as you possibly can.
Maybe I'll take a question from the audience that goes along with what we were just talking about with your different generations of DDR5. The question is, when is DDR6 due out? Is that in the pipeline?
Yeah, yeah. What typically happens is once a memory launches, usually there are some months, it could be six months, could be a year, where a lot of effort is spent enabling the technology and then really thinking about how to get to the data rates at the end of the architectural life of the memory. When DDR5 launched, people were looking at, well, can we extend it one speed grade or two? Usually about a year after that or a year and a half after that, the industry starts to think about what's next. There are discussions going on now about what would the next thing really be. It is all part of the normal progression of things. The discussions are all very early right now. Usually, people just, through standards organizations like JEDEC, people just think about, well, what are the challenges and what are some interesting ideas for how to kind of get through them?
Your long-term licensing agreements with the DRAM manufacturers, you'll be right in there with the IP for DDR6.
Yeah. I mean, our licenses, as you know, are signed for certain durations of time. And so, yeah, depending on when DDR6 comes out, and it may or may not be depending on the timing. It is really just based on when DDR6 gets fully defined and then when it starts to come to market. Right now, I think there is no set date, but we all have watched the memory industry over the years, and we know that DDR generations, they typically last five to seven years before the next one comes out. It is hard to say exactly when DDR6 would come out, but if you just kind of follow the history of it all, then if it follows that same history, then it will be five to seven years after DDR5.
Okay. Great. Yep. One other standard that's out there is CXL. You're saying that solid-state drives aren't anywhere near fast enough, but CXL is a little bit slower, but it's still DRAM. It just seems to have been a little slow, maybe in committee, and you're getting a lot of people still adding to the standard of CXL. Maybe if you could give us an update of where we are with CXL.
Yeah, absolutely. I think what's important is that we participate in the CXL market because we have our silicon IP core that is a CXL controller. What's interesting is we're involved in the ecosystem, and we get a lot of insight based on the customers that purchase our IP core. We understand a little bit more about what they're trying to do. I think the industry had hoped early on that there would be kind of a convergence on maybe one or two use cases that would really start to drive wide adoption. What we're seeing is that there's still a lot of experimenting going on and a lot of kind of individual use cases that are, I guess, in some ways fragmenting the market. The anticipated adoption, broad adoption is kind of pushed out a little bit.
I think it's kind of normal because there's just learning that you need to do to figure out how do you use this other tier of memory. I think also AI has been a big, has taken a lot of mind share in the industry and a lot of dollars. There has been a lot of effort to focus on that as well. What we've seen is that there's largely people that are doing kind of this expansion with CXL. It's kind of these very tailored use cases with tailored silicon right now. We think, and certainly the people we talk to, that when CXL 2.0 really gets fully enabled and the 2.x generation kind of really gets out there, we'll see, we think more adoption.
When I think what a lot of people are saying is the 3.x version has a lot of really interesting features that can then drive further adoption. I think it's really kind of based on the enabling of the standard that we think is going to drive kind of more adoption. Some of these use cases like pooling and things like that, that was always intended to be a bit later. Expansion, we think, will be first, and we think it'll depend a lot on kind of the individual spec adoptions, kind of how much the market uptake is based on the hardware being compliant to the 2.0 and 3.0 specs. We're still advocates of the serial attach for memory. We think it solves a lot of really interesting problems, and it's partly why we're still in it in the silicon IP business. We're really monitoring a lot of what's going on. We're getting a lot of insight from that business, and then that'll inform us on what we may or may want to do for on the silicon side.
Okay. Another question I get from investors in January, and we'll just touch on this because tomorrow we have our panel discussion at 1:00 P.M. to go into more details about inference and efficient models like DeepSeek. In January, when DeepSeek came out, a lot of investors got very nervous about the whole AI cycle and how much memory you need, that if you have these more efficient models. Maybe just an idea of what do you think is happening with DeepSeek, and does it change anything in the market?
Yeah. I mean, when I saw DeepSeek come out, I at the time, and I still believe this, I thought it was great for our industry. I think in so many ways, what we do in semiconductors, we've been driven by Moore's Law. How do you do more with the dollars that you're spending? How do I make transistors cheaper? How do I make silicon more capable and less expensive? Through the decades, what that's done with cheaper, more capable silicon is it's grown the adoption. Silicon's everywhere now. It's in cars and appliances, toys, things like that, right? What we've repeatedly seen is that when you can make hardware more efficient, you can make it more capable, and you can make it more performant. That just drives the adoption of more hardware, and it drives better applications and a broader range of applications.
A couple of examples. When we first saw, for example, multi-core CPUs, there was this belief that, oh, gosh, if a CPU now has two cores, I'm going to sell half as many, right? What really happened is it made computing cheaper. Now everybody wants to do more things through software. There is more availability of the hardware. Once standards got in place and support for the multi-core CPUs happened, all of a sudden you had cloud computing and more and more cores. It has consistently driven kind of cheaper silicon and more cost-effective solutions. When I look at DeepSeek, really what they did was they figured out how to take the hardware that they had and improve the application performance. The techniques are very clever. They are very applicable to lots of different kinds of AI that we want to do now and in the future.
One of the things is they dedicated a lot of the cores and the hardware to communication between the engines. What they realized was that communication and data movement were big problems because there was so much data that they needed to move. What they've now done is they've shown the industry that, hey, with this hardware we've got, you do not necessarily have to wait for the next-gen hardware. You can start doing some of your next-gen application development on today's hardware. The next-gen hardware, you can start doing two generations out of software that you were planning to wait on doing. This is going to accelerate things. I'm really confident that this is a great breakthrough for our industry, and it's going to continue to drive wider adoption, and it's going to accelerate the kinds of applications that we're all looking forward to in the future. I think it was a great thing for our industry.
Yeah. Good. Good perspective. Thanks. Maybe we were talking about what these new applications are. We've heard the terms now of AI agents and agentic AI. How does that play into the memory subsystems too? Maybe a quick description of what those are.
Yeah, yeah. I kind of mentioned just now that DeepSeek does help accelerate things, right? What's really interesting is it's accelerating the move towards agentic AI and really better reasoning, right? The consequence of all of this is if I can compute faster or I can arrive at my solution earlier, then I need more memory bandwidth and more memory capacity because I'm going to need to feed the engines with more data. That's one consequence of what DeepSeek's done is it's going to drive the demand for better memory. If you look at these new models like agentic AI, it's doing the same thing. Agentic AI, really, it's this ability to have AI that is more autonomous and can kind of make decisions and change its goals over time.
The way to think about it is in generative AI, like these large language models, I type a question in, and the goal is to answer my question, right? That's the whole goal. It's trained to do that. With agentic AI, the goal may be more nebulous or more complex. For example, it could be, let me know anytime a dog walks by the front of my house and turn on my sprinklers when you see that happen, right? Don't turn on the sprinklers too much that you overrun my water bill because I don't want to pay some penalty for too much water. In that particular case, you've got a goal. The goal's complicated, right? You have to be able to do something. Oops, sorry, it just went out of my brain here. Yeah. The goal is more complicated.
You need to have planning, and you need to have replanning as you get new information. That is what is different about agentic AI. You are going to have a lot of different things going on at the same time, and you are going to be fusing a lot of information together. Many of the same things we see in generative AI. In fact, agentic AI will use generative AI, but it will have other things going on on top of that. The end result is, from a memory standpoint, you are going to need more capacity, more bandwidth because you are moving lots more data, and you are trying to make a lot of decisions in a short amount of time.
You know, when you talked about more bandwidth earlier today, we had NVIDIA Networking VPN, and the question came up from a lot of people of how long does copper last, and when do we switch over to optics? I would say the same is going to be true for the copper wire, the lines going from the memory to the CPU, and even within the HBM memory to the GPU. What's your view on copper versus going to co-op?
Yeah. So with optics, the idea is to provide a wider pipe to move your data. What we've seen is that it's really a distance game. Initially, when you were moving data between data centers that were geographically very far from each other, really the only game in town is optics. We're starting to see that distance shrink, right? Within data centers, there's optics in the top of rack switches and things like that. At some data rate, it's inevitable that you've got to be using optics inside the server for more communication. The thing that is also true is that optics will eventually get converted back to electrons that will move over copper wires. Maybe the copper wires are short, but there's going to be some conversion back to the copper world.
That is really what most electronic components operate in today. Kind of the next thing that will likely happen is that once optics starts to be kind of the conduit for moving data inside a server, there is still going to be this conversion back to electronics. The interesting part of it is because optics has incredibly high bandwidth, you only want to put it there if you feel like you can feed it. It is going to be up to the memory industry to come up with even more capacity and even more bandwidth to keep these pipes full. You do not build a freeway just to let it have one or two cars every hour. You build a freeway because you are planning to fill the thing. The call to action for our industry is, hey, the pipes are getting big now. Figure out how you're going to continue down this bandwidth and capacity roadmap to keep those things full.
Yeah. Great. You know, we only have about five minutes left, but I'd like to jump topics over to when looking at these companion chips that are on the modules. You know, in particular, and it comes up a lot with investors, is the PMIC, the power management IC. Yeah, lots of companies that make PMICs. The question comes up, why is Rambus bothering getting into the PMIC market?
Oh, that's a great question.
For you to bring in. Yeah.
Yeah, great question. Again, if you look at these modules that I've got up here, you'll notice that the DRAMs are not made by us. They're made by the DRAM manufacturers. Again, there's a lot more silicon that's on the module these days. It turns out we've been doing the RCD, and we do have past experience on these kinds of data buffers. This other silicon, it makes a lot of sense to do because, for one thing, our chips are dependent on the power that's being supplied. Having a companion chip that's part of the full module chipset that does power makes complete sense to us.
Now, the reason why I think we're in kind of an interesting position and why we're in a good position to do this kind of thing, one is we have a lot of experienced talent on our staff that knows how to do PMICs and things like that. We've got other people that are working on temperature sensors and SPD hubs, things like that. The really, really hard part about a lot of this is making them all work together in this incredibly space-constrained environment where you have to kind of get all these components to operate together. You're under very difficult cooling constraints. There are a lot of other components close by that could potentially interfere with electromagnetic interference or just routing difficulties and things like that. The physical constraints of operating on a DIMM are extremely difficult.
We have 30 years of experience of operating in this environment. That is really the experience we bring, the value add is the ability to make all of these components work together in the chipset so the customer has confidence that when they buy our components, they will work together. We understand the environment that these are going into. We understand the cooling and the sockets and the reliability requirements to make sure that these things will work well in a finished product.
It just kind of adds on to your IP where you do a lot of interfaces to the memory. You understand that memory signal and how much noise that creates, and power management is very sensitive to that. Is that?
Absolutely. I mean, the important thing here about why the PMIC has been brought onto the module is as you go faster and faster and as you have more components, you need higher quality power. The place where the power is coming from is the PMIC. It's right next to all of these components. It's called being near the point of load. One way to think about it is if I was supplying the power from very far away, one thing is I'd lose some of the power because it would dissipate in the wires because it has to travel so far. It could be subject to noise from other electrical components. That quality would degrade.
What we're seeing is that for the data rates we need to get to and for the efficiencies that the data centers are calling for, there are multiple reasons why that PMIC needs to be on the module. Our experience with working on that module and, of course, needing the power from these components, it's really an ideal kind of additional chip to put into our chipset.
Great. It's nice to have one more piece of silicon to sell to your customers too.
Absolutely. Yeah. That complete chipset, it's a good thing.
We got about a minute. I'll give it one more poll if anyone from the audience wants to ask a question last minute. Otherwise, I'll thank Steve once again for a great presentation. We'll talk to you tomorrow.
Thanks very much.
I did get the one question here.
Oh, okay.
Here it is.
All right.
There are other components that might move to the RDIMM, similar to the PMIC. Are there any others? What would Rambus expand into this? Are there going to be more components coming onto the RDIMM? It'd offload the motherboard as well, I think of it.
Yeah. It's a great question. I think there's always these discussions about, would it be possible to move something onto a DIMM? There's nothing to announce right now, but we continue to participate in those kinds of discussions. On the research side of our business, we do look at that kind of thing where I'm from Rambus Labs, where we do a lot of our innovation. Architecturally, we do look at that kind of thing. There are possibilities, but the industry hasn't really announced anything yet.
Okay. Great. Again, thank you, Steve.
Oh, you're welcome. Thanks for having me.