AMD - Zen 6 (c) - Medusa Ridge / Medusa Point - Ryzen 10000?
- Ersteller derDruide
- Erstellt am
derDruide
Grand Admiral Special
★ Themenstarter ★
Laut Yuri Bubliy (1usmus) sind Engineering Samples von ZEN 6 schon unterwegs.
Die Kerne pro CCD sollen auf 12 ansteigen, frühere Gerüchte halten auch 16 für möglich. Außerdem soll es zwei Speichercontroller geben, obwohl die Speicherkanäle unverändert bei zwei bleiben. Damit sollen höhere Geschwindigkeiten erreicht werden können.
Die Kerne pro CCD sollen auf 12 ansteigen, frühere Gerüchte halten auch 16 für möglich. Außerdem soll es zwei Speichercontroller geben, obwohl die Speicherkanäle unverändert bei zwei bleiben. Damit sollen höhere Geschwindigkeiten erreicht werden können.
Zuletzt bearbeitet:
Krümel
Grand Admiral Special
Hmm, ob die höhere Geschwindigkeit den synchronisationsaufwand und die damit verbundene Verzögerung (Latenz) ausgleicht?
vinacis_vivids
Admiral Special
Dual Channel DDR 5-8000 incoming?
Beim synchron Modus wäre das ein Anstieg von 8000 / 6000 ~ +33% Bandbreite ggü. dem bekannten DDR5 6000 Mhz.
Bisher hat sich gezeigt, dass 6400Mhz 1:1 synchron Memclk=UCLK genauso schnell ist wie 8000 Mhz asynchron memclk zu UCLK.
6400 / 6000 ~ 6,6% Leistungsteigerung von 6000Mhz zu 6400Mhz.
Für Zen6 mit 24C oder 32C wäre ein oder zwei IMC mit 8000Mhz synchron erforderlich, um den gestiegenen Bedarf an Bandbreite abzudecken. Zwischenschritt 7200 Mhz Synchron dann.
16C -> 24C ~ +50% cores
6000 -> 7200 ~ +20% Bandbreite
16C -> 32C ~ +100% cores
6000 -> 8000 ~+33% Bandbreite
Wäre natürlich krank wenn Zen6 mit 24C / 32C dann mit 256GB DDR5 7200 bis 8000Mhz synchron rennen kann.
AMD würde den Sockel AM5 somit auf ein neues Level heben können. Dazu muss das I/O wahrscheinlich auf 4nm umsteigen statt 6nm aktuell. 3nm I/O ist zu teuer (wie Apple APU).
Ich schätze 3nm bei den CCDs und 4nm beim I/O. Insbesondere der IMC muss hoch auf 4nm für höhere Takte und weniger Verbrauch.
Bei den MCDs bleibt es wohl bei 6nm wie RDNA3 / EPYC / X3D
Beim synchron Modus wäre das ein Anstieg von 8000 / 6000 ~ +33% Bandbreite ggü. dem bekannten DDR5 6000 Mhz.
Bisher hat sich gezeigt, dass 6400Mhz 1:1 synchron Memclk=UCLK genauso schnell ist wie 8000 Mhz asynchron memclk zu UCLK.
6400 / 6000 ~ 6,6% Leistungsteigerung von 6000Mhz zu 6400Mhz.
Für Zen6 mit 24C oder 32C wäre ein oder zwei IMC mit 8000Mhz synchron erforderlich, um den gestiegenen Bedarf an Bandbreite abzudecken. Zwischenschritt 7200 Mhz Synchron dann.
16C -> 24C ~ +50% cores
6000 -> 7200 ~ +20% Bandbreite
16C -> 32C ~ +100% cores
6000 -> 8000 ~+33% Bandbreite
Wäre natürlich krank wenn Zen6 mit 24C / 32C dann mit 256GB DDR5 7200 bis 8000Mhz synchron rennen kann.
AMD würde den Sockel AM5 somit auf ein neues Level heben können. Dazu muss das I/O wahrscheinlich auf 4nm umsteigen statt 6nm aktuell. 3nm I/O ist zu teuer (wie Apple APU).
Ich schätze 3nm bei den CCDs und 4nm beim I/O. Insbesondere der IMC muss hoch auf 4nm für höhere Takte und weniger Verbrauch.
Bei den MCDs bleibt es wohl bei 6nm wie RDNA3 / EPYC / X3D
Ich glaube ehrlich gesagt nicht, dass wir 8000 default bekommen werden. Dafür ist der Sprung zu groß. Und als JEDEC-Standard ohne XMP existiert bisher nur maximal 6400. Per XMP mag das anders aussehen, als default aber sicher nicht.
BavarianRealist
Grand Admiral Special
- Mitglied seit
- 06.02.2010
- Beiträge
- 3.386
- Renomée
- 85
Soll nicht vor allem die Latency (und der Energieverbrauch) zwischen den Chiplets sehr viel besser werden, weil sie mit dem neuen Stacking-Verfahren ganz nah zusammen rücken, sodass sie die Verbindungstechnologie nutzen sollen, wie sie in MI300 zwischen den Chiplets realisiert ist?
vinacis_vivids
Admiral Special
@Yoshi 2k3
JEDEC hat schon bis 8800 Mhz spezifiziert:
www.hardwareluxx.de
Ich denke 6000Mhz default, 6600 und bis 7200 1:1 synchron und 8000Mhz++ asynchron dann.
FCLK und UCLK müssen halt von 3000 Mhz auf 3600 Mhz oder beim OC maximal auf 4000 Mhz steigen (für 8000Mhz RAM synchron).
Und die North Bridge scheint ja doch umgebaut zu werden.
Infinity Fabric mit 6nm läuft derzeit maximal 2133Mhz (7950X) bis 2200Mhz (9950X), Mit dem Umstieg auf 4nm I/O, also auch die Fabric, dürfte locker 15-20% mehr Takte können oder auch doppelt so breit werden wie sonst:
von CCD zu cIOD sind die 16B/cycte write doch ziemlich klein, könnte auch verdoppelt werden auf 32B/cyle write und 64B/cyle read pro CCD. Innerhalb des cIOC würde wohl dann ein weiterer UMC eingebaut werden. Bei zwei CCDs wie im Abbild könnten dann pro CCD dann "dual channel" DDR5 ansprechen.
Fabric = 2000 Mhz -> 6000 Mhz RAM (zen4)
Fabric = 2167 Mhz -> 6400 Mhz RAM (zen5)
Fabric = 2400 Mhz -> 7200 Mhz RAM (zen6)
Fabric = 2600 Mhz -> 7800 Mhz RAM (zen6)
Fabric = 2666 Mhz -> 8000 Mhz RAM (zen6)
Die Taktraten für FCLK von 2167Mhz bis 2666Mhz klingen für mich synchron machbar mit dem neuen I/O. Default könnten die 2000Mhz oder 2167Mhz für die Fabric dann sein. OC und AIMP dann je nach Chipgüte bis maximal ~2666Mhz FCLK synchron für den Betrieb von 8000Mhz RAM 1:1.
JEDEC hat schon bis 8800 Mhz spezifiziert:
Nun bis 8.800 MT/s: Die JEDEC erweitert den DDR5-Standard - Hardwareluxx
Die JEDEC hat den DDR5-Speicher nun bis 8.800 MT/s spezifiziert.
www.hardwareluxx.de
Ich denke 6000Mhz default, 6600 und bis 7200 1:1 synchron und 8000Mhz++ asynchron dann.
FCLK und UCLK müssen halt von 3000 Mhz auf 3600 Mhz oder beim OC maximal auf 4000 Mhz steigen (für 8000Mhz RAM synchron).
Und die North Bridge scheint ja doch umgebaut zu werden.
Infinity Fabric mit 6nm läuft derzeit maximal 2133Mhz (7950X) bis 2200Mhz (9950X), Mit dem Umstieg auf 4nm I/O, also auch die Fabric, dürfte locker 15-20% mehr Takte können oder auch doppelt so breit werden wie sonst:
von CCD zu cIOD sind die 16B/cycte write doch ziemlich klein, könnte auch verdoppelt werden auf 32B/cyle write und 64B/cyle read pro CCD. Innerhalb des cIOC würde wohl dann ein weiterer UMC eingebaut werden. Bei zwei CCDs wie im Abbild könnten dann pro CCD dann "dual channel" DDR5 ansprechen.
Fabric = 2000 Mhz -> 6000 Mhz RAM (zen4)
Fabric = 2167 Mhz -> 6400 Mhz RAM (zen5)
Fabric = 2400 Mhz -> 7200 Mhz RAM (zen6)
Fabric = 2600 Mhz -> 7800 Mhz RAM (zen6)
Fabric = 2666 Mhz -> 8000 Mhz RAM (zen6)
Die Taktraten für FCLK von 2167Mhz bis 2666Mhz klingen für mich synchron machbar mit dem neuen I/O. Default könnten die 2000Mhz oder 2167Mhz für die Fabric dann sein. OC und AIMP dann je nach Chipgüte bis maximal ~2666Mhz FCLK synchron für den Betrieb von 8000Mhz RAM 1:1.
derDruide
Grand Admiral Special
★ Themenstarter ★
Laut Kepler_L2 im Anandtech-Forum soll ZEN 6 schon in N2P gefertigt werden, und das fast vollständig. Nur die APUs sollen zwei Verfahren nutzen (N2P und N3P, low cost APUs nur N3P).
www.3dcenter.org
Nachdem dem Tapeout im April soll das Release "grob im Sommer 2026" erfolgen.
News des 10. Juli 2025 | 3DCenter.org
Laut Tool-Programmierer '1usmus' auf Discord (gefunden und wiedergegeben von WCCF Tech) sind derzeit schon Engineering Samples zu Zen 6 im Umlauf, sprich AMD muß den angeblich im April angesetzten Tape-Out erfolgreich hinter sich gebracht haben.
Nachdem dem Tapeout im April soll das Release "grob im Sommer 2026" erfolgen.
Ja am Packing soll sich bei Zen6-Desktop einiges ändern. Ob damit ein Chipstacking wie bei MI300 kommt oder ein Fanout anstatt SERDES Interface wie bei Strix Halo weiß man noch nicht. Ich würde im Moment eher auf Letzteres tippen.
vinacis_vivids
Admiral Special
@Yoshi 2k3
Ja, richtig. Default bei Zen4 Vollbestückung ist 3600 Mhz und 4800 Mhz mit zwei Bänken. Die meisten lassen bei zwei Bänken 6000Mhz (bis max 6400 Mhz) derzeit zu.
Die Fabric 2666 Mhz = 8000 Mhz 1:1 RAM denke ich ist auch nur für ein CCD machbar, also maximal 12C oder 16C mit dem neuen Medusa Ridge Zen6-CCD.
Die hypothetische neue "Gamer-CPU" mit 12 & 16 Core und X3D IF$ sowie 6,6Ghz wird absolut krank gepaart mit FCLK 2666Mhz und 8000 Mhz 1:1 RAM.
Bei der Vollbestückung gehts dann wahrscheinlich nicht mehr so hoch, vllt. 7200Mhz - 7800Mhz bei 192GB oder 256GB DDR5-RAM.
So eine 32C / 64T Kombo mit 256 GB DDR5-7200 Vollbestückung würde mir auch schon reichen für ein upgrade. Tue mir derzeit schwer vom 7950X auf 9950X "aufzurüsten", da müssen mehr Cores her, egal ob 3NP oder 2NP.
Ja, richtig. Default bei Zen4 Vollbestückung ist 3600 Mhz und 4800 Mhz mit zwei Bänken. Die meisten lassen bei zwei Bänken 6000Mhz (bis max 6400 Mhz) derzeit zu.
Die Fabric 2666 Mhz = 8000 Mhz 1:1 RAM denke ich ist auch nur für ein CCD machbar, also maximal 12C oder 16C mit dem neuen Medusa Ridge Zen6-CCD.
Die hypothetische neue "Gamer-CPU" mit 12 & 16 Core und X3D IF$ sowie 6,6Ghz wird absolut krank gepaart mit FCLK 2666Mhz und 8000 Mhz 1:1 RAM.
Bei der Vollbestückung gehts dann wahrscheinlich nicht mehr so hoch, vllt. 7200Mhz - 7800Mhz bei 192GB oder 256GB DDR5-RAM.
So eine 32C / 64T Kombo mit 256 GB DDR5-7200 Vollbestückung würde mir auch schon reichen für ein upgrade. Tue mir derzeit schwer vom 7950X auf 9950X "aufzurüsten", da müssen mehr Cores her, egal ob 3NP oder 2NP.
vinacis_vivids
Admiral Special
Gigantischer Cache: AMD arbeitet angeblich an neuartiger X3D-CPU
AMD arbeitet Berichten zufolge an einem neuen Ryzen-Prozessor mit revolutionärer Dual-X3D-Technologie. Erstmals soll 3D-V-Cache auf beiden CCDs verbaut werden. Das dürfte unter anderem die Gaming-Performance der CPU massiv steigern.
Zen6? könnte riesigen doppelten 3D Cache haben. 16C/32T und 192MB LLC!
vinacis_vivids
Admiral Special
AMD Ryzen X mit bis zu 24 Kernen für AM5: Zen 6 CCD mit 12 Kernen, 2.5D-Interconnect und RDNA5?
AMD Ryzen X mit bis zu 24 Kernen, RDNA 5 und für AM5
Es sind erste Gerüchte zu Zen 6 aufgetaucht. Demnach setzt AMD auf einen neuen 2,5D-Interconnect mit höherer Bandbreite.
www.allround-pc.com
24Core CPU auf Zen6 Basis mit 2nm Chiplet für Sockel AM5 spekuliert.
derDruide
Grand Admiral Special
★ Themenstarter ★
AMD hat erneut bestätigt, openSIL als Open Source-Ersatz für AGESA einzuführen, für Epyc "Venice" und ZEN 6 "Medusa".
Für ZEN 4 Phoenix APUs soll die Firmware schon veröffentlicht sein, was ich noch gar nicht gelesen hatte.
Bleibt die Frage, wie man das praktisch nutzen kann.
Grundsätzlich bin ich immer für Open Source, mache mir bei dem Thema aber auch Gedanken, ob AMD wirklich auf dem richtigen Weg ist. Wenn man als einziger transparent und offen ist, kann man ja auch (zu) viel Know-How preisgeben.
wccftech.com
Für ZEN 4 Phoenix APUs soll die Firmware schon veröffentlicht sein, was ich noch gar nicht gelesen hatte.
Bleibt die Frage, wie man das praktisch nutzen kann.
Grundsätzlich bin ich immer für Open Source, mache mir bei dem Thema aber auch Gedanken, ob AMD wirklich auf dem richtigen Weg ist. Wenn man als einziger transparent und offen ist, kann man ja auch (zu) viel Know-How preisgeben.
AMD Confirms openSIL Support For Zen 6 Ryzen "Medusa" CPUs In 1H 2027, EPYC "Venice" In 2026
AMD has confirmed its commitment to openSIL "Open Firmware" for next-gen Zen 6-based Ryzen "Medusa" & EPYC "Venice" CPUs.
wccftech.com
Zuletzt bearbeitet:
derDruide
Grand Admiral Special
★ Themenstarter ★
AMD hat die erste Doku zu ZEN 6 veröffentlicht:
Performance Monitor Counters for AMD Family 1Ah Model 50h - 57h Processors
Als Features dabei sind FP16, Memory Profiler und sechs Integer Scheduler.
docs.amd.com
Performance Monitor Counters for AMD Family 1Ah Model 50h - 57h Processors
Als Features dabei sind FP16, Memory Profiler und sechs Integer Scheduler.
AMD Technical Information Portal
Complicated
Grand Admiral Special
Sehr interessantes Video mit Strix Halo Dieshots und detaillierter Beleuchtung des möglichen Interconnects für Zen6 mit Fan-Out Packaging, wie bei Strix Halo.
Basierend auf diesem Video, denke ich auch, dass Fanout der nächste logische Schritt ist zur Energieeffizienz.
Basierend auf diesem Video, denke ich auch, dass Fanout der nächste logische Schritt ist zur Energieeffizienz.
Complicated
Grand Admiral Special
Aus irgendeinem Grund konnte ich dein Zitat nicht in meinen Beitrag rein editieren
Die Annahme führt zu Konsequenzen, welche im Video ebenfalls genannt werden zum Schluß hin, bzgl. 3DCache-Dies unter dem CCD und der Beschränkung der Chipletgröße mit Fanout-Interconnects, auf die verfügbare Kantenlänge des IO-Dies. Das führt direkt dazu, dass es mehrere Versionen des IO-Dies geben muss für die unterschiedlichen Produktklassen von Mobile über Embedded und Server, abhängig von der Anzahl der CCDs, die sich mit Fanout-Packaging verbinden lassen.
Edit: Eine Schritt weiter spekuliert, wäre die Latenz des L3 Cashes mit der Fanout-Anbindung, ohne SerDes, möglicherweise niedrig genug um ihn direkt im IO-Die unterzubringen anstatt der kompletten 40 CUs von Strix Halo. Man braucht die Fläche/Kantenlänge schon wegen der (Fanout-)Anbindung an die vielen CCDs im Server.
Zuletzt bearbeitet:
Complicated
Grand Admiral Special
Nimmt man den Strix Halo Dieshot und rückt die CPU-CCDs in die Mitte, fügt darüber ein zweites GCD an, verbindet einen 12-Kern-CCD mit dem oberen GCD (180° drehen) und einen mit dem unteren erhält man eine Desktop-APU mit 24 Kernen und 80 CU (RDNA 3,5). Das wäre schon krass, sollte das möglich sein. Ganz zu schweigen von möglichen integrierten NPUs und der KI Leistung mit so einem Chip.
Wegen der Probleme mit dem Zusatzcache glaube ich ehrlich gesagt nicht so sehr an einen langfristigen Einsatz im CPU Bereich sondern eher daran das es bei Strix Halo in der Massenfertigung erprobt wurde. Längerfristig gehe ich eher davon aus das es bei den CCDs wegen der Option des darunter liegenden Zusatzcaches bleiben dürfte da er oben drauf eine zu große Bremse für den Wärmestrom ist. Bei den CCDs sehe ich das erst wieder wenn diese Vorgehensweise wieder verschwinden und statt dessen Transistorebenen im DIE gestapelt werden. In dem Fall könnte man mit der bisherigen Transistor- und Verdrahtungsebene anfangen, die Oberfläche wieder neu planarisieren, darauf die gröbere Transistorebene für den SRAM setzen und mit dessen Verdrahtungsebene weiter machen bevor es an die noch gröberen Verdrahtungsebenen zu den Bumps geht. Damit könnte man sich das ganze DIE Stacking sparen allerdings dürfte die mit Abstand größte Hürde das erneute Planarisieren der Oberfläche für den zusätzlichen Transistoraufbau sein denn ist diese dafür zu uneben kommt nur Kernschrott dabei raus.
Bei anderen Produkten wo die DIEs nur nebeneinander liege aber sehr viel Bandbreite benötigt wird spricht wiederum recht wenig dagegen.
Bei anderen Produkten wo die DIEs nur nebeneinander liege aber sehr viel Bandbreite benötigt wird spricht wiederum recht wenig dagegen.
Angeblich ist das 12 Kern Zen 6 CCD nur 76mm² groß, und damit ähnlich klein wie die bisherigen CCDs.
https://wccftech.com/amd-zen-6-ccd-slightly-bigger-than-zen-5-50-percent-more-cores-cache-tsmc-n2/
https://wccftech.com/amd-zen-6-ccd-slightly-bigger-than-zen-5-50-percent-more-cores-cache-tsmc-n2/
Die 48 MB L3 halte ich schon für wichtig, da sonst die Kapazität pro Kern im CCD sinken würde.
Ich hätte auch mit mehr gerechnet, aber der Sprung von N4 auf N2 ist auch relativ groß und das IO interface sollte wahrscheinlich deutlich kleiner werden. Es wäre auch möglich, dass AMD dank TSMCs NanoFlex die high-density libs exzessiv nutzt, um die Kerne kleiner zu bekommen.
Ich hätte auch mit mehr gerechnet, aber der Sprung von N4 auf N2 ist auch relativ groß und das IO interface sollte wahrscheinlich deutlich kleiner werden. Es wäre auch möglich, dass AMD dank TSMCs NanoFlex die high-density libs exzessiv nutzt, um die Kerne kleiner zu bekommen.
Genau das meinte ich.
Wenn lediglich das Verhältnis beibehalten wird zerschlagen sich auch alle Hoffnungen auf einen schrumpfenden Vorsprung der X3Ds. Diese Varianten werden also sehr relevant bleiben.
Da lt. bisheriger Berichte der Cache aber nur noch schlecht oder kaum schrumpft könnten ein stärkeres Komprimieren der Logik Teile aber auch erforderlich sein um die DIE Größe halbwegs beizubehalten da der Cache verhältnismäßig deutlich mehr Platz fressen würde.
Ja, das wird mit Sicherheit keinen X3D ersetzen können. 48 MB sind schon besser als bisher 32, weil die im Extremfall auch von einem Kern genutzt werden können, aber so groß ist der Sprung dann auch nicht. Noch mehr L3 würde aber zu viel Fläche benötigen.
Spannender wird es, wenn neben dem L3 auch der L2 und L1 ohne Latenzverlust gestacked werden können.
Spannender wird es, wenn neben dem L3 auch der L2 und L1 ohne Latenzverlust gestacked werden können.
Solche Extremfälle sind fürs Spielen aber eher wenig relevant. Bei aktuellen Spielen sind wir bereits bei ca. 8 genutzten Kernen und das wird eher mehr. Zudem dürften die +50% mehr L3 gegenüber der Verdreifachung der bisherigen X3D Modelle nicht viel ausmachen.
Edit:
Ein Stacken des L2 oder gar L1 Cache halte ich für extrem kontraproduktiv.
Ohne Latenzverlußte dürfte das kaum möglich sein und vor allem der L1 Cache dürfte problematisch sein da die Rechenleistung der CPU sehr empfindlich darauf reagiert.
Ich denke eher dass der L1 Cache im klassische Design bleibt weil der zu problematisch ist aber beim L2 kann ich mir durchaus vorstellen das dieser später wegen der Schrumpfungsproblematik in mehreren Layern, also Transistorebenen angelegt werden könnte. Das dürfte für die Bandbreite und Latenz deutlich weniger problematisch sein als das Stacking. Der L3 bildet dann eher die Masse um stärker vom Speicherinterface zu entkoppeln und die inter Core Kommunikation zu verbessern. Es ist also eher eine Abkürzung zu den externen Schnittstellen welche schon aufgrund der deutlich längeren Signalwege auch eine deutlich schlechtere Latenz bieten würden.
Edit:
Ein Stacken des L2 oder gar L1 Cache halte ich für extrem kontraproduktiv.
Ohne Latenzverlußte dürfte das kaum möglich sein und vor allem der L1 Cache dürfte problematisch sein da die Rechenleistung der CPU sehr empfindlich darauf reagiert.
Ich denke eher dass der L1 Cache im klassische Design bleibt weil der zu problematisch ist aber beim L2 kann ich mir durchaus vorstellen das dieser später wegen der Schrumpfungsproblematik in mehreren Layern, also Transistorebenen angelegt werden könnte. Das dürfte für die Bandbreite und Latenz deutlich weniger problematisch sein als das Stacking. Der L3 bildet dann eher die Masse um stärker vom Speicherinterface zu entkoppeln und die inter Core Kommunikation zu verbessern. Es ist also eher eine Abkürzung zu den externen Schnittstellen welche schon aufgrund der deutlich längeren Signalwege auch eine deutlich schlechtere Latenz bieten würden.
Zuletzt bearbeitet:
