loading
loading
At Hot Chips 2026, Intel finally detailed the architecture of their upcoming server CPU code named Diamond Rapids. SemiAccurate has been waiting for this chip for years, and it is getting close, just over a year to go now. So what did we know about Diamond Rapids (DMR) before the full disclosure? As we exclusively brought you in 2019, along with the name, was the platform called Mountain Stream and a release date of 2H/2023. We were asked not to divulge more details about this 80 core beast with 20 DDR5 channels for the big socket, mounted on the daughter card, and eight channels for the small socket. There was lots more we sat on for a little more than seven years. Given that a server CPU takes about 3 years to develop start to finish, you might think something went a little wrong. You would be correct there, things went bump in the night several times for this project, and the only thing that the current iteration of Diamond Rapids has in common with the version SemiAccurate was told about in 2019 is the name “Intel” on the slides we saw. Everything else has changed, likely multiple times, but SemiAccurate is only aware of the first and last variants. So with that preamble out of the way, lets look at DMR as it stands now, and it is pretty impressive. This new version is a 256 core beast with more dies than you probably realize, multiple interconnect schemes, and a host of other interesting construction methods. It may not be as complex as Ponte Veccio but it is still astoundingly complex. The advanced packaging folk at Intel’s Malaysia campus will have those new buildings full before you know it. Lets take a look at the new Diamond starting with the layout. Diamond Rapids looks like 5 tiles If you look at DMR with the naked eye, it looks like an AMD Epyc CPU, the upcoming Venice to be specific, with two IO dies, Intel calls these Fabric Hubs, and four CBBs or Compute Building Blocks. A closer look reveals they are anything but simple, those CBBs are actually five dies each, times four CBBs, and the interconnects are not just simple UCIe links. All 22 DMR tiles in full plumage To save you some counting, there are 22 dies in the biggest version of DMR, Intel hasn’t specified how lower core count variants are going to be laid out. And for the record, the DMR-8, that is the 8x DDR5 channel variant, was canceled late last year. If you look at the DMR-16, you can see how that device was going to be done. It also tells you how AMD is going to do the small socket Venice and likely the next Threadripper, but that is out of the scope of this article. One thing to pay attention to here is the packaging bits of the diagram above. Each CBB is comprised of five dies, four Core Chiplets (CC) and a Base Tile (BT), each made on distinct processes. The processes are different for each type of chiplet far a reason, Intel 3 for the Fabric Hub (FH), 3-T for the Base Tile, and 18A-P for the Core Chiplets. This tells you a lot about what each piece does, and do recall that Intel 4 and 3 are newspeak for the old 7nm and 7+ respectively with the 18xx line being the renamed Intel 5nm class devices. This is important for several reasons, the foremost is capacity, something Intel is really short of now. Whether or not this is still the case in late 2027 when DMR is set to hit the market officially, early 2028 now according to SemiAccurate’s sources, it is still an open question. That said, like AMD’s Epyc Line starting with Rome in 2018, the entirety of the chip does not need to be made on the current bleeding edge node, the overwhelming majority can be made on a -1 node, in this case Intel 3/3T. For those who are curious, 3T is just 3 with a PDK that supports TSVs. More on this when we look at the BTs in more detail. OK, if you want more on the BTs now, we are here to serve. The BTs each have four CCs on them, so four BTs times four CCs is 16 CCs per device, 16 cores per CC means 256 cores so at least the math works out. The bonding between the two dies is Hybrid Bonding which Intel calls Foveros 3D Direct. What this means is you set up the pads on each die with a surface treatment that allows the two sides to bond when they come into contact. There is a lot more to this bonding than we are describing including materials choices, size, and more, but we will just leave it there for now. More interesting is the UCIe-S connections. UCIe is a well known die to die connection standard, the -S is for Substrate but there are varieties for organic packaging, interposers, and more plus a lot of sub-standards. That is a joke that will live on, eh? The point of using UCIe-S is kind of fundamental to the philosophy of DMR and it is at a weak point of the AMD Epyc architecture… until Venice… maybe. Intel architected DMR at a high level to have consistent memory latency between any CC and any memory location. This means the FHTs have to be connected to each BT directly, no hops between the two FHTs needed here. This made for a rather unique problem with the BT to FHT connections. UCIe-S is cheaper but slower and less efficient that an interposer or EMIB link. So why use -S instead of EMIB or similar technologies? EMIB et al need a lot of beachfront area which is in high demand and obviously physically limited. Worse yet the dies have to be very close, a small number of mm from the furthest pad on each die to the next. Going from one of the BTs in proximity to FHT 0 to FHT 1 is more than those few mm so you would need a hop between the two. This breaks the consistent memory latency paradigm so that connector was right out. Doing things on the surface of the substrate also meant you had to route around the near FHT so again, non-starter. Go deep my son or daughter, and by deep we mean down to lower substrate layers. Instead of going around the near FHT, you can go under it and pop up under the far one. Problem solved, let the interns deal with the routing headaches. So UCIe-S allows Intel to have a reasonably efficient, standards based die to die interface and still have consistent memory latency from any die to any memory location. This is actually quite impressive, lets see what AMD does with Venice, it also has two IODs. Back to the BT, remember that 3-T process? Those TSVs allow the CCs to pass data and power through the BTs directly if needed so the stacking in DMR is something between 2.5D and 3D but it should work really well. On the down side you might notice that the four CCs almost totally cover the BTs, the word almost being the issue. If you have a nearly covered tile, it makes it had to mate that with a heat spreader. Worse yet any clamping load is spread non-uniformly which is a problem for bumps that are measured in microns. The last time Intel had an issue like this was during the dual-die P4 era with the hybrid 45/32nm CPUs. You remember those, Havendale et al, the ones that never came out because the dies were different heights and hilarity ensued when they tried to work around the issue. SemiAccurate thinks the engineering has progressed to the point where this won’t be an issue, but the diagrams Intel supplied at Hot Chips make it worth asking the question. Intel 18A vs 18A-P Last up we have the 18A-P process which is distinctly different from the 18A process. For all the uninformed clickbait consumers out there who just ‘know’ the Intel 18A process has miserable yields, underperforms, or is sinking the foundry efforts, let us point and laugh at you. 18A-P is the new variant of the completely whelming and performant 18A process. It is also the first process that can support non-Intel customers, IE foundry customers. Anyone who looks at foundry and says that it has/is/will fail because there are no customers making chips RIGHT NOW is ignorant of the facts, 18A-P is the gating point and it hasn’t arrived yet. Ranting done, if you look at 18A-P vs 18A, you can see a lot of substantial gains, in line with what Intel promised years ago when 18A was announced. Gains of between 10-20% over 18A seem very achievable and better yet the libraries and IP will be there to support a much wider variation of device types, both Intel and otherwise. Circling back to the tiles data from before, you can see that the minority of die area in DMR is on 18A-P so the new process is unlikely to be a bottleneck even as wafer starts ramp. Compute Building Block details That covers the construction of Diamond Rapids, what are the details of each type of tile, Fabric Hub, Core Chiplet, and Base Tile? Well since you asked, lets take a look at each starting with the 16 CCs that the full sized DMR wields. Each CC has 16 cores, the L2$ that they share, and a 3D crossbar that connects to something somehow. That is about what Intel disclosed about the CCs, other than you can vary the number of them per BT and fuse off cores as well. Questions remain, things like the size of the L2$ for one, but that pales in importance against the crossbar. Intel was very forward about the importance of consistent memory latency on DMR, and for good reason. Each Compute Building Block (CBB), the name for the BT and CC assembly, directly connects to each FHT so in theory, and quite likely, each CC is a single hop away from any other CC. That is a good thing but how the crossbar is laid out will determine if it is just a good thing or a really impressive architecture. I guess we will have to wait for the full architecture disclosure for that. That brings us to the BT itself, and the first surprise is that it isn’t passive like most other interposers. As you know an active tile generates heat, and stacked heat sources can be problematic for performance and device longevity. The BT has a chunk of the 1.28GB system LLC/L3$, and math tells us that it is 320MB for each of the four tiles, quite a decent chunk there. The tile also has the caching agent logic and a snoop filter, plus the obvious die to die SERDES and logic. It may be active but it doesn’t all that much, at least not enough to generate tons of heat. As we stated above, the real question about the CBBs are mechanical. Will Intel put a silicon slug above the ‘blank’ area not covered by a CC? If not, how will they manage the mechanical pressure of the heat spreader and how will they contact it? How will they manage the heat? These are not trivial questions, similar issue have sunk past Intel projects as mentioned above, but much learning has been had since then, some the hard way. Two colors for the Scalable Fabric Hub That brings us to the last type of chiplet, the Fabric Hub, which in many ways is the heart of the system. Intel divides these into two logical sections based solely on the color of the transistors used, blue or brownish. That is a joke, the divisions are based roughly on whether a block is memory or fabric related, or you could envision it as internal or external facing. Flexbus I/O Fabric detail The blue, err Flexbus I/O Fabric is the external bit and it does roughly what you expect, what Xeons in the past have had updated a bit to modern standards. The new platform updates PCIe5 to PCIe6, CXL 2.x to 3, and UPI3 is now there too. The PHYs are connected to the Flexible I/O Subsystem which means each lane can be PCIe, CXL, or UPI. Xeons of the past have used PCIe physical layers for just about everything, and DMR does the same just faster. How flexible and what combinations are the key here, and that wasn’t disclosed. On paper it looks like you can have up to 128 PCIe6 lanes per socket but that means no second socket so all is not exactly rosy but tradeoffs rarely are. The I/O Caching and Filtering block is far more important than it looks, especially if you care about high speed I/O with real throughput. This is the modern iteration of DDIO which SemiAccurate first wrote about for Romley 14ish years ago. If you think about how fast a 100GbE link can fill a cache while waiting for a memory transaction, you get why DDIO is a necessity. Now think 800GbE and off you go. Snoop filtering and caching agents for coherency are also necessities in this modern era, but they are much more widely understood and expected. Last comes the accelerators, something that is either absolutely necessary for your workload or irrelevant to it, very little lives between. The accelerators were used for evil in the past by the dark SKUing gods, it is an open question how different SKUs will be offered this time around. Given that Intel is way behind AMD and currently lacks the power to abusively wield monopoly power, we will go out on a limb and say those days are behind us. In any case the accelerators are a good thing if you need them. Overall there are no surprises on the Flexbus I/O Fabric, at least at the current level of disclosure it just looks like a bit more, a bit updated, and better everywhere. Unified Memory Fabric Detail Now we come to the brownish transistors also known as the Unified Memory Fabric which is roughly what it sounds like. The UMF obviously supports the memory controller itself with all the goodies that Intel supports for Xeon, mostly some pretty advanced RAS features but also support for MRDIMMs and the like. The Memory Value Function basically lets the CPU support external memory via CXL with either one partition or a mirrored set of partitions, something that was probably requested much more before the current memory pricing silliness. Memory Encryption Engine is just what it sounds like, pretty mandatory for current server products. The Home Agent and Home Snoop Filter are again what they seem, coherency across the system. If you look at how the Diamond Rapids CPU is laid out with 16 separate CCs, four BTs, and 2 FHTs, you can see that there is more than the usual amount of juggling needed to keep track of memory. Coherency is a pain to do right and worse to validate, this block may be small but without it, memory doesn’t work like most users hope it will. In technical terms, that would be a ‘bad’ thing. If you look at the whole system, it is laid out fairly logically. Each FHT has six blocks labeled Die 2 Die which do what they say. Four of these connect to the four BT/CBBs directly and two go to the other FHT. Assuming the diagrams intel provided are close to reality, the layout of the FHTs makes sense with the D2Ds as close to each other as possible. Connections to a second socket are done through the UPI ports on the Flexible I/O Subsystem and routed separately while memory goes out the sides like it always does. Intel calls this whole paradigm Fan-out Fabric Architecture which makes sense if you look at it. After 8-10 years, depending on when DMR is actually released and how you count, Intel is finally catching up with the paradigm AMD launched with Rome. Take a central core that is cheap to make and add many expensive but small and high yielding chiplets around the edges. It just makes sense. For the moment Intel has even leaped ahead of AMD with the architecture, the dual FHTs give them flexibility and the UCIe-S interconnects give them memory latency that would be tough to do without direct connections between the components. AMD’s Venice was shown off a few weeks ago and it too has two IODs but how they are connected will make all the difference as to which architecture is better. That question won’t be answered for a few months though, stay tuned. Intel listed a lot of details around DMR and the feature set which at the high level of their Hot Chips talk seemed to be the same as current devices with a speed bump here and there. Without details we won’t go over each bit individually but we will give Intel credit for a complete set of RAS and accelerator features this time around. That brings us to the elephant in the room, threading. You may have noticed that Intel was a bit shy with details about core counts, L2$, and other things on the CC itself. The core count for the full device is 256, that has been known for a long time, and AMD’s Venice is also at 256 so Intel is in the game, right? Venice has two threads per core or 512 threads per die, DMR has one thread per core or 256 threads per die. Oops. While we may write up the reason this mismatch occurred someday, it is out of the scope of this story. Just realize it wasn’t intentional, Intel tried to make 2T cores but failed. AMD is quick to credit threading for a roughly 15% performance boost so taken at face value, Intel is behind on paper. Given what we have heard about the Lion Cove cores themselves, they are unlikely to match AMD’s Zen6 cores either. When you add it all up, Diamond Rapids is a credible part that narrows the gap to AMD’s Epyc line but doesn’t close it. As SemiAccurate has been saying since 2018, Intel has no chance in servers until AFTER Diamond Rapids. We weren’t joking but at least things are starting to look competitive again.S|A Charlie Demerjian Latest posts by Charlie Demerjian (see all) - What Is Intel’s Diamond Rapids Server CPU? - Sep 11, 2026 - ARM’s 2026 ‘Tech’ Day Is A Self-Inflicted Wound - Sep 7, 2026 - Intel Bumps Xeon Memory Speeds - Jul 20, 2026 - Qualcomm’s 2026 Investor Day Has Hidden Goodies - Jul 15, 2026 - Phison Phudges The Numbers… In A Good Way - Jun 24, 2026
At Hot Chips 2026, Intel finally detailed the architecture of their upcoming server CPU code named Diamond Rapids. SemiAccurate has been waiting for this chip for years, and it is getting close, just over a year to go now. So what did we know about Diamond Rapids (DMR) before the full disclosure? As we exclusively brought you in 2019, along with the name, was the platform called Mountain Stream and a release date of 2H/2023. We were asked not to divulge more details about this 80 core beast with 20 DDR5 channels for the big socket, mounted on the daughter card, and eight channels for the small socket. There was lots more we sat on for a little more than seven years. Given that a server CPU takes about 3 years to develop start to finish, you might think something went a little wrong. You would be correct there, things went bump in the night several times for this project, and the only thing that the current iteration of Diamond Rapids has in common with the version SemiAccurate was told about in 2019 is the name “Intel” on the slides we saw. Everything else has changed, likely multiple times, but SemiAccurate is only aware of the first and last variants. So with that preamble out of the way, lets look at DMR as it stands now, and it is pretty impressive. This new version is a 256 core beast with more dies than you probably realize, multiple interconnect schemes, and a host of other interesting construction methods. It may not be as complex as Ponte Veccio but it is still astoundingly complex. The advanced packaging folk at Intel’s Malaysia campus will have those new buildings full before you know it. Lets take a look at the new Diamond starting with the layout. Diamond Rapids looks like 5 tiles If you look at DMR with the naked eye, it looks like an AMD Epyc CPU, the upcoming Venice to be specific, with two IO dies, Intel calls these Fabric Hubs, and four CBBs or Compute Building Blocks. A closer look reveals they are anything but simple, those CBBs are actually five dies each, times four CBBs, and the interconnects are not just simple UCIe links. All 22 DMR tiles in full plumage To save you some counting, there are 22 dies in the biggest version of DMR, Intel hasn’t specified how lower core count variants are going to be laid out. And for the record, the DMR-8, that is the 8x DDR5 channel variant, was canceled late last year. If you look at the DMR-16, you can see how that device was going to be done. It also tells you how AMD is going to do the small socket Venice and likely the next Threadripper, but that is out of the scope of this article. One thing to pay attention to here is the packaging bits of the diagram above. Each CBB is comprised of five dies, four Core Chiplets (CC) and a Base Tile (BT), each made on distinct processes. The processes are different for each type of chiplet far a reason, Intel 3 for the Fabric Hub (FH), 3-T for the Base Tile, and 18A-P for the Core Chiplets. This tells you a lot about what each piece does, and do recall that Intel 4 and 3 are newspeak for the old 7nm and 7+ respectively with the 18xx line being the renamed Intel 5nm class devices. This is important for several reasons, the foremost is capacity, something Intel is really short of now. Whether or not this is still the case in late 2027 when DMR is set to hit the market officially, early 2028 now according to SemiAccurate’s sources, it is still an open question. That said, like AMD’s Epyc Line starting with Rome in 2018, the entirety of the chip does not need to be made on the current bleeding edge node, the overwhelming majority can be made on a -1 node, in this case Intel 3/3T. For those who are curious, 3T is just 3 with a PDK that supports TSVs. More on this when we look at the BTs in more detail. OK, if you want more on the BTs now, we are here to serve. The BTs each have four CCs on them, so four BTs times four CCs is 16 CCs per device, 16 cores per CC means 256 cores so at least the math works out. The bonding between the two dies is Hybrid Bonding which Intel calls Foveros 3D Direct. What this means is you set up the pads on each die with a surface treatment that allows the two sides to bond when they come into contact. There is a lot more to this bonding than we are describing including materials choices, size, and more, but we will just leave it there for now. More interesting is the UCIe-S connections. UCIe is a well known die to die connection standard, the -S is for Substrate but there are varieties for organic packaging, interposers, and more plus a lot of sub-standards. That is a joke that will live on, eh? The point of using UCIe-S is kind of fundamental to the philosophy of DMR and it is at a weak point of the AMD Epyc architecture… until Venice… maybe. Intel architected DMR at a high level to have consistent memory latency between any CC and any memory location. This means the FHTs have to be connected to each BT directly, no hops between the two FHTs needed here. This made for a rather unique problem with the BT to FHT connections. UCIe-S is cheaper but slower and less efficient that an interposer or EMIB link. So why use -S instead of EMIB or similar technologies? EMIB et al need a lot of beachfront area which is in high demand and obviously physically limited. Worse yet the dies have to be very close, a small number of mm from the furthest pad on each die to the next. Going from one of the BTs in proximity to FHT 0 to FHT 1 is more than those few mm so you would need a hop between the two. This breaks the consistent memory latency paradigm so that connector was right out. Doing things on the surface of the substrate also meant you had to route around the near FHT so again, non-starter. Go deep my son or daughter, and by deep we mean down to lower substrate layers. Instead of going around the near FHT, you can go under it and pop up under the far one. Problem solved, let the interns deal with the routing headaches. So UCIe-S allows Intel to have a reasonably efficient, standards based die to die interface and still have consistent memory latency from any die to any memory location. This is actually quite impressive, lets see what AMD does with Venice, it also has two IODs. Back to the BT, remember that 3-T process? Those TSVs allow the CCs to pass data and power through the BTs directly if needed so the stacking in DMR is something between 2.5D and 3D but it should work really well. On the down side you might notice that the four CCs almost totally cover the BTs, the word almost being the issue. If you have a nearly covered tile, it makes it had to mate that with a heat spreader. Worse yet any clamping load is spread non-uniformly which is a problem for bumps that are measured in microns. The last time Intel had an issue like this was during the dual-die P4 era with the hybrid 45/32nm CPUs. You remember those, Havendale et al, the ones that never came out because the dies were different heights and hilarity ensued when they tried to work around the issue. SemiAccurate thinks the engineering has progressed to the point where this won’t be an issue, but the diagrams Intel supplied at Hot Chips make it worth asking the question. Intel 18A vs 18A-P Last up we have the 18A-P process which is distinctly different from the 18A process. For all the uninformed clickbait consumers out there who just ‘know’ the Intel 18A process has miserable yields, underperforms, or is sinking the foundry efforts, let us point and laugh at you. 18A-P is the new variant of the completely whelming and performant 18A process. It is also the first process that can support non-Intel customers, IE foundry customers. Anyone who looks at foundry and says that it has/is/will fail because there are no customers making chips RIGHT NOW is ignorant of the facts, 18A-P is the gating point and it hasn’t arrived yet. Ranting done, if you look at 18A-P vs 18A, you can see a lot of substantial gains, in line with what Intel promised years ago when 18A was announced. Gains of between 10-20% over 18A seem very achievable and better yet the libraries and IP will be there to support a much wider variation of device types, both Intel and otherwise. Circling back to the tiles data from before, you can see that the minority of die area in DMR is on 18A-P so the new process is unlikely to be a bottleneck even as wafer starts ramp. Compute Building Block details That covers the construction of Diamond Rapids, what are the details of each type of tile, Fabric Hub, Core Chiplet, and Base Tile? Well since you asked, lets take a look at each starting with the 16 CCs that the full sized DMR wields. Each CC has 16 cores, the L2$ that they share, and a 3D crossbar that connects to something somehow. That is about what Intel disclosed about the CCs, other than you can vary the number of them per BT and fuse off cores as well. Questions remain, things like the size of the L2$ for one, but that pales in importance against the crossbar. Intel was very forward about the importance of consistent memory latency on DMR, and for good reason. Each Compute Building Block (CBB), the name for the BT and CC assembly, directly connects to each FHT so in theory, and quite likely, each CC is a single hop away from any other CC. That is a good thing but how the crossbar is laid out will determine if it is just a good thing or a really impressive architecture. I guess we will have to wait for the full architecture disclosure for that. That brings us to the BT itself, and the first surprise is that it isn’t passive like most other interposers. As you know an active tile generates heat, and stacked heat sources can be problematic for performance and device longevity. The BT has a chunk of the 1.28GB system LLC/L3$, and math tells us that it is 320MB for each of the four tiles, quite a decent chunk there. The tile also has the caching agent logic and a snoop filter, plus the obvious die to die SERDES and logic. It may be active but it doesn’t all that much, at least not enough to generate tons of heat. As we stated above, the real question about the CBBs are mechanical. Will Intel put a silicon slug above the ‘blank’ area not covered by a CC? If not, how will they manage the mechanical pressure of the heat spreader and how will they contact it? How will they manage the heat? These are not trivial questions, similar issue have sunk past Intel projects as mentioned above, but much learning has been had since then, some the hard way. Two colors for the Scalable Fabric Hub That brings us to the last type of chiplet, the Fabric Hub, which in many ways is the heart of the system. Intel divides these into two logical sections based solely on the color of the transistors used, blue or brownish. That is a joke, the divisions are based roughly on whether a block is memory or fabric related, or you could envision it as internal or external facing. Flexbus I/O Fabric detail The blue, err Flexbus I/O Fabric is the external bit and it does roughly what you expect, what Xeons in the past have had updated a bit to modern standards. The new platform updates PCIe5 to PCIe6, CXL 2.x to 3, and UPI3 is now there too. The PHYs are connected to the Flexible I/O Subsystem which means each lane can be PCIe, CXL, or UPI. Xeons of the past have used PCIe physical layers for just about everything, and DMR does the same just faster. How flexible and what combinations are the key here, and that wasn’t disclosed. On paper it looks like you can have up to 128 PCIe6 lanes per socket but that means no second socket so all is not exactly rosy but tradeoffs rarely are. The I/O Caching and Filtering block is far more important than it looks, especially if you care about high speed I/O with real throughput. This is the modern iteration of DDIO which SemiAccurate first wrote about for Romley 14ish years ago. If you think about how fast a 100GbE link can fill a cache while waiting for a memory transaction, you get why DDIO is a necessity. Now think 800GbE and off you go. Snoop
document fetched 2026-09-12 02:56 · canonical https://semiaccurate.com/2026/09/11/what-is-intels-diamond-rapids-server-cpu