The worst of Intel's processor core asymmetry was with Meteor Lake and Arrow Lake, where the two LP-E cores on the IO die had no L3 cache and really bad DRAM latency despite being directly adjacent to the DRAM controller, resulting in those two cores combined offering about as much performance as one of the E-cores on the CPU chiplet. And they used the same IO die across both generations, while updating the microarchitecture of the CPU chiplet, so things diverged even more. And because the performance of the LP-E cores was so bad, Windows wouldn't schedule any threads on them unless it was trying to operate exclusively on those LP-E cores with the CPU chiplet powered down entirely—but those two LP-E cores were still reported to software in the total thread count, so heavy multithreaded applications would launch two more threads than could actually be scheduled at once.

With Panther Lake, Intel still has three tiers of CPU cores, but the performance gap between E cores and LP-E cores is down to only about 10%.

What needs to fail here is the instruction doing insanely slow MMIO. That's not going to be too hard to debug; none of the examples of suitably slow instructions are anywhere close to reasonable, and a fault on a vmovdqu in MMIO address space is a big red flag.

And this attack requires enough ridiculous behavior from coordinating software beyond just the single super-slow instruction that it's hard to imagine any reasonable workload being affected if this case starts causing a fault.

The base interface die has eight or 12 memory dies stacked on top of it. The wafer cost of that interface die is therefore small.

If the process of die thinning and TSV stacking reduced yields by a factor of three, nobody would consider HBM mature enough to put into production, and especially not mature enough to be increasing stack height from one generation to the next.

Trace length has approximately nothing to do with die size. If anything, designing for shorter traces means you can get away with smaller PHYs at either end.

What might go some ways toward explaining such a huge difference in die size is that the TSVs themselves take up significant die area and must be fairly numerous to carry both a large number of signal wires and all the power and ground required by the stack. But it's wildly implausible that the die area consumed by the TSVs would be significantly larger than the die area consumed by the memory arrays themselves, or that anyone would build a memory die where the memory array was not a large majority of the total die area.

If there's any truth to that ~3x higher wafer requirement for the same number of bits as compared to DDR5, it must be a combination of several factors and probably includes something non-obvious and dubious, like counting all the area of the passive interposers that go between HBM stacks and GPUs (those interposers aren't competing for the same fab space).

Did you mean that each HBM3 stack is that large? Because it only takes one glance to see that the memory chips are much smaller than reticle-sized GPUs they sit next to.

You could try reading the footnotes, which include a link to https://www.amd.com/content/dam/amd/en/documents/solutions/a...

This announcement is for a system to do the first phase on Helios and the second phase on WSE.