CCX Size

Moving down in node size brings up a number of challenges in the core and beyond. Even disregarding power and frequency, the ability to put structures into silicon and then integrate that silicon into the package, as well as providing power to the right parts of the silicon through the right connections becomes an exercise in itself. AMD gave us some insight into how 7nm changed some of its designs, as well as the packaging challenges therein.

A key metric given up by AMD relates to the core complex: four cores, the associated core structures, and then L2 and L3 caches. With 12nm and the Zen+ core, AMD stated that a single core complex was ~60 square millimeters, which separates into 44mm2 for the cores and 16mm2 for the 8MB of L3 per CCX. Add two of these 60mm2 complexes with a memory controller, PCIe lanes, four IF links, and other IO, and a Zen+ zeppelin die was 213 mm2 in total.

For Zen 2, a single chiplet is 74mm2, of which 31.3 mm2 is a core complex with 16 MB of L3. AMD did not breakdown this 31.3 number into cores and L3, but one might imagine that the L3 might be approaching 50% of that number. The reason the chiplet is so much smaller is that it doesn’t need memory controllers, it only has one IF link, and has no IO, because all of the platform requirements are on the IO die. This allows AMD to make the chiplets extremely compact. However if AMD intends to keep increasing the L3 cache, we might end up with most of the chip as L3.

Overall however, AMD has stated that the CCX (cores plus L3) has decreased in size by 47%. That is showing great scaling, especially if the +15% raw instruction throughput and increased frequency comes into play. Performance per mm2 is going to be a very exciting metric.

Packaging

With Matisse staying in the AM4 socket, and Rome in the EPYC socket, AMD stated that they had to make some bets on its packaging technology in order to maintain compatibility. Invariably some of these bets end up being tradeoffs for continual support, however AMD believes that the extra effort has been worth the continued compatibility.

One of the key points AMD spoke about with relation to packaging is how each of the silicon dies are attached to the package. In order to enable a pin-grid array desktop processor, the silicon has to be affixed to the processor in a BGA fashion. AMD stated that due to the 7nm process, the bump pitch (the distance between the solder balls on the silicon die and package) reduced from 150 microns on 12nm to 130 microns on 7nm. This doesn’t sound like much, however AMD stated that there are only two vendors in the world with technology sufficient to do this. The only alternative would be to have a bigger bit of silicon to support a larger bump pitch, ultimately leading to a lot of empty silicon (or a different design paradigm).

One of the ways in order to enable the tighter bump pitch is to adjust how the bumps are processed on the underside of the die. Normally a solder bump on a package is a blob/ball of lead-free solder, relying on the physics of surface tension and reflow to ensure it is consistent and regular. In order to enable the tighter bump pitches however, AMD had to move to a copper pillar solder bump topology.

In order to enable this feature, copper is epitaxially deposited within a mask in order to create a ‘stand’ on which the reflow solder sits. Due to the diameter of the pillar, less solder mask is needed and it creates a smaller solder radius. AMD also came across another issue, due to its dual die design inside Matisse: if the IO die uses standard solder bump masks, and the chiplets use copper pillars, there needs to be a level of height consistency for integrated heat spreaders. For the smaller copper pillars, this means managing the level of copper pillar growth.

AMD explained that it was actually easier to manage this connection implementation than it would be to build different height heatspreaders, as the stamping process used for heatspreaders would not enable such a low tolerance. AMD expects all of its 7nm designs in the future to use the copper pillar implementation.

Routing

Beyond just putting the silicon onto the organic substrate, that substrate has to manage connections between the die and externally to the die. AMD had to increase the number of substrate layers in the package to 12 for Matisse in order to handle the extra routing (no word on how many layers are required in Rome, perhaps 14). This also becomes somewhat complicated for single core chiplet and dual core chiplet processors, especially when testing the silicon before placing it onto the package.

From the diagram we can clearly see the IF links from the two chiplets going to the IO die, with the IO die also handling the memory controllers and what looks like power plane duties as well. There are no in-package links between the chiplets, in case anyone was still wondering: the chiplets have no way of direct communication – all communication between chiplets is handled through the IO die.

AMD stated that with this layout they also had to be mindful of how the processor was placed in the system, as well as cooling and memory layout. Also, when it comes to faster memory support, or the tighter tolerances of PCIe 4.0, all of this also needs to be taken into consideration as provide the optimal path for signaling without interference from other traces and other routing.

New Instructions: Cache and Memory Bandwidth QoS Control AMD Zen 2 Microarchitecture Overview: The Quick Analysis
Comments Locked

216 Comments

View All Comments

  • Gastec - Wednesday, June 19, 2019 - link

    I'm 95% convinced that your micro-stuttering is caused by the GPU/drivers. Disable SLI or Crossfire if that's what you have (you never said what video card you use). And please stop trolling.
  • wurizen - Thursday, June 20, 2019 - link

    Really? After all that I said about this... you think that you're 95% sure it's caused by GPU drivers and you want me to disable SLI or Crossfire? Really?
  • Qasar - Thursday, June 20, 2019 - link

    have you even mentioned which vid card you are using, or what version the drivers are, or if they are up to date ??
  • Gastec - Wednesday, June 19, 2019 - link

    It could also be related to G-sync/FreeSync and your monitor. When debugging the best way is to reduce everything to a minimum.
  • wurizen - Thursday, June 20, 2019 - link

    Really, dude? You think it's related to Gsyng and Freesync?
  • Qasar - Thursday, June 20, 2019 - link

    it very well could be.. a little while ago.. there was a whole issue with micro stuttering and the fix.. was in new drivers after a certain revision...
  • wurizen - Thursday, June 20, 2019 - link

    This is gonna be my last comment regarding my comment about Infinity Fabric High memory latency issue... an objective response would be "It could;" or, "it's quit possible;" or, "110 nanoseconds latency via cross-ccx-memory-performance is nothing to sneeze at or disregard or a non-issue;"

    instead, i get the replies above; which doesn't need to be repeated since one can just read them. but, just in case, the replies basically say I am trolling such as the most recent from user Gastec; and someone prior I jumped to my conclusion of pointing my scrawny little finger at Infinity Fabric high memory latency; someone plain said I didn't know what I was talking about; etc!

    So, I just wanna say that as my one last piece. It's odd no one has aired to the caution of objectivity and just plain responded with "It's possible..."

    Instead, we get the usual techligious/fanboyish responses.
  • Qasar - Thursday, June 20, 2019 - link

    it doesnt help, you also havent cited any links or other proof of this other then your own posts... and i quote " And, there are people having head-scratching issues similar to me with Ryzen CPU. " oh.. and where are these other people ?? where are the links and URLs that show this ??? lastly.. IF you have a spare hdd ( ssd or mechanical ) that isnt in use that you could install windows on to, so you wont have to touch the current one you are using, try installing windows on to that, update windows as much as you can via windows update, update all drivers, and do the same things you are doing to get this issue.. and see if you still get it.. if you do.. then it isnt your current install of windows, and it is something else.
  • Carmen00 - Friday, June 21, 2019 - link

    Qasar, Gastec et al, I appreciate that you're trying to educate wurizen but when you get responses like "bruh!" and "Really?", I think it's time to call it quits. Like HStewart, feeding wurizen will just encourage him and that makes it difficult to go through the comments and see the important ones. Trust that the majority of Anandtech's readership is indeed savvy enough to know pseudo-technical BS when we encounter it!
  • Qasar - Friday, June 21, 2019 - link

    well.. the fact that he didnt cite any one else with this problem, or links to forums/web pages.. kind of showed he was just trolling.. but i figured... was worth a shot to give him some sort of help....

Log in

Don't have an account? Sign up now