Next Generation Hardware Speculation with a Technical Spin [2018]

Status
Not open for further replies.
I may be biased but I am thinking consoles are about features and not power. The move to push chiplet design is a call for a lot of power.
One could argue that the Wii U's design used a "chiplet" for the CPU. Espresso was really just the IBM CPU cores with L2. All the I/O and memory controller were on AMD's GPU and the CPU even used the GPU's eDRAM as L3 cache.

In that case, the MCM "chiplet" design was definitely not made for power. If I recall correctly, it was made to allow different fab sourcing: CPU "chiplet" was made at IBM, GPU+eDRAM at Renesas. This factor is actually similar to EPYC's.
 
I would imagine that’s where you introduce a new IO die variant
It's more about the actual phys I/O density on the package, which is why things like Intel's EMIB or TSV interconnects were developed for higher bandwidth interconnects between chips on a particular package. The 8chan RomIO for EPYC2 implies 512-bit DDR4 to off-package DRAM, but between the chiplets there must be some limitation there (thought there was some mention of 100GB/s between GPUliets)

(have you ever heard of the tragedy of RomIO and GPUliet, daughter of the CaPUlets) :V
 
Last edited:
There should be a Sun Glasses warning on that Spoiler!
 
Versus 1 CPU, 1 GPU, one AI processor, 1 I/O chip. That’s 4x more chips.
But can't existing CPU and GPU chips already being manufactured for AMD's PC market be used? You'd get greater economies of scale there, using 'of the shelf' GPU and CPU and coupling them with relatively tiny additional processors.
 
But can't existing CPU and GPU chips already being manufactured for AMD's PC market be used? You'd get greater economies of scale there, using 'of the shelf' GPU and CPU and coupling them with relatively tiny additional processors.
Perhaps, but don’t they come with I/O in them ?

I suspect that there needs to be some form of customization, I did not think that the chiplets are so flexible to that extent, I imagine this would have been big news
 
But can't existing CPU and GPU chips already being manufactured for AMD's PC market be used? You'd get greater economies of scale there, using 'of the shelf' GPU and CPU and coupling them with relatively tiny additional processors.
Especially if the navi has been heavily developed with Sony.
could be used as a pc/console part pretty much as is.
It could be the best way to get the best price to performance for the ps5.
It would still be a semi custom apu.

Only problem is not sure if pc gpu part IO etc lends itself to it, considering amd have said no mcm consumer gpu's
 
Perhaps, but don’t they come with I/O in them ?

I suspect that there needs to be some form of customization, I did not think that the chiplets are so flexible to that extent, I imagine this would have been big news

No! The I/O is all in the I/O die. The chiplets communicate with each other and with the I/O die over IF links and then the I/O die connects to everything else. Next-gen SoC could theoretically use a generic Zen 2 chiplet and a lightly-customized GPU chiplet and custom I/O chiplet allowing for lots of parallel IF links between those latter two chiplets to support the bandwidth requirements and for connection to GDDR6.
 
No! The I/O is all in the I/O die. The chiplets communicate with each other and with the I/O die over IF links and then the I/O die connects to everything else. Next-gen SoC could theoretically use a generic Zen 2 chiplet and a lightly-customized GPU chiplet and custom I/O chiplet allowing for lots of parallel IF links between those latter two chiplets to support the bandwidth requirements and for connection to GDDR6.
I mean. Can we just take any AMD component off the shelf and make it a chiplet?

The answer would be no. It would have to be a chiplet by design before you can add the components in. So there is some form of customization required as we know today that AMD have not made a Vega + Zen 2 chiplet design.
 
No! The I/O is all in the I/O die. The chiplets communicate with each other and with the I/O die over IF links and then the I/O die connects to everything else.

I think I read somewhere that each chiplet in Rome has 16 PCIe 4.0 lanes in it. I don't remember where, and it could be wrong.
 
I mean. Can we just take any AMD component off the shelf and make it a chiplet?

The answer would be no. It would have to be a chiplet by design before you can add the components in. So there is some form of customization required as we know today that AMD have not made a Vega + Zen 2 chiplet design.

I said that the GPU and I/O die would have to be customized, but the CPU chiplet wouldn't. That specific part could be identical across a large segment of AMD's product line with binning for clockspeed and defects determining which product each produced chip was suitable for.
 
I think I read somewhere that each chiplet in Rome has 16 PCIe 4.0 lanes in it. I don't remember where, and it could be wrong.

This is the diagram I saw. And I believe I also saw it described in this way somewhere. May have to wait till closer to Rome's launch before we know for sure.

https://forums.anandtech.com/threads/64-core-epyc-rome-(zen2)architecture-overview?.2554453/#post-39585909

Also, I'm not sure you could build Rome with PCIe lanes on the CPU chiplets if you wanted to allow for different core counts, because a lower number of CPU chiplets would result in a lower # of PCIe lanes being available.
 
I said that the GPU and I/O die would have to be customized, but the CPU chiplet wouldn't. That specific part could be identical across a large segment of AMD's product line with binning for clockspeed and defects determining which product each produced chip was suitable for.
Sorry I missed that. Yes. I suppose 1/3 of the equation is already complete in theory.
 
How does Sony cover issues that might arise with swapped drives ? I am not sure for the end user its really the best of both worlds

Not sure if this has been answered...but what issues? I've not seen any issues/remarks coming from people swapping drives? Can you be a bit more specific?
 
It's more about the actual phys I/O density on the package, which is why things like Intel's EMIB or TSV interconnects were developed for higher bandwidth interconnects between chips on a particular package. The 8chan RomIO for EPYC2 implies 512-bit DDR4 to off-package DRAM, but between the chiplets there must be some limitation there (thought there was some mention of 100GB/s between GPUliets)

(have you ever heard of the tragedy of RomIO and GPUliet, daughter of the CaPUlets) :V
Agree bandwidth is a concern, but David Wang doesn’t mention it explicitly in this article.
 
I mean. Can we just take any AMD component off the shelf and make it a chiplet?

The answer would be no. It would have to be a chiplet by design before you can add the components in. So there is some form of customization required as we know today that AMD have not made a Vega + Zen 2 chiplet design.

Surely this depends on their plans for Navi/Arcturus though?

They state in the article linked by Anexanhume that a concern for a chiplet design is acceptance of it by developers, but that wouldn't be a concern in the console space, so even a monolithic GPU for Navi on PC isn't necessarily indicative of their semi-custom approach.

In an age of multi tier consoles and streaming, it's conceivable that TSMC could manufacture a GPU wafer per platform, and use a much higher percentage thereof by way of binning.

For a hypothetical example, TSMC manufacture a wafer of 20CU Navi PS5 chiplets and bin:
- the highest clocking chiplets, with all 20 CU's, for streaming servers. 8 chiplets per streaming PS5 Pro.
- lower clocked chiplets, each with 2 CU's disabled, for a PS5 Pro. 8 chiplets per console.
- even lower clocked chiplets, each with 2 CU's disabled, for a base PS5. 4 chiplets per console.
- those same lowest clocked chiplets, with 2 CU's disabled, for a streaming focused PS5 Micro. 2 chiplets per console.

So I agree that it's a great way to hit high performance, but I also think it's a great way to use the same silicon across each platform, bringing overall prices down and catering to each strata of gamer.
 
So I agree that it's a great way to hit high performance, but I also think it's a great way to use the same silicon across each platform, bringing overall prices down and catering to each strata of gamer.
So BC emulation is not a concern at all? Everyone is onboard with off the shelf components will make for a cheaper and effective console?

I can’t see this being true at $399.

Chiplets are super effective when you need to drive performance at higher core counts and a single SOC is 1000mm^2. The idea that it’s also cost effective competing with the 360mm^2 mark needs more data points.
 
Yeah, we definitely need more data points. Some sort of solid indication that AMD are committing to chiplet GPU's would also help.

But, even without those, I think it's a reasonable assumption that utilising a higher percentage of a wafer should lead to cost savings.

Sony and Microsoft may even be able to save on R&D by focusing on the I/O die, and "plugging in" chiplets as necessary. The same goes for node improvements: they can keep the I/O die ticking along on whichever node's the cheapest - keep manufacturing on 7nm, for example, without any need to R&D a 5nm or 3nm version - and plug in the new 5nm and 3nm chiplets as they become cheaper than their 7nm counterparts. Same as they currently do with memory.
 
So BC emulation is not a concern at all? Everyone is onboard with off the shelf components will make for a cheaper and effective console?

I can’t see this being true at $399.

Chiplets are super effective when you need to drive performance at higher core counts and a single SOC is 1000mm^2. The idea that it’s also cost effective competing with the 360mm^2 mark needs more data points.

For the CPU part specifically, you could consider the benefit of scale at the foundry level. Especially with the likely competition for capacity at the 7nm node. Being able to put in a massive order of one design is going to be easier to schedule with foundry partners than trying to do smaller runs of several different designs. The I/O die being at 14nm (where there is more available foundry capacity) will help here as well as it should be easier to secure a production slot for a smaller run of a more customized part. That just leaves the GPU portion as an open question.
 
Not sure if this has been answered...but what issues? I've not seen any issues/remarks coming from people swapping drives? Can you be a bit more specific?

issues would be anytime someone swaps a drive and damages connectors , has the new drive fail or doa , data transfer messes up etc
 
Status
Not open for further replies.
Back
Top