News AMD Zen 5: Hochauflösende Die-Shots zeigen überraschende Änderungen

[Rock Lee]

Was auch nur 600€ sind

Inflationsbereinigt ca 954 Euro, wenn wir schon dabei sind

 

[M1ch431]

Bisher kein OC bei X3D wegen dem thermisch schwierigen Stapelcache über den Hotdpots. Außerdem bei Dual CCD nur ein Cache und Schedulerprobleme.

Meine Vermutung:

• Cache überlagert nicht mehr die hotspots der compute teile der CPU -> OC möglich und hoher Takt wie die non X3D
• Entweder halber X3D Cache für Single CCD und voller für Dual CCD -> keine Schedulerprobleme und größere X3D CPUs lassen sich besser verkaufen
• Oder stacked cache auf allen ccd Varianten -> Latenz wird von höheren Takt kompensiert und die dual CCDs haben doppelt so viel Cache (vermutlich unwahrscheinlich)

 

[eastcoast_pete]

Schon sehr interessant und auch (IMHO) immer wieder schön anzusehen - nackte Tatsachen in Silizium, und dabei 100% jugendfrei 😁.
Ich bin auch schon gespannt, wie die-shots von Arrow Lake dann im Vergleich aussehen.

 

[wern001]

Prima Wallpaper-Material.

und zum ausdrucken in Postergröße

 

[Convert]

Bei EPYC scheidet diese Lösung aus, weil man auf diese Art und Weise gar nicht alle CCDs mit dem IOD Verbinden kann.

Nicht kann? MI300 hat 3 CCDs. Wenn man die GPU-XCDs weglässt, hätte man bei MI300 12CCD drauf packen können. Wenn man den Base Tile durch mehr Cache noch größer machen würde, würden auch mehr CCDs drauf passen.

Einziger Nachteil: Die MI300 hätte "nur" 256MB L4-Cache für 12 CCDs. Wenn man allerdings den Interposer weg lassen würde, weil man ja kein HBM braucht, dann könnte man 32MB X3D-L3-Cache auf die CCDs packen, die CCDs mit X3D-L3 dann auf den Base Tile mit Speichercontroller/IO und L4-Cache drauf packen und man hätte wie bei MI 300 drei Schichten, nur statt Interposer unten die X3D-Caches oben und durch den L4-Cache im Base Tile hätten alle Kerne schnell mit einander komunzizieren können.

 

[ETI1120]

Nicht kann?

Beim EPYC funktioniert es nicht weil der IOD nicht mit 12 CCD oder gar 16 CCDs per Hybrid bonding verbunden werden kann, es geht rein mechanisch nicht.

Natürlich kann man sich eine Architektur ausdenken bei der man CCDs per Hybrid Bonding auf einen IOD packt aber es kommt kein EPYC raus, der in die SP5 Plattform passt.

Und ohne Plattform taugt eine CPU nichts.

MI300 hat 3 CCDs. Wenn man die GPU-XCDs weglässt, hätte man bei MI300 12CCD drauf packen können. Wenn man den Base Tile durch mehr Cache noch größer machen würde, würden auch mehr CCDs drauf passen.

Es gab Spekulationen, dass AMD so etwas bringen könnte, als Konkurrenz zu den Intel Max Series. Ja die Rechnung zeigt dass man damit wie bei Genoa 96 Kerne bereitstellen könnte. Aber es wäre eine Variante der MI300 und kein EPYC. Denn sie passt nicht in SP5, sondern würde in die Plattform der
MI300A passen.

Einziger Nachteil: Die MI300 hätte "nur" 256MB L4-Cache für 12 CCDs.

Das spielt bei der verfügbaren Speicherbandbreite die Rolle.

Wichtiger sind dass das Teil nur 48 PCIe Lanes hätte und beim Speicherausbau ziemlich begrenzt ist. Es wäre eine HPC CPU. Braucht man so etwas?

Wenn man allerdings den Interposer weg lassen würde, weil man ja kein HBM braucht,

Ohne HBM hätte man keinen Hauptspeicher. Die IODs der MI300 haben kein DDR 5 Speicher Interface.

dann könnte man 32MB X3D-L3-Cache auf die CCDs packen, die CCDs mit X3D-L3 dann auf den Base Tile mit Speichercontroller/IO und L4-Cache drauf packen und man hätte wie bei MI 300 drei Schichten, nur statt Interposer unten die X3D-Caches oben und durch den L4-Cache im Base Tile hätten alle Kerne schnell mit einander komunzizieren können.

Ohne Interposer hast Du gar nichts weil dann die 4 IODs nicht gekoppelt sind.

Mit einem einzelnen IOD hättest Du eine CPU mit 24 Kernen. Dafür wären die Infinity Links mit denen die anderen IODs angeschlossen werden wieder verfügbar. Vielleicht könnte man sie umwidmen und für CXL verwenden und darüber den Hauptspeicher anschließen.

Ich bezweifle, dass es sich lohnt dafür eine Plattform zu entwickeln.

 

[stefan92x]

Natürlich kann man sich eine Architektur ausdenken bei der man CCDs per Hybrid Bonding auf einen IOD packt aber es kommt kein EPYC raus, der in die SP5 Plattform passt.

Kann man sich schon passend ausdenken. Man müsste halt den IOD passend designen (also nicht den von MI300 verwenden, sondern einen eigenen), dann könnte man auch so ein Package bauen. Dann bekommt der IOD halt DDR5 statt HBM3 Interface und über die Anzahl PCIe-Lanes kann man dann ja auch nochmal nachdenken. Physisch passen würde sowas auf jeden Fall, der MI300-Sockel SH5 ist ja von den Abmessungen her identisch zu SP5.

Klar ist aber auch, dass das nicht passieren wird, da das natürlich eine massive Abweichung von allem wäre, was wir über Zen 5 Epyc bereits wissen.

 

[ETI1120]

Bei Zen 6 ändert sich einiges im Package. Es soll Advanced Packaging verwendet werden. Hier war ich lange überzeugt dass es Fanout wird. Es könnte auch ein Substrat mit Glaskern werden. Hier hat AMD ein Patent und es wabern Gerüchte (Trend Force) herum, dass AMD 2025/2026 mit Glassubstraten beginnen wird.

Es gibt das Gerücht (MLID) dass AMD für Zen 6 einen modularen IOD bringt. Hier bin ich skeptisch wie das funktionieren soll. Wie soll damit der Vorteil des zentralen IOD aufrecht erhalten werden? Sowohl was die Kommunikation zwischen zwei Kernen in unterschiedlichen CCDs als auch was den Zugriff auf den Speicher betrifft.

Wenn Kommunikation oder Speicherzugriff über zwei IOD statt einen IOD laufen, wird es nicht schneller. Deshalb sitzen die IOD bei der MI300 auf einem teuren Silizium Interposer. So viel Aufwand für einen modularen IOD?

Bei EPYC gibt es viel dringendere Themen wie das Einbinden von SmartNIC, DPU, NPU oder optical Links ins Package. Da bei Zen 5 alles noch über das klassische organische Substrat läuft, erwarte ich bei Zen 5 noch nichts in diese Richtung.

IMO ist bei den CPUs der Einsatz von Hybrid Bonding bei den Mobil SoC am dringendsten. Dies würde den Chipletansatz mit minimalen Energieverbrauch ermöglichen. Aber hier stehen (noch) die Kosten des Hybrid Bonding und die Herausforderungen der Wärmeabfuhr im Weg.

Hier wäre IOD unten und CPU, NPU und GPU oben. In das IOD könnte man auch den System Level Cache packen. Der Vorteil wäre enorm weil die IO-Funktionen, die nicht skalieren in einem billigen Node gefertigt würden und die Rechenwerke, die skalieren, mit modernen Nodes gefertigt würden. Mobilen Anwendungen werden auf möglichst wenig power optimiert, was auch helfen würde das Problem mit der Wärmeabfuhr unter Kontrolle zu behalten.

 

[fdsonne]

Sorry, da sind ein paar Halbweisheiten drin, das kann ich so nicht stehen lassen:

Danke für die Ausführung, leider verlierst du dich sehr stark in Details und im Wording und kommst am Ende doch irgendwie zu keiner anderen Aussage als ich?

Doch genau das. Der Roh Wafer, also das was wir sehen ist immer 0,4 bis 0,5mm dick, also im Vergleich zu den Transistoren selbst ungeheuer dick. Wenn man auf die CPU guckt, guckt man auf die Rückseite des Wafers. Die feinsten Transistoren des ersten Logiklayers werden in diesen Wafer geätzt, mittels electroplating aufgefüllt und mit einer oxidschicht versehen. Alle darauf folgenden Schichten wachsen nach Oben aus Chipsicht, das heißt richtung Sockel. Diese werden erst auf dem kristallinen Wafer in einem chemischen Abscheideprozess "gewachsen". Nach jedem Auftrag kommt wieder photolack, Belichtung, Ätzen, elektroplatieren, oxidieren, aktivieren, wachsen, etc.

Hier ein Beispiel dazu. Ich sprach von "Das ist nicht wie ne paar Millimeter dicke Platte" -> und du führst aus, dass der Rohwafer 0,5mm dick ist.
0,5 sind nicht "paar Millimeter". Der Rest sind viele Details, wirklich nice to know, ganz ehrlich, danke dafür, aber das ist doch in der Aussage nicht relevant?

Nein, das ist kein Träger, das ist der Wafer selber. Beim Wafer von Schutzschicht zu sprechen ist nicht korrekt, weil er eben nicht nur die erste Lage an den feinsten Layern selbst beinhaltet, bzw. auch alle anderen dadurch dass es ein Mono-Kristall ist der nicht gestapelt sondern gewachsen ist.

Auch hier, das ändert doch an der Aussage nichts? Es ist ein mehrschichtiges Gebilde. Ob jetzt gewachsen, gestapelt, gebeamt, ge- was auch immer, ist doch gar nicht entscheidend? Dieses Material trägt den Inhalt, die Logik, die Metal Layer usw. und schützt letztlich auch den Kram. Der Spaß wird in hochreinen Umgebungen gefertigt. So ne CPU kannst du ohne Deckel auch in den Dreck schmeißen und das geht immer noch. Das ist perse also irgendwo auch ein Schutz.

Wenn man sich die Videos bspw. von Roman dazu anschaut, wo CPUs in Mikroskopen durchleuchtet wurden, sieht man das auch sehr schön. Da ist rings um alle Transistoren vergleichsweise dick Material und über bzw. unter den Transistoren, je nach Blickrichtung eben die verschiedenen Lagen an Verbindungen.

Genau, der CPU-DIE wird abgeschliffen, dann kommt der Cache-DIE drauf und wird gebondet. Das was man sieht ist dann nicht mehr der Wafer vom CPU-DIE wie sonst sondern der Wafer vom Cache-DIE. Unterschiede in der Dicke des verbleibenden passiven Siliziumteils sind theoretisch vorhanden aber vernachlässigbar, weil der Metal stack im Chip selber wirklich nur hundertstel der Waferdicke ausmacht und der Wafer vom Cache sehr ähnlich dick sein wird wie der einer non-x3d CPU.

Sagt im Endeffekt auch das gleiche wie oben, nur in der anderer Wortwahl - schleifst du den X3D Prozessor Die runter, dann kommt in der Mitte der Cache und an den Seiten schleifst du den Dummy weg.

Auf die Bereichen wo die Kerne sitzen wird bisher ein Silizium Dummy draufgeklebt. Das ist einfach rohes Wafermaterial in gleicher Dicke wie der Cache-Wafer. Ja, der verfügt über keine Kupferlayer und kein nachträglich gewachsenes Silizium aber ist auch je ein einzelner Kristall. Die Kupfer traces innerhalb des Cache-DIEs werden wegen der guten Wärmeleitfähigkeit von Kupfer eben höchstens einen positiven unterschied machen. Das Silizium ist praktisch gleich, weil es durch den chemischen Wuchs wieder ein Einzelkristall ist, genau wie der Dummy wafer auch. Nur waren es bisher halt mindestens vier zusammen geklebte Kristalle, der vom CPU-Die unten, der vom Cache drauf und zwei dummy-DIEs daneben über den Kernen. Wenn man das auf zwei reduziert dürfte das besser sein von der Wärmeleitung. Cache dürfte eigentlich besser die Wärme leiten als leeres Silizium was da bisher war.

Von der Argumentrichtung her ja, aber die Überlegung der Leute hier und auch im Artikel war, dass die Wärme nicht an den Stellen primär abgeben wird, wo der Cache sitzt, einfach weil durch die Logikschaltung mehr Verlustleistung entsteht als durch die Cacheschaltungen, egal ob nun huckepack oder nicht.

Sprich wenn da jetzt etwas über (oder unterhalb) der Kerne klebt, was Teile der Logik verdeckt, könnte das zu einem Problem werden. Wohlgemerkt, könnte...

Nichts desto trotz möchte ich darauf hinweisen, dass ich sagte, dass das mMn nicht wirklich ein Problem ist, weil wie du es ja selbst ausführtest, da ist auf den Logikteilen ein Dummy drauf. Der ist halt so dick wie er ist. Die CPU selbst ohne den Huckepack Cache ist doch nicht höher oder niedriger als mit? Sprich wahrscheinlich ist die absolute Höhe zwischen den (Richtung Kühler) obersten Ebenen ähnlich bis fast gleich dick. Es geht halt durch den Dummy oder es bleibt bei der normalen unverheirateten Version ohne Dummy. Wenn also das Material gleich dick ist, und generell gleich bis stark ähnlich, kommt die Wärme so oder so relativ gleich schnell da durch. Beim Cache kommt maximal dazu, dass der Cache Bereich auch entsprechender Belastung etwas an Wärme abgeben wird. Das wird dann addiert zu der Wärme, die von "unten" kommt. Dafür stehen möglicherweise potentiell bessere Wärmeleiteigenschaften aufgrund der Metallschichten ggü. dem Dummy ohne diese - wobei das auch nicht bewiesen ist? Vielleicht haben die Dummys auch Metalschichten zur Hitzeverteilung??

Das ist eben nicht korrekt. EIn Chip besteht sehr wohl nur aus einer Lage Silizium. Das ist wie gesagt dem Umstand geschuldet dass Siliziumwafer ein Monokristalliner Werkstoff sind und per chemischen Wachstumsprozess hergestellt werden.

Was du meinst sind die Metal Layer in dem Prozess, die bei modernen Prozessen schon über 30 sein können.

Wenn du es so willst, mag das stimmen. Aber das war so nicht gemeint. Gemeint war, dass die horizontale Ebene nicht identisch sein muss und eben die Metallschichten unterschiedlich "dick" ausfallen können - je nach Prozess(or). Sprich die Aussage im Artikel (darauf war das ja bezogen), dass eine Lage Cache drauf pauschal hinderlich ist, muss lange nicht stimmen, weil es der Energie egal ist, durch was sie geht - die Summe aller Eigenschaften bestimmt wie gut oder schlecht das funktioniert. Ein Layer Logik mit einer Lage Cache drauf kann damit theoretisch auch besser die Wärme abführen als eine Lage Logik ohne Cache, wenn andere Gegebenheiten für schlechtere Wärmeleitfähigkeiten sorgen.

Das war mit mehrlagig gemeint. In den Mikroskop Aufnahmen bspw. von Roman sieht man, dass da vergleichsweise viel viel Metall übereinander liegt und die Transistoren selbst sehr klein sind. Ob das jetzt über oder unterhalb ist, ist dabei meiner Auffassung nach wenig entscheidend, die Metall Layer leiten je nach Material wahrscheinlich deutlich besser die Energie wie das Silizium drum rum. Sprich die Energie wird über die Metallschichten sehr wahrscheinlich entsprechend breit verteilt und das Silizium hindert (im Vergleich) eher den Energietransport.

Zwei gebondete Chips wie bei X3D sind sehr wohl physisch total unterschiedlich gegenüber einem einzelnen Stück Silizium.

Das ist vollkommen klar und wurde meinerseits auch nicht in Abrede gestellt. Ich stellte allerdings in Frage, ob möglicherweise die Verbindung mit dem Huckepack Cache durch andere Eigentschaften bspw. dazu führen kann, dass das dennoch zu einem guten bis vielleicht sogar besseren Ergebnis führt?

Ich denke/dachte da so ein wenig bildlich gesehen an Kühler mit Heatpipes. Da geht die Energie unten in die Platte rein und wird über vergleichsweise dünne Rohre an großflächige Kühlfinnen transportiert. Ja, klar, ist viel größer, ist ganz andere Ausgangslage usw. Aber im Endeffekt ist es der Effekt auf den ich hinaus wollte -> kann man vielleicht durch entsprechende Produktionsschritte geziehlt die Energie abtransportieren. Bspw. durch Metall Durchkontaktierungen, wo dann über großflächige Bereiche die Energie der unteren Lage Logik "hoch" geführt wird ohne dass sich dabei ein Hitzestau bildet?
Im Endeffekt wie oben erwähnt - innerhalb der Transistorebene im Chip ist das ja jetzt schon so, weil sehr sehr viel Metall mit einem entsprechenden Kupferanteil und dem ~2,5-3x?? so hohen Wärmeleitfähigkeiten zu Silizium ja auch schon für die Verteiliung sorgen.


PS: nimm das alles bitte nicht zu ernst, wir sind hier nicht in einem Wissenschaftsforum wo es auf 100% korrekte Wortwahl und Wasserfeste Argumentation ankommt. Mir fehlt dafür mittlerweiles die Zeit um das so felsenfest zu formulieren - ich schreibe was mir dazu in den Kopf kommt und wenn da mal ein Wort falsch ist, der Sinn aber weiter gegeben ist, dann sieh mir das bitte nach

Ergänzung (8. Oktober 2024)

Dass sich eben schon etwas getan hat, was man ja auch an der Anwendungsleistung sieht, v.a. unter Linux. Und auch die Umgruppierung ist ja ein nicht kleiner Schritt, da darauf dann auch kommende Generation und weitere Zugewinne aufbauen können, vielleicht nun ja auch im X3D-Bereich.

Man muss halt differenzieren - weil ein Teil der Anwendungsleistung kommt durch AVX512 bzw. den dortigen größeren Zugewinn. Das siehst du in Benches, in Games halt nicht.
Deswegen hat sich aber nicht automatisch viel getan. Zudem ich zu Bedenken gebe, das Layout machen normal auch keine Menschen, sondern das macht der Computer. Sprich das was du siehst ist nicht unbedingt etwas, was Fortschritt oder eben besagtes "es hat sich was getan" aufzeigt, sondern einfach das letzte Layout, was der Computer ausgespuckt hat und als das "beste" aus dem ihm gegebenen Parametern ausgesucht hat.

 

[ETI1120]

Ich will mich in Eure Diskussion eigentlich nicht einmischen, aber

Gemeint war, dass die horizontale Ebene nicht identisch sein muss und eben die Metallschichten unterschiedlich "dick" ausfallen können - je nach Prozess(or).

geklaut bei: https://semiengineering.com/breaking-the-2nm-barrier/

Der Aufbau eines Dies von Bump bis zum Wafer.

In dieser Darstellung ist nicht maßstabsgerecht, und wir sind bei modernen CPUs schon lange über 5 Metallierungsebenen hinaus.

Das BEOL sieht bei intel 4 so aus:

https://www.semiconductor-digest.co...ried-and-tested-copper-with-cobalt-liner-cap/

Aber diese Ebenen M0 bis M15 der Metallisierung sind etwas anderes als zwei Silizium Dies, per Hybrid Bonding verbunden werden.

Auf der anderen Seite sollte bei diesen Bildern klar sein, warum die TSVs im CCD sind und die optionalen Cache-Chiplets auf er Rückseite des CCD angebracht werden.

Sprich die Aussage im Artikel (darauf war das ja bezogen), dass eine Lage Cache drauf pauschal hinderlich ist,

Diese Aussage im Artikel ist korrekt. Es ist genau das was AMD erzählt.

Die große Herausforderung beim 3D Stacking ist die Abfuhr der Wärme und das Management der Temperatur im Stack.

In dieser Hinsicht ist die MI300 ein weiterer Schritt weil Logik über Logik bzw. Logik über Cache plaziert wurde. Bei der MI300 haben wir Wassergekühlung was das Kühlen einfacher macht.

muss lange nicht stimmen, weil es der Energie egal ist, durch was sie geht -

Materialien leiten Wärme unterschiedlich gut.

• Silizium besser als Siliziumoxid.
• Das Kupfer in den TSVs besser als das Silizium außen herum.
• Die Kupfer zu Kupfer Verbindung bei Hybrid Bonding erheblich besser als ein Lotverbindung bei Micro Bumps.
• ...

die Summe aller Eigenschaften bestimmt wie gut oder schlecht das funktioniert.

genau und deshalb hat AMD hat bei Zen 3 und Zen 4 das Cache Chiplet nicht über den Kernen platziert.

Ein Layer Logik mit einer Lage Cache drauf kann damit theoretisch auch besser die Wärme abführen als eine Lage Logik ohne Cache, wenn andere Gegebenheiten für schlechtere Wärmeleitfähigkeiten sorgen.

Du übersiehst den großen Elefanten im Raum.

Bei den ganzen Darstellungen von gestapelten Chips darf man nicht vergessen, dass sie die massiv Höhe überzeichnen. Deshalb kann man ohne großen Fehler annehmen dass die Wärmeabfuhr nach oben zum Kühler und auch nach unten über den Sockel erfolgt.

Auch im Cache entsteht Wärme und diese Wärme addiert sich zur Wärme die in der Logik entsteht. Wenn die maximale Wärmeabfuhr konstant ist, verringert jedes Milliwatt das im Cache in Wärme umgesetzt wird das Wärmebudget des Kerns. Außerdem wird die Temperatur in den Teilen des Caches über den Kernen höher sein als über den Teilen des Caches, die sich über Cache befinden.

Natürlich wird man auch diese Anforderung angehen müssen. Aber ist das schon bei Zen 5 der Fall? Wenn sich die TSVs bei Zen 5 ausschließlich im L3 Cache befinden, dann hat AMD das bisherige Vorgehen beibehalten.

Offensichtlich musste AMD an einigen Stellen Neuland beschreiten. Lassen wir uns überraschen wo es passierte.

SRAM skaliert nicht mehr so gut wie Logik. Entweder wird SRAM in ansehbarer Zeit durch eine andere Speichertechnologie, die skaliert, ersetzt ( z.B. MRAM, ReRAM) oder das SRAM muss auf (eine) eigene Ebene(n) verschoben werden.

 

[Convert]

Beim EPYC funktioniert es nicht weil der IOD nicht mit 12 CCD oder gar 16 CCDs per Hybrid bonding verbunden werden kann, es geht rein mechanisch nicht.

Natürlich kann man sich eine Architektur ausdenken bei der man CCDs per Hybrid Bonding auf einen IOD packt aber es kommt kein EPYC raus, der in die SP5 Plattform passt.

Dass 12 CCDs nicht auf den aktuellen IOD passen, ist nun wirklich jedem klar. Darum ging es auch nie. Es ging um einen neuen IOD, der auch Cache integriert hat. Ob man jetzt eine CPU mit Hybrid Bonding nicht SP5-kompatibel hinbekommen kann, weiß ich nicht. Wenn man aus dem neuen IOD alle Leitungen an die gleichen Pins in dem Sockel hin schiebt und alle Versorugungsleitungen von den Sockelpins zu den CCDs durchleitet, wäre es vielleicht möglich. Vielleicht hast du aber recht und es ist nicht möglich. Ja gut, dann haben wir halt einen anderen/zusätlichen Sockel. Ist ja nicht so, als würde sich AMD von einem zusätzlichen Sockel von irgend einem Produkt abhalten lassen. Vor Zen 4 gab es auch weniger Sockel...

Und ohne Plattform taugt eine CPU nichts.

Es gab Spekulationen, dass AMD so etwas bringen könnte, als Konkurrenz zu den Intel Max Series. Ja die Rechnung zeigt dass man damit wie bei Genoa 96 Kerne bereitstellen könnte. Aber es wäre eine Variante der MI300 und kein EPYC. Denn sie passt nicht in SP5, sondern würde in die Plattform der
MI300A passen.

Epyc ist einfach nur der Name der Serverprozessoren bei AMD. Eine MI300 ohne GPUs, sondern nur mit CCDs wäre demnach auch ein Epyc oder "Epyc MAX" oder was auch immer sich das Marketing ausdenkt. Genau so wie bei Intel alle Serverprozessoren Xeon heißen, oder eben Xeon MAX, wenn die auf einen anderen Sockel und mit HBM daher kommen, statt nur mit DDR5.

Das spielt bei der verfügbaren Speicherbandbreite die Rolle.

Wichtiger sind dass das Teil nur 48 PCIe Lanes hätte und beim Speicherausbau ziemlich begrenzt ist. Es wäre eine HPC CPU. Braucht man so etwas?

Warum hätte die CPU nur 48 PCIe Lanes? Wenn ich ein neues IOD baue, dann kann ich auch entscheiden, wie viele PCIe-Lanes ich in das IOD einbaue. Ich hab doch gar nicht darüber gesprochen, dass man schon vorhandene IOD benutzen solle, sondern dass man ein neues IOD mit Cache bauen kann.

Ohne HBM hätte man keinen Hauptspeicher. Die IODs der MI300 haben kein DDR 5 Speicher Interface.

Oh man. Natürlich hat der IOD des MI300 kein DDR5-Controller. Deswegen soll ja auch ein neuer IOD gebaut werden, der statt HBM-Controller DDDR5-Controller eingebaut hat. Oder hast du irgendwo gelesen, dass ich geschrieben habe, man solle den IOD vom MI300 1:1 übernehmen?

Ohne Interposer hast Du gar nichts weil dann die 4 IODs nicht gekoppelt sind.

Jo, deswegen sollte man dann auch nicht 4 IODs nehmen, sondern einen großen. Hab ich was von 4 IODs geschrieben? Nein. Ein IOD mit Cache und Speichercontroller und PCIe, so viele wie man braucht.

Mit einem einzelnen IOD hättest Du eine CPU mit 24 Kernen. Dafür wären die Infinity Links mit denen die anderen IODs angeschlossen werden wieder verfügbar.

Du machst einfach ein IOD, der so groß ist wie vier IODs, und schon kannst du 12 CCDs drauf bauen. Ich verstehe nicht, warum du ständig bereits vorhandene Teile des MI300 verwenden willst. Das Konzept lehnt sich lediglich an MI300 an, aber die Chip-bestandteile sollen nicht aus dem MI300 entnommen werden.

Ich bezweifle, dass es sich lohnt dafür eine Plattform zu entwickeln.

Die Vorteile habe ich genannt. Du hättest einen gemeinsamen L4, so dass du weniger X3D auf dem Chiplet stapeln musst und alle Kerne einer CPU wären über den L4 auch mit einander verbunden und die Effizienz würde steigen, weil die Kommunikation zwischen iOD und Chiplets nicht mehr über den Low-Cost Substrat laufen muss. Du hättest immer noch einen IOD in älterer Fertigungsstufe, aber eben zusätzlich mit Cache. Nachteil wäre, dass der IOD mit dem Cache noch größer wäre, als das aktuelle. Ob sich das rechnet, weiß ich natürlich nicht. Vielleicht lohnt es sich auch tatsächlich eher vier IODs zu nehmen und diese mit "EMIB" (weiß nicht wie das TSMC-Equivalent dazu heißt) mit einander zu verbinden...

 

[fdsonne]

Aber diese Ebenen M0 bis M15 der Metallisierung sind etwas anderes als zwei Silizium Dies, per Hybrid Bonding verbunden werden.

Es hat doch aber auch Niemand behauptet, dass das das gleiche ist!?
Es ging (mir) darum, dass CPUs mehrlagig sind. Wie du schön an deinem eigenen Bild siehst - Und in Summe muss die Wärmeenergie abtransportiert werden. Ob jetzt pauschal ein drauf geklebtes Stück mit Verbindungen die Wärmeübertragung weg vom Hotspot schlechter hinbekommt als der klassische Ansatz ist zwar anzunehmen, aber keinesfalls praktisch und ausschließlich Fakt. Eben weil:

Materialien leiten Wärme unterschiedlich gut.

• Silizium besser als Siliziumoxid.
• Das Kupfer in den TSVs besser als das Silizium außen herum.
• Die Kupfer zu Kupfer Verbindung bei Hybrid Bonding erheblich besser als ein Lotverbindung bei Micro Bumps.
• ...

Exakt das ist doch die Unbekannte dabei - wie viel Metall ist da wie verbunden um vielleicht irgendwelche schlechten Materialübergänge so zu kompensieren, dass das letztlich trotzdem gut aufgeht?

genau und deshalb hat AMD hat bei Zen 3 und Zen 4 das Cache Chiplet nicht über den Kernen platziert.

In der Tat - aber das wissen wir doch?
Die Frage ist, wie im Artikel zu lesen, ob sie das weiterhin so machen. Diese Frage hab ich doch nicht in den Raum gestellt, sondern lediglich gesagt, dass wenn man das nicht so machen würde, letztlich die Umstände entscheiden. Im Artikel steht, dass das pauschal Mist ist. Das ist eine Annahme die auf keinerlei Fakten beruht, weil man alles in der Gleichung variabel und offen hält. Das kann so sein, muss aber nicht.

Auch im Cache entsteht Wärme und diese Wärme addiert sich zur Wärme die in der Logik entsteht.

... auch das sagte ich bereits. Ist das jetzt Absicht erst zu sagen, ich überseh was und dann in Teilen die selbe Aussage zu bringen?

Wenn die maximale Wärmeabfuhr konstant ist, verringert jedes Milliwatt das im Cache in Wärme umgesetzt wird das Wärmebudget des Kerns. Außerdem wird die Temperatur in den Teilen des Caches über den Kernen höher sein als über den Teilen des Caches, die sich über Cache befinden.

WENN, ja wenn das so ist, dann wäre das wie Hätte Hätte Fahrradkette. Versteh mich nicht falsch, aber so funktioniert die Argumentation nicht. Du musst nicht MICH überzeugen, warum das so bisher gebaut wurde, das ist doch klar und auch öffentlich bekannt. Mir ging es darum darauf hinzuweisen, dass das keineswegs der Weisheit letzter Schluss ist und damit geänderte Ansätze möglicherweise Dinge möglich machen, die bisher eben nicht getan wurden. Das Argument mit einem Produkt der Vergangenheit zu belegen und zu sagen, ja wurde so nicht gemacht ist sehr dünn. Weil es eben nicht belegt, warum es so gemacht wurde, sondern lediglich das Resultat zeigt. War es gar nicht möglich? War es lediglich günstiger es so zu machen? Waren andere Parameter dafür verantwortlich? Niemand weis das... Wäre aber notwendig zu wissen um pauschal zu sagen, Cache auf Logik = Mist.

Zudem der zeitliche Aspekt auch im Hinterkopf beibehalten werden sollte. Zen3 war der erste Anlauf für den Huckepack Cache. Zen4 der Zweite. Das sind jetzt 4 Jahre knapp seit Release von Zen3. Gut, der Stapelcache kam später, aber jede Wette, dass das initial in der Planung und im Design mit eingeflossen ist. Vier Jahre ist eine verdammt lange Zeit. Warum spricht man AMD ab, dass die 4 Jahre lang das gleiche machen müssen?

Intel stackt Logik auf Cache bspw. in Ponte Vecchio - das seit mehr als einem Jahr. Und wir wollen uns hier darüber "streiten" ob man das machen kann? Ich versteh das Argument nicht... Machbar ist nahezu alles. Sofern die Probleme in den Griff bringbar sind. Lass(t) uns doch stattdessen über die Probleme und Themen sprechen, die dafür oder dagegen sprechen anstatt am Grundsatz rumdiskuttieren? Das kann eh Niemand hier wirklich belastbar erklären oder belegen.

 

[ETI1120]

@Jan
https://forums.anandtech.com/thread...ranite-ridge-ryzen-9000.2607350/post-41312162

Hans de Vries hat im AnadTech Forum gesagt er hätte weitere 8500 TSVs gefunden.

Wenn dies zutrifft überdeckt das Cache-chiplet den Kern teilweise. Im überdeckten Bereich ist aber einiges an SRAM. Die Strukturen in denen Hans de Vries Power TSVs verortet sind eigentlich ziemlich offensichtlich sichtbar.

 

[Jan]

Artikel-Update: Im Forum von AnandTech will Hans de Vries weitere circa 8.500 TSVs außerhalb des L3-Cache im Zen-5-CCD gefunden haben, die sich sogar über den L2-Cache in den Kernen bis hin in die eigentlichen Recheneinheiten ziehen.

Darauf aufbauende Spekulationen reichen von „damit bedeckt der neue 3D V-Cache-Die also doch einen Teil der Kerne, was in Sachen Kühlung nur ein Desaster sein kann“ bis hin zu „vielleicht wird der 3D-V-Cache-Die bei Ryzen 9000X3D unter und nicht auf das CCD gesetzt“. Das würde bedeuten, dass der neue L3-3D-V-Cache-Chip doch nur den L3-Cache „von unten“ bedeckt und die stomführenden TSVs in den Kernen zur Versorgung der Kerne über ein Substrat darunter dienen. Eine handfeste Idee, wie AMD Ryzen 9000X3D umsetzen wird, haben auch die neu entdeckten TSV noch nicht hervorgebracht.

 

[ETI1120]

Unter dem CCD ist nicht möglich.

Unter dem CCD ist die Metallisierung und dass es nach wie vor TSVs sind, zeigt dass das Cache Chiplet nach wie vor auf der Rückseite (oben) sitzt.

Wäre das CCD oben würde man beim CCD keine TSV sehen.

 

[TenDance]

Ich bleibe gespannt und finde ZEN5 aktuell zwar gut aber er ist eben nicht der Überflieger für den ihn alle gehalten haben vorher ... Hyptrain sei dank ...

Es ist in der Technik oft so dass ein grundlegend neuer Ansatz in seiner ersten "Massenproduktion" noch nicht das ganze Potential ausschöpft weil man sich erst mal darauf konzentriert das ganze wirtschaftlich gangbar zu machen, es also ohne großartigen Ausschuss in die Produktion zu bringen. Der aktuelle Mehrwert ist gering, aber das Potential schon absehbar.

Ein Beispiel hierfür ist zum Beispiel AMDs Fiji (multi-die Ansatz auf einem Interposer inklusive HBM, zwei für damalige Zeiten grundlegend neue Technologien welche derzeit so langsam ihr Potential in der Massenproduktion entfalten respektive wenn es um HBM geht aus Kostengründen nicht im consumer-Markt anzutreffen ist aber ohne den im Bereich HPC derzeit sehr wenig geht) oder auch Intels Broadwell mit aufgesetztem Cache (damals noch ohne TSVs und nebenan, aber quasi ein Vorreiter sogar für Apple Silicon).

https://www.anandtech.com/show/1619...ective-review-in-2020-is-edram-still-worth-it

 

[Cabranium]

wie „findet“ man 8500 Hochauflösende Bilder? Ist ja jetzt nicht so das da irgendwo seine Digicam liegen lässt 😅

 

[LukS]

@Cabranium
Von was redest du?
Die haben weitere 8500 TSVs (Trough Silicon VIAs) auf dem CCD gefunden. Das sind Durchkontaktierungspunkte durch das Silizium.

 

[Nitschi66]

@Cabranium
Wer lesen kann ist klar im Vorteil :-D

 

[FUSION5]

Ich fand zum Zen 5 Release das folgende Interview mit Mike Clark ganz interessant. Da wird dann auch deutlich, dass mit Zen 5 einiges neu gemacht worden als Grundlage für die zukünftigen Generationen.

https://chipsandcheese.com/p/a-video-interview-with-mike-clark-chief-architect-of-zen-at-amd Video + transcript

Another key point I’d like to hit on is it’s also hard for software trying to leverage, let’s say something that has 6 ALUs and 8-wide dispatch, they don’t get the payback when they run it on our older architecture. So even if they’re you know trying to tune their code and building smarter algorithms, there’s no payback for them so they don’t end up doing it. Whereas now that we’ve built it, they’ll start innovating on the software side with it [and they’ll go], “Holy cow look what I can do, I’ll do this, and I can do that” and you’ll see the actual foundational lift play out in the future on Zen 6 even though it was really Zen 5 that set the table for that and let software innovate.