AMD Rome mit 256 MB L3-Cache: Zwei Quad-Core-CCX mit jeweils 16 MB pro Chiplet

[HWL News Bot]

Auf dem New-Horizon-Event stellt AMD seine EPYC-Prozessoren der zweiten Generation vor. Diese werden bis zu 64 CPU-Kerne bieten – verteilt auf acht Chiplets mit jeweils acht Kernen – gefertigt in 7 nm sowie einem zentralen I/O-Chip, der weiterhin in 14 nm gefertigt wird.Die wichtigsten technischen Daten kennen wir aber noch nicht. So ist nicht bekannt, wie AMD das Speicherinterface mit acht Kanälen an die einzelnen Chiplets anbinden wird. Unbekannt ist außerdem die genaue Konfiguration der...

... weiterlesen

 

[fortunes]

Also bleiben sie bei 4C je CCX, wie vermutet. So mussten sie die CCX-Maske nur in die 7nm von TSMC "rüberbringen", was nochmals Zeit und Geld spart.

Da bin ich ja mal gespannt, was das für die kleinen Zen2 bedeutet.

 

[RAZ0RLIGHT]

Entweder habe ich einen Denkfehler oder...

32MB pro Chiplet, was spricht dann gegen einen 8Core CCX... irgendwie verstehe ich nicht, wie man dadurch jetzt schon ableiten kann, dass es wieder genau wie bei Zen 1 sein wird.

 

[Holzmann]

Somit könnte ein L3 Drive in greifbare Nähe rücken.

 

[Don]

Entweder habe ich einen Denkfehler oder...

32MB pro Chiplet, was spricht dann gegen einen 8Core CCX... irgendwie verstehe ich nicht, wie man dadurch jetzt schon ableiten kann, dass es wieder genau wie bei Zen 1 sein wird.

Weil es als 16x 16 MB ausgelesen wird.

 

[Tzk]

Hoffentlich hat AMD dann das Augenmerk auf die Optimierung der bestehenden CCX gelegt, weil sie keine Arbeit ins Ummodeln von 4 auf 8 Kerne pro CCX stecken mussten. Eine Steigerung von mehr als 5% IPC wäre super

 

[l0n]

Das dürfte auf jedenfall interessant werden

 

[Jaimewolf3060]

Hoffentlich hat AMD dann das Augenmerk auf die Optimierung der bestehenden CCX gelegt, weil sie keine Arbeit ins Ummodeln von 4 auf 8 Kerne pro CCX stecken mussten. Eine Steigerung von mehr als 5% IPC wäre super

Damit wäre man fast auf SKL-X/W Niveau oder gleich auf. Und das ist mehr als ausreichend.
Aber wann kann man was für AM4 kaufen.
Egal was man zZ. kauft, sei es Intel oder AMD liegt man falsch.

 

[Holt]

Was von irgendwelchen Tool bei irgendwelchen Prototypen ausgelesen wird, muss noch lange nicht stimmen und wenn ich mit erinnere wie große der zentrale I/O Chip und wie klein die Chiplets sind:

(hier noch besser zu sehen bei Anandtech)

Da hat doch ein Chiplet nur noch so ein Viertel der Größe der Zeppelin Dies:

Dabei haben die Chiplets genau wie die Zeppelin Dies je 8 Kerne und auch wenn der Prozess sich 7nm nennt, so wissen wir doch nur zu gut, dass die Strukturen deswegen noch lange nicht auf ein Viertel der Größe verkleinert werden. Außerdem bekommen die Kerne ja größere AVX Einheiten mit 256Bit, die brauchen auch Platz und ob der Wegfall von I/O Logik (so ganz kann die ja nicht wegfallen, die CCX müssen ja untereinander und mit dem I/O Chip verbunden werden) dann reicht um trotzdem noch den L3 Cache zu verdoppeln? Zeppelin hat ja nur 16MB pro Die, also 2MB pro Kern und 16x16MB wären bei 8 Chiplets dann 32MB pro Chiplet und damit 4MB pro Kern.

So klein ist der L3 Cache (2MB/Kern) im Vergleich schon zur den Kernen von Ivy Bridge auch nicht gewesen:

Und was steckt denn alles in dem I/O Chip, der ja gut und gerne die Größe eines Zeppelin Dies hat? Nicht vielleicht doch der L3 Cache auf den dann alle Kerne gleich fast gut zugreifen könnten, wenn der zentral gehalten wird?

 

[fortunes]

Holt, das werden wir alles sehen, wenn es so weit ist.

An der Stelle zu spekulieren, macht keinen Sinn. Aber 16x16MB Cache spricht zumindest erstmal für das alte CCX-Design, was schon'mal mehr Aufschlüsse gibt. AMD hält an dem alten Design fest, bringt aber den zentralen I/O. Spannung, was das am Ende ausmacht. Wenn es nichts bringen würde, hätte es AMD sicher nicht gewählt. Die Frage ist nur: hat AMD dadurch einen Leistungsverlust aufgrund der Signalwege im InfinityFabric verhindert oder ist das als Verbesserung (Evolution) zu sehen?

 

[Don]

Was von irgendwelchen Tool bei irgendwelchen Prototypen ausgelesen wird, muss noch lange nicht stimmen und wenn ich mit erinnere wie große der zentrale I/O Chip und wie klein die Chiplets sind

Ja, aber schau dir auch mal an, wie groß ein Interconnect-Switch sein kann. Der NVSwitch von NVIDIA kommt auf 2 Milliarden Transistoren und wird in 12 nm gefertigt. In wie weit sich die beiden Chips in ihrer Funktion vergleichen lassen, weiß ich jetzt nicht genau, aber klar ist: So ein Interconnect-Switch kann sehr komplex und damit groß werden.

 

[Gamerkind]

Und was steckt denn alles in dem I/O Chip, der ja gut und gerne die Größe eines Zeppelin Dies hat?

Die I/O-Die ist ca. doppelt so groß wie Zeppelin.

Nicht vielleicht doch der L3 Cache auf den dann alle Kerne gleich fast gut zugreifen könnten, wenn der zentral gehalten wird?

L3 auslagern ergibt keinen Sinn, die Kerne sollen schnell darauf zugreifen können!

Ausserdem wäre die I/O-Die für 256MB L3 eindeutig zu klein

 

[NasaGTR]

Die I/O-Die ist ca. doppelt so groß wie Zeppelin.


L3 auslagern ergibt keinen Sinn, die Kerne sollen schnell darauf zugreifen können!

Ausserdem wäre die I/O-Die für 256MB L3 eindeutig zu klein

Ja und die Chiplets sind für jeweils 16MB L3 Cache noch viel "krasser" zu klein, und das ist dann ja genau das was Holt meinte.

 

[senbei]

Auf 7nm "rüberbringen" ist nicht, da der komplette Die geändert wurde. Aus dem Die wurden die northbridge und southbridge komplett entfernt, da ist bis auf Logik, Cache und IF/CCIX nichts mehr drin. Zen+ hat 213mm² und die Hälfte davon fehlt jetzt -> 213 x 0,5 = 106,5. Der Shrink von 12 auf 7 nm wurde mit 0,5 angegeben, also 106,5 x 0,5 = 53,25. Man nehme 10% für AVX-256 und erhält ~59mm². Die Dies auf den Fotos zu Rome haben 71mm² wenn ich mich recht erinnere. Da bleiben also 12mm² um den L3§ aufzublasen. Sollte reichen.

 

[Gamerkind]

Warum sollten die Chiplets zu klein dafür sein?

 

[senbei]

Sie raffen nicht dass hier nur noch Logik und Cache im Die sind. Würde man die Zen/Zen+ -Dies shrinken käme man auf geschätzt 140mm² was dann der doppelten Größe von Zen2 entspräche.

 

[[HOT]]

7nm ist fast genau 100%-Shrink zu 14nm (etwas mehr zu 16nm). Das I/O-Zeug kann aber nicht 1:1 geshrinkt werden, deshalb ist ja der externe I/O-Constroller ne gute Idee.

Und ich seh das auch so. Der 8-Kerne-CCX ist damit nicht vom Tisch. Entweder es bleibt bei 4er CCX mit jeweils 16MB dann oder es wird 4MB pro Kern.

 

[Gamerkind]

ntweder es bleibt bei 4er CCX mit jeweils 16MB dann oder es wird 4MB pro Kern.

4MB pro Kern wären es aber immer, egal ob 4er oder 8er CCX

 

[Holt]

Wieso sollte "das I/O-Zeug nicht 1:1 geshrinkt werden" können? Der Grund dürfte eher sein, dass es viel teurer ist ein 7nm als einen 14nm (12nm, wie GF seinen optimierten 14nm Prozess nennt) zu fertigen und TMSC sicher nicht endlose Kapazität in 7nm für AMD übrig hat, AMD aber gleichzeitig auch noch Abnahmeverpflichtungen bei GF haben dürfte. Außerdem ist es einfacher und geht schneller wenn man die I/O weiter im gleichen Prozess fertigt, statt sie für einem anderen Prozess neu zu entwickeln und gerad bei I/O muss man eben auch aufpassen das die Dimensionierung der Transistoren passt, sonst geht es wie bei den SATA 3Gb/s Ports von Intels Sandy Bridge Chipsätzen des B2 Steppings.

 

[Gamerkind]

Wieso sollte "das I/O-Zeug nicht 1:1 geshrinkt werden" können?

Weil es einfach so ist, das ist allgemein bekannt!

 

[Holt]

Gamerkind, und wie schafft man dieses angeblich Unmögliche bei den 7nm ARM Server CPUs und SoCs für Mobilgeräte oder bei 7nm GPUs?

 

[RAZ0RLIGHT]

Wurde von AMD schon mehrfach erwähnt, die I/O Komponenten skalieren nicht wirklich mit kleineren Fertigungsgrößen weshalb man sich für den älteren, deutlich günstigeren 14nm Prozess entschieden hat, außerdem kann man so auch die Verträge mit GF einhalten.

 

[unl34shed]

Holt, der limitieren der Faktor sind die BGA Pads bzw. Balls. Die können nicht beliebig verkleinert werden.
Und wenn dein DDR4 IF 10mm2 für die Pins braucht bringt es nichts wenn die Logik nur 4mm2 statt 8mm2 benötigt, du brauchst eh einen 10mm2 Chip.

Also nimmt man den älteren Prozess, der günstiger ist.

 

[Gamerkind]

Gamerkind, und wie schafft man dieses angeblich Unmögliche bei den 7nm ARM Server CPUs und SoCs für Mobilgeräte oder bei 7nm GPUs?

Was soll man da bitte geschafft haben?

 

[Luebke]

Somit könnte ein L3 Drive in greifbare Nähe rücken.

meine erste hdd hatte tatsächlich weniger speicher

 

[Holt]

unl34shed, die Strukturgrößen des Prozesses haben mit den BGA Pads doch nun gar nichts zu tun, man nimmt 14nm für den I/O Chip, weil das günstiger ist und man die Abnahmeverträge mit GF erfüllen muss, aber sonst gibt es dafür keinen Grund. Bei den Energieverbrauch der IF wären 7nm technisch der viel bessere Prozess für diesen Chip gewesen.

 

[Tzk]

Seine Bedenken, das man am I/O Chip nicht genug Fläche hat um alles anzubinden kann ich aber schon nachvollziehen. Immerhin müssen alle AM4 Pins an den I/O Chip und zusätzlich noch die Chiplets angebunden werden. Da kommt schon was zusammen.

Die Hauptgründe werden aber wohl a) die Verträge mit GloFo und b) die nicht lohnenswerte Skalierung des I/O Die auf 7nm sein. Es wird schon was bringen, aber wieviel? Vermutlich nicht genug um 7nm am I/O Die zu rechtfertigen. Man sollte sich bewusst sein, das AMD derzeit möglichst kosteneffizient versucht CPUs zu bauen. Das die dabei noch schnell sind, ist natürlich super.

 

[Gamerkind]

Immerhin müssen alle AM4 Pins an den I/O Chip

Alle nicht, die Chiplets werden wohl zumindest die Stromversorgung noch direkt vom Sockel bekommen.

 

[unl34shed]

unl34shed, die Strukturgrößen des Prozesses haben mit den BGA Pads doch nun gar nichts zu tun, ...

Hab ich was anderes behauptet?
Die BGA Pads bzw. ihre Anzahl geben aber die Chipgröße vor, da es sich (wie seit Jahren Standard) wohl wieder um einen Flip Chip handelt. Und die solderballs demnach mit dem top Metal laser verbunden werden.

 

[Holt]

Seine Bedenken, das man am I/O Chip nicht genug Fläche hat um alles anzubinden kann ich aber schon nachvollziehen.

Die BGA Pads sind unten an der CPU und verbinden diese mit dem Sockel, die gibt also nur die Größe der Trägerplatine der CPU und des Sockels vor und hat nichts damit zu tun wie die Abstände der Verbindungspunkte zwischen dem Die und der Trägerplatine sind.

Immerhin müssen alle AM4 Pins an den I/O Chip und zusätzlich noch die Chiplets angebunden werden. Da kommt schon was zusammen.

Mehr als der Sockel Pins hat plus denen der IF Anbindung des Chiplets auch nicht, sofern AMD überhaupt bei den AM4 Zen2 auf diese Technik setzen wird, dies ist ja noch gar nicht bekannt.

Bei den üblichen 100μm sind das 100 Verbindungen pro mm² Diesize und AM4 hat 1331 Pins, sagen wir also großzügig man bräuchte 2000 Verbindungen für einen I/O Chip für AM4, so wären 20mm² ausreichend, also nicht einmal ein Zehntel der Größe des Zepplin Dies.

Die Hauptgründe werden aber wohl a) die Verträge mit GloFo und b) die nicht lohnenswerte Skalierung des I/O Die auf 7nm sein.

Wenn man sich ansieht wie hoch die Leistungsaufnahme der IF und des Uncore ist, dann denke ich schon das es sich technisch gelohnt hätte den I/O Chip auch in 7nm zu fertigen:

EPYC 7601
..
At low loading, out of a total package power of 74.1W, the IF Power consumes 66.2W, or a staggering 89% ! As we go up through the cores, that 66.2W becomes up to 90W in places, but even at its lowest point, the IF accounts for 50% of the power of the total chip. The cores are barely getting 90W out of the 180W TDP!

Bei EPYC 7601 macht unter Last die Leistungsaufnahme der Kerne gerade die Hälfte der gesamten Leistungsaufnahme aus und nur die Kerner werden durch die 7nm effizienter, der I/O Chip könnte daher bei Rome durchaus die Hälfte der Leistungsaufnahme ausmachen und damit würde es sich sicher lohnen diese Leistungsaufnahme ebenfalls durch ein Fertigungsverfahren zu senken welches eine bessere Effizienz ermöglicht. Bei der nächsten dürfte dies dann wohl auch gemacht werden.

Man sollte sich bewusst sein, das AMD derzeit möglichst kosteneffizient versucht CPUs zu bauen.

Eben und da ist ein 14nm I/O Chip billiger, zumal die Schaltungen ja bisher auch schon für den 14nm Prozess von GF im Zeppelin Die vorliegen, die einzelnen Funktionsgruppen müssen also nicht neu designt, sondern nur neu arrangiert werden.

Hab ich was anderes behauptet?

Ja:

Holt, der limitieren der Faktor sind die BGA Pads bzw. Balls. Die können nicht beliebig verkleinert werden.

Das trifft eben bei CPUs nur auf die Größe der Trägerplatine zu.

Die BGA Pads bzw. ihre Anzahl geben aber die Chipgröße vor, da es sich (wie seit Jahren Standard) wohl wieder um einen Flip Chip handelt.

Und wieder wirfst Du die Verbindung des Dies mit der Trägerplatine und die der Trägerplatine mit dem Sockel durcheinander.