Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)

[DisEnchantment]

Speculate at will

 

[adroc_thurston]

Zen4 c has 16MB L3
V-cache for that would be 32MB

Dense CCD is never getting any V$.

This is the only way your server = Zen c

wat

 

[PJVol]

N3e/p/whatever literally have 0% SRAM scaling off N5.

What are the reasons behind poor SRAM density scaling in general?

 

[maddie]

Client will look like STX-halo, server will be akin to Navi4C.

As cache is area constant now, are you saying that Zen5 c will have 32MB L3 (2X % area of chiplet). This is the only way your server = Zen c and your 32MB + 1 Hi 64MB claims can coexist.

wat

This is the progression .

 

[adroc_thurston]

What are the reasons behind poor SRAM density scaling in general?

Iirc it's mostly assist circuitry woes (but the bitcell itself is hardly scaling too).

This is the progression .

Where did I mention Dense ever.
Navi4C is the canned composable RDNA4, from which Venice inherits the bulk of system design features.

 

[PJVol]

Fixed, in Navi4C C=Canned, i.e. it was designed to be canned

 

[LightningZ71]

Stacked cache could eventually move to N4P and realize power, density and speed improvements over the existing N6 based product. It's likely going to have to wait for N4P to come down in price considerably.

Going farther down that well, the only thing that looks like it might scale cache any farther is adding BSPD and GAA tech to it. However, neither of those stand to make a large effect on the size of L2 cache cells, so the scaling will be limited still and VERY expensive.

 

[maddie]

Iirc it's mostly assist circuitry woes (but the bitcell itself is hardly scaling too).

Where did I mention Dense ever.
Navi4C is the canned composable RDNA4, from which Venice inherits the bulk of system design features.

My mistake.

 

[Joe NYC]

My belief is that, the reason for Mick Clark's excitement is because of new design approach for Zen5 rather than for outright performance. In addition, the question was a directed question about future Zen versions. Of course AMD had big expectations for Bulldozer and Original Phenom.

At the time of the interview, Zen 5 was still in the "expectations" stage. But today, Zen 5 is already running, it is sampling. So it is way past the expectations stage.

 

[Joe NYC]

Stacked cache could eventually move to N4P and realize power, density and speed improvements over the existing N6 based product. It's likely going to have to wait for N4P to come down in price considerably.

Going farther down that well, the only thing that looks like it might scale cache any farther is adding BSPD and GAA tech to it. However, neither of those stand to make a large effect on the size of L2 cache cells, so the scaling will be limited still and VERY expensive.

Why would there be an incentive to move V-Cache to N4P?

N7 / N6 cache is already keeping up with Zen 4 just fine. If Zen 5 unlikely go get higher clock speeds, the same V-Cache should keep up with Zen 5 just fine. If more bandwidth is needed, it is a question of how the cache is organized, not necesarily about chasing clock speeds.

In L3 capacity per dollar, N6 / N7 has a substantial lead.

 

[Joe NYC]

Well you still stack cache on a CCD so not much difference.

Except, on Zen4c.

But with Zen5c, presumably being a unified 16 core CCD, it might be feasible to stack V-Cache on these. Any chance AMD is working on Zen5c-X?

 

[Kepler_L2]

Fixed, in Navi4C C=Canned, i.e. it was designed to be canned

C was for Colossal AFAIK.

 

[adroc_thurston]

But with Zen5c, presumably being a unified 16 core CCD, it might be feasible to stack V-Cache on these

No.

Any chance AMD is working on Zen5c-X?

No.
c means poverty.
They're poverty cores for poverty markets.

 

[Kemano]

You seem to be a very informed persion.
If you don't mind, I'd like to take a few shots at asking you.

EVen before the introduction of V$ on CCD-s, but even more since then, I have been wondering why amd did not try to mitigate cross-CCD latency / communication with an L4$ on board of the IOD. Without 3D stacking I understand it would have made the IOD too big. But 3D stacked an L4$ connecting all CCD-s could have been somewhat helpful.
My guess to answer this question is that the bandwidth between the CCD and IOD is not sufficient for doing that. It may occasionally save the time of accessing memory but it would still be slow.
To do so AMD would need the replace current CCD-IOD connection to a high bandwidth one.

On the other hand since the introduction of Mi300 I have been wondering when/if amd would put a base die under CCD-s connecting 2-4 CCDs together with a unified L4$. In the cpu quadrant of Mi300 it is likely so.

 

[LightningZ71]

Why would there be an incentive to move V-Cache to N4P?

N7 / N6 cache is already keeping up with Zen 4 just fine. If Zen 5 unlikely go get higher clock speeds, the same V-Cache should keep up with Zen 5 just fine. If more bandwidth is needed, it is a question of how the cache is organized, not necesarily about chasing clock speeds.

In L3 capacity per dollar, N6 / N7 has a substantial lead.

Why would they move it to N4P? N4P, even for cache, still has scaling and power advantages over N6. Yes, it costs considerably more TODAY, but, if AMD can get more usable dies per wafer from it, those dies support higher operating speeds at lower power, it can help make up for the hit to peak operating frequency that stacked cache CCDs are still experiencing.

It doesn't make sense TODAY. We don't know how the math works out TOMORROW.

 

[Mopetar]

What are the reasons behind poor SRAM density scaling in general?

It's been slowing down for a while now, but part of the reason it's essentially stopped is that the newer nodes are having to focus on being able to shrink logic and the design choices that enable that are at odds with being able to shrink SRAM.

It's not that it's impossible to do, just that it can't be done reliably on the same silicon that contains all of the logic. With their v-cache dies, AMD was able to achieve about twice the density in the SRAM because they were building a die that only contained SRAM.

The two main issues that I've heard describing why are that SRAM scaling is effectively limited by gate pitch and as there was a move to FinFET, that slowed. The second is that it gets harder to get SRAM to perform reliably as voltage decreases so any shrinks on the node wind up being eliminated due to added circuitry to make sure the cache remains stable or enable error detection/correction.

 

[DrMrLordX]

They're poverty cores for poverty markets.

I figured they were cloud cores for cloud markets. We should expect a Zen5c successor to Bergamo, no?

 

[Joe NYC]

I figured they were cloud cores for cloud markets. We should expect a Zen5c successor to Bergamo, no?

Zen5c CCD is the successor to Bergamo Zen4c CCD, with 16 cores.

It will be interesting to find out if AMD built in ability to stack V-Cache. It seems like all these cores on the CCD would benefit from larger L3, given that the on-die L3 is halved.

But adding stacked die on N3 needs its own validation, and the layout of the CCD would need to accommodate the TSVs (maybe some area overhead as well), both of which point to AMD likely skipping V-Cache for this product in favor of faster time to market.

 

[adroc_thurston]

I have been wondering why amd did not try to mitigate cross-CCD latency / communication with an L4$ on board of the IOD.

SLCs have horrible latency and power characteristics and thus are not really suitable for CPUs.

 

[adroc_thurston]

I figured they were cloud cores for cloud markets. We should expect a Zen5c successor to Bergamo, no?

Yes.
But cloud is a poverty market, every cent matters there.

 

[soresu]

We should expect a Zen5c successor to Bergamo, no?

Supposedly its codename is Sienna.

 

[adroc_thurston]

Supposedly its codename is Sienna.

Siena is the edge/embedded Z4c-based EPYC.
Turin-Dense is called Turin-Dense as far as you should care about it.

 

[A///]

slc is single layer cache in this instance?

 

[Joe NYC]

slc is single layer cache in this instance?

That would be System Level Cache in this context.

 

[A///]

That would be System Level Cache in this context.

right I was too distracted by your constant bringing up a 16 core die with cache theory.

 

[kir123]

Probably meant to ask if Wafer-on-Wafer n3 (cores only) + n4 (level 2 and 3 cache) would be a viable option for zen5c.
Definitely cheaper than n2p