I think it's looking pretty good overall. Slight improvement in single core and massive improvement in multicore scores probably due to reduced L3 and inter CCX latencies. That should transfer directly to gaming results.
Ryzen 2 made at TSMC. 64 Core Epyc processor.
For structure. Can't leave those spaces empty, then expect the lid to stay straight when the cooler is fastened down.So could some one tell what the blank die does please??
I dont even need to watch the video to know that this going to be wrong........
For structure. Can't leave those spaces empty, then expect the lid to stay straight when the cooler is fastened down.
He's essentially saying AMD will go further assembling chips from multiple dies that then aren't self contained CPUs anymore like the current Zeppelin die is. Essentially similar to what Intel announced wanting to do with EMIB, mixing and matching different IPs.
Not that I'm agreeing with Adored's speculation but why do you say this?Two things. As it is if Intel is able to pull off EMIB (and Kaby-G isn't the EMIB pipecleaner that Intel has been suggesting). I will be the better solution in the long run so I hope AMD is heading towards something like that. The second is I don't see Zen 2 being what Adored suggested. Personally it seems waaay to soon for that kind of departure. On top of that it would be really awkward for desktop usage. On Epyc adding the control chip would cost 25% more on top of the "core chips". Not bad. On Ryzen 3k it would mean doubling the cost of production. Also they would probably have to design a control chip for each version of Ryzen. They probably could get away with just disabling features from the top down, but then you have on your highest volume option a chip that is 2-4 times larger than it needs to be.
To me if AMD is going to do any 5 chip EPYC, Adored is on the right track but seriously off. Instead of a control chip I could see AMD doing an off Die L4, specifically for Epyc. So a 5th chip with like 128-256MB that would be in similar die size to the other 4 die size. Something they wouldn't need to provide for Thread Ripper and Ryzen.
Not that I'm agreeing with Adored's speculation but why do you say this?
Fabbing 5 chips does not mean 25% increase in costs especially if you're eliminating duplicated circuitry. Each of the core die will be smaller and the total silicon area should be smaller, leading to even greater yields, which might be essential for 7nm. You will have to fab 2 separate designs and this will increase costs, but without details such as sales volumes, etc,` no one here can accurately predict the final composite cost.
What am I missing?
The cost for a theoretical split up Zen 2 wholly depends on the balance between 7nm yield and the vastly increased complexity of interconnects an MCM consisting of many relatively tiny parts will require. If yield is high enough AMD's current approach of having two dies covering everything of the whole products range and matching partially faulty dies with respective lower end offerings will be the safe option. To me the switch to more aggressive MCMs may be an optimization that they may target for Zen 3 or beyond where significant process node improvements are not yet a given.
Two points:If AMD were to use 5 dies, as speculated (leaked?), I think it makes sense to have 1 inter socket communication die that will take care of all the communication between chips in different sockets. Looking at the current Zeppelin die, it seems to have too much resources dedicated to implanting IF for communication. There are total 6 IF IO ports (4 IFOP and 2 IFIS/PCIe) and they will have to add more if they want to build 4/8 socket systems. Most of those are used only in the server/HEDT versions of the chip. I'd build a 1 one large IFOP per chip and use a bridge/router chip (with L4/directory cache?) to take care of inter socket communication. That way, you don't waist as much transistors for consumer dies and support 4/8 socket systems without increasing worst case latency or increase pins on the socket.
Two points:
1) Everything seemingly superfluous and a "waste of transistors" actually works as built in redundancy: If that part is faulty the die can still be used in products that don't use it.
2) If everything is split up all the routing complexity is moved from silicon to interconnects. The latter are more coarse and as such it's hard to map all the routing 1-1 there. In many parts there will be added interface logic to the silicon just for standardizing the interconnects which at some point may not worth the area overhead. Note that Epyc/Zeppelin has an area overhead of 10% for the added interfaces enabling the 4 dies chips/2 sockets systems. The smaller the parts the relatively bigger will be the area overhead needed just for connecting them all.
So we are looking @ 5% "IPC" based on
https://browser.geekbench.com/v4/cpu/compare/7144831?baseline=6690641
add a 200mhz clock bump(to base and XFR) and we are at 10% perf improvement...….
The reduction in average packet latency and average packet energy for the wireless multichip system varies between applications due to the variation in off-chip traffic patterns from different memory access patterns. However, for all application-specific traffic patterns considered here, the performance of the wireless multichip system is better than the interposer based wireline configuration. The average reduction in packet latency and packet energy for the wireless multichip system is 54% and 45% compared to the interposer based system. This is due to the energy efficient single-hop wireless links connecting processing chips and memory stacks. It is worth noting that these performance benefits can be achieved with negligible active area overhead of 0.3 mm squared per transceiver.
--
Computing modules with multiple smaller processing chips with in-package memory stacks are becoming prevalent in platform based and HPC systems due to their performance benefits and cost-effectiveness. In this work, we explore the advantages possible if the chip-to-chip and memory-to-chip communication in multichip systems can be realized with state-of-the-art mm-wave wireless links operating in the 60GHz band. The wireless links are capable of establishing direct communication channels between cores in different chips and memory stacks via on-chip embedded transceivers and antennas. Such integration mechanism results in significant gains in performance and energy consumption in data communications in a multichip environment with negligible overhead of 0.3mm squared per transceiver.
FX-14 supports 12LP.Custom Design for 5G Wireless Base Stations: The company’s application-specific integrated circuit (ASIC) design systems (FX-14 and FX-7) enable optimized 5G solutions (functional modules) by supporting wireless infrastructure protocols on high-speed SerDes, solutions to integrate advanced packaging, monolithic, ADC/DAC and programmable logic. The 5G solution includes 32G BP and 32G SR SerDes to support CPRI, JESD204C standards. It also includes advanced packaging solutions such as 2.5D and MCM, with mmWave capable ADC/DAC data converters and digital front end (DFE). FX-14 is available to customers today while volume production is expected in 2019 for FX-7.
https://www.computer.org/csdl/trans/tc/2017/07/07795230.htmlHeterogeneous System Architectures (HSA) that integrate cores of different architectures (CPU, GPU, etc.) on single chip are gaining significance for many class of applications to achieve high performance. Networks-on-Chip (NoCs) in HSA are monopolized by high volume GPU traffic, penalizing CPU application performance. In addition, building efficient interfaces between systems of different specifications while achieving optimal performance is a demanding task. Homogeneous NoCs, widely used for many core systems, fall short in meeting these communication requirements. To achieve high performance interconnection in HSA, we propose HyWin topology using mm-wave wireless links. The proposed topology implements sandboxed heterogeneous sub-networks, each designed to match needs of a processing subsystem, which are then interconnected at second level using wireless network. The sandboxed sub-networks avoid conflict of network requirements, while providing optimal performance for their respective subsystems. The long range wireless links provide low latency and low energy inter-subsystem network to provide easy access to memory controllers, lower level caches across the entire system. By implementing proposed topology for CPU/GPU HSA, we show that it improves application performance by 29 percent and reduces latency by 50 percent, while reducing energy consumption by 64.5 percent and area by 17.39 percent as compared to baseline mesh.
This sounds amazing, but seems to optimistic for the time frame imo.I speculate that breaking up the individual die tasks differently on the EPYC package will enable AMD to leverage the existing 12LP node production capacity with the new 7nm capacity. For example, high speed DRAM controllers don't need to be made at the bleeding edge node to be effective. The same for I/O controllers.
With that in mind, why not address the biggest weakness of EPYC, which is inter CCX communication latency? Build one slightly larger 7nm die that can house 8-12 CCX units linked by an on chip IF mesh with 5 high bandwidth serial I/O links. Those links go to 4 on package memory, I/O and L4 cache die that link to the on board PCI-E slots, DRAM, etc with the 5th link reserved for a direct connection to the 5th die on the second CPU.
The advantage here is that only the CPU core die needs to be 7nm. The memory controller dies can be easily made on the mature 12lp process without hampering performance. They can also easily hold 32-128 MB of L4 cache each. Such an arrangement could net you an Epyc processor with 128-512 MB of L4 cache each. The second advantage of such an arrangement comes with future proofing. Need to change the DRAM controllers to DDR5? Just change the I/O dies. Need to support pci-e 5.0? Just change the i/O chip? Want to support a large install base of servers with a new core design or a newer node that clocks faster? Change the core die. Finally get 7nm production to a very high yield ratio and have extra capacity? Move the i/O dies to it and quadruple the L4 cache amounts.
The issue is supporting so many different dies. I also don't expect that making an 8-12 CCX 7nm die will be at all easy.
I speculate that breaking up the individual die tasks differently on the EPYC package will enable AMD to leverage the existing 12LP node production capacity with the new 7nm capacity. For example, high speed DRAM controllers don't need to be made at the bleeding edge node to be effective. The same for I/O controllers.
With that in mind, why not address the biggest weakness of EPYC, which is inter CCX communication latency? Build one slightly larger 7nm die that can house 8-12 CCX units linked by an on chip IF mesh with 5 high bandwidth serial I/O links. Those links go to 4 on package memory, I/O and L4 cache die that link to the on board PCI-E slots, DRAM, etc with the 5th link reserved for a direct connection to the 5th die on the second CPU.
The advantage here is that only the CPU core die needs to be 7nm. The memory controller dies can be easily made on the mature 12lp process without hampering performance. They can also easily hold 32-128 MB of L4 cache each. Such an arrangement could net you an Epyc processor with 128-512 MB of L4 cache each. The second advantage of such an arrangement comes with future proofing. Need to change the DRAM controllers to DDR5? Just change the I/O dies. Need to support pci-e 5.0? Just change the i/O chip? Want to support a large install base of servers with a new core design or a newer node that clocks faster? Change the core die. Finally get 7nm production to a very high yield ratio and have extra capacity? Move the i/O dies to it and quadruple the L4 cache amounts.
The issue is supporting so many different dies. I also don't expect that making an 8-12 CCX 7nm die will be at all easy.
Memory latency has been a real issue with Ryzen in many tasks. AMD is on record saying this is one of the things they targeted when making Pinnacle, so it would make sense that some workloads see a major improvement. Cache latencies too, and I wouldn't be surprised to see improvements in the CCX to CCX latency. There's likely some optimization work on the branch predictor too. You can see how the multithreaded results benefitted more, but even in single threaded there's some improvement.Interesting. IPC for Pinnacle Ridge wasn't supposed to be much, if any, better than Summit Ridge. I'm intrigued.
Pinnacle Ridge will outperform people's expectations from what I've been seeing on the web, as long as it breaks the 4GHz Fmax wall. If it still can't break that wall the IPC improvements will somewhat make up for expectations on overall performance, but it won't outperform expectations.
The matching 14+ figure is for efficiency, not drive current or Fmax or anything of the sort that would tell you absolute speed.https://www.computerbase.de/2018-01/amd-ryzen-threadripper-2000/
I fully expect Pinnacle Ridge to blow past even 4.6 Ghz. AMD has given hints that GF 12nm is very close to competitor 14+ process at the CES Tech day. Its obvious the competitor is Intel 14+ process. KBL clocked 5 Ghz easily. I think AMD will get very close to KBL with around 4.8 Ghz for max clocks. In fact I think everybody is going to be surprised with max clocks of PR.
The matching 14+ figure is for efficiency, not drive current or Fmax or anything of the sort that would tell you absolute speed.
I think this is unlikely in the extreme.
One of the big reasons went to MCM for Epyc/TR is so they could leverage only doing 1 single die, and using it in multiple markets.
What you suggest here is creating multiple dies for a single market.
As much as I would love to see that, even AMD's own figures for the performance improvement aren't quite near that (a 10% improvement was mentioned by multiple, reliable sources IIRC). They could be rather conservative and probably are, but I'm expecting a 15% improvement in general, significantly better in some cases but worse in others. Still, I hope that your prediction about the 12LP process they will be using are correct.I am confident you will see at launch that PR closes the gap completely in terms of single core turbo. CFL will have an advantage in max OC as it can hit 5.2-5.4 Ghz which will not happen on 12LP. I have done my analysis and think AMD have gone for max clocks with a small die size increase. I think Zen+ will use 12LP (MMP=56nm CPP=84nm) 10.5T libraries for max frequency.