AMD Zen 2 und Rome – was wir bisher wissen

Die kom­men­de CPU-Archi­tek­tur Zen 2 wird AMD zuerst im für 2019 geplan­ten Ser­ver-Pro­zes­sor Epyc “Rome” ein­füh­ren. Das macht Sinn, da die Ser­ver-Platt­form den Zwi­schen­schritt “Zen+” über­sprun­gen hat, der uns 2018 die in vie­len Details ver­bes­ser­ten Ryzen 2000 CPUs beschert hat. Kürz­lich hat­te AMD ja, wie berich­tet, offi­zi­el­le Infor­ma­tio­nen zu Rome ver­öf­fent­licht, aller­dings auch vie­le Details aus­ge­spart. In der Zwi­schen­zeit sind in der Gerüch­te­kü­che jedoch eini­ge Info­schnip­sel dazu­ge­kom­men, die wir nicht uner­wähnt las­sen wol­len.

Zen 2 und Rome – was AMD bis­her offi­zi­ell ver­ra­ten hat
Auf der in San Fran­cis­co abge­hal­te­nen “Next Hori­zon” Prä­sen­ta­ti­on hat AMD den Vor­hang gelüf­tet. Der Ser­ver-Pro­zes­sor Epyc “Rome” im Spe­zi­el­len wird wie schon der aktu­el­le Nap­les ein Mul­ti-Chip-Design wer­den. Aller­dings geht AMD bei Rome noch einen Schritt wei­ter und rea­li­siert die CPU nicht mit iden­ti­schen Dies, son­dern trennt Rechen­ein­hei­ten und I/O. So wird Rome aus bis zu 8 Com­pu­te-Chip­lets bestehen, die je 8 Ker­ne auf­wei­sen, sowie aus einem I/O-Chip.

Wäh­rend die eigent­li­chen Rechen-Chip­lets in 7 nm bei TSMC gefer­tigt wer­den, kommt der I/O-Chip nach wie vor in 14 nm daher. Der Sinn dahin­ter ist, dass vie­le Kom­po­nen­ten im I/O-Bereich nicht so sehr von der Schrump­fung der Fer­ti­gung pro­fi­tie­ren und daher bes­ser im güns­ti­ge­ren 14-nm-Ver­fah­ren pro­du­ziert wer­den kön­nen. Zudem wird AMD sicher­lich nach wie vor Abnah­me­ver­trä­ge mit sei­ner ehe­ma­li­gen haus­ei­ge­nen Fab (jetzt Glo­bal­Found­ries) haben, die auf die­se Wei­se erfüllt wer­den kön­nen, obwohl die eigent­li­chen Zen-2-Dies bei TSMC in 7 nm pro­du­ziert wer­den. Kom­mu­ni­ziert wur­de auch, dass AMD mit Rome PCI-Express 4.0 ein­füh­ren wird (sofern das Main­board es unter­stützt), es bei acht Spei­cher­ka­nä­len bleibt (DDR4 logi­scher­wei­se, da DDR5 noch nicht ein­ge­führt wur­de) und die zwei­te Genera­ti­on der soge­nann­ten Infi­ni­ty Fabric zum Ein­satz kommt, also der Kom­mu­ni­ka­ti­ons­pfad zwi­schen den ein­zel­nen Ker­nen, die sich nicht im sel­ben Seg­ment befin­den.

Auch zur Zen-2-Archi­tek­tur als sol­cher wur­den Details genannt, wie etwa die ver­bes­ser­te Exe­cu­ti­on Pipe­line, die ver­bes­ser­te Sprung­vor­her­sa­ge samt Pre­fet­ching, der opti­mier­te Befehls­cache, ein grö­ße­rer Op-Cache und – ganz wich­tig – die dop­pelt so brei­te FPU, die nun 256 Bit in einem Rutsch ver­ar­bei­ten kann statt zwei Mal 128 Bit nach­ein­an­der. Dazu wur­de auch die Load-/Sto­re-Band­brei­te ver­dop­pelt. Zudem hat AMD ver­spro­chen, dass Gegen­maß­nah­men zu den Sicher­heits­pro­ble­men der Spec­t­re-Fami­lie per Hard­ware getrof­fen wur­den.

Die ers­ten Main­boards für Rome
Inter­es­san­ter­wei­se hat AMD auf der “Next Horizon”-Präsentation nicht expli­zit den Sockel SP3 erwähnt. Zur Markt­ein­füh­rung des Nap­les hat­te AMD aller­dings betont, dass der Sockel SP3 über Jah­re die desi­gnier­te Ser­ver-Platt­form blei­ben wird. Damit dürf­ten auch CPU-Upgrades per Drop-In-Repla­ce­ment mög­lich sein, sofern Main­board-Her­stel­ler ihre Nap­les-Pla­ti­nen per BIOS-Update fit für Rome machen. In der Zwi­schen­zeit hat Giga­byte ein Main­board für Rome gezeigt, das neben der Beschrif­tung “PCIe Gen 4” auch expli­zit “SP3” als Sockel ein­gra­viert hat.

Der Die-Auf­bau und die Caches
Offi­zi­ell sagt AMD bis­her nichts dazu, aber bereits vor über einem Jahr ging das Gerücht um, dass AMD bei Rome die Kern­an­zahl ver­dop­peln und die L3-Cache­grö­ße ver­vier­fa­chen wird. Die Ver­dop­pe­lung der Kern­an­zahl ist tat­säch­lich so ein­ge­tre­ten, sodass die Gerüch­te zur vier­fa­chen Cache­grö­ße (bzw. Ver­dop­pe­lung je Kern) nicht aus­zu­schlie­ßen sind.

Ver­gan­ge­ne Woche ist ein Ein­trag in der SiSoft­ware-Daten­bank auf­ge­taucht (inzwi­schen wie­der ver­schwun­den), der von einem Rome Engi­nee­ring-Sam­ple stam­men soll.

Das Engi­nee­ring-Sam­ple mit der Bezeich­nung 2S1404E2VJUG5_20/14_N soll 64 Ker­ne auf­wei­sen, die mit 1,4 GHz getak­tet sind. Das wäre selbst für ein Engi­nee­ring-Sam­ple recht wenig. Aller­dings kann natür­lich sein, dass AMD ange­sichts der über­bor­den­den Anzahl an Ker­nen den Basistakt betont nied­rig ansetzt um inner­halb der für SP3 übli­chen TDP zu blei­ben, und dann bei den fina­len Sam­ples den Rest per Tur­bo erle­digt. Das ist auch bei unse­rem Nap­les im Pla­net 3DNow! Web­ser­ver so. Der hat einen Basistakt von nur 2,4 GHz, läuft aber prak­tisch durch­ge­hend im Tur­bo­mo­dus um 2,8 GHz her­um, selbst dann, wenn man künst­lich alle Ker­ne belas­tet.

Inter­es­san­ter als der Takt, der sich natür­lich noch ändern kann und wird bei den fina­len Pro­duk­ten, ist die Anga­be zum Cache: 16x 16 MB L3-Cache steht dort. Zum einen wären das 256 MB und damit wirk­lich vier­mal so viel wie bei Nap­les, wo maxi­mal 64 MB L3-Cache bereit­ste­hen. Zum ande­ren sagt auch die Anga­be “16x” eini­ges über den Chip­auf­bau aus, sofern San­dra die Archi­tek­tur kor­rekt aus­ge­le­sen hat. Da AMD bereits kom­mu­ni­ziert hat, dass Rome aus acht Zen-2-Dies bestehen wird, wür­de der Umstand, dass der L3-Cache aus 16 Seg­men­ten besteht, dar­auf hin­deu­ten, dass jedes Zen-2-Die – so wie bei Zen 1 – aus zwei CCX bestehen wird. Also kein homo­ge­nes 8-Kern-Die mit glei­chen Zugriffs­zei­ten für alle Ker­ne, son­dern wei­ter­hin zwei CCX mit je 4 Ker­nen, die via Infi­ni­ty Fabric zusam­men­ge­schal­tet sind. Nur, dass jeder CCX dann 16 MB L3-Cache haben wird statt nur 8 MB wie bei Zen 1.

Was steckt im I/O-Die?
Wie erwähnt hat AMD die für I/O zustän­di­gen Kom­po­nen­ten bei Rome in einen eige­nen Chip aus­ge­la­gert. I/O wird bedeu­ten: Memo­ry-Con­trol­ler, PCI-Express Con­trol­ler, aber bei einem SoC wie Epyc auch SATA-Con­trol­ler, USB-Con­trol­ler, even­tu­ell auch Netz­werk-MACs oder gan­ze Netz­werk-Con­trol­ler. Das wur­de aber noch nicht ver­ra­ten.

Und trotz­dem. Sieht man sich das Die auf den gezeig­ten Fotos an, dann ist der Chip nur dafür zu groß; erheb­lich zu groß. Der Groß­teil eines her­kömm­li­chen Dies wird ohne­hin vom Cache belegt. Das sind die auf Dieshots gleich­for­mig erschei­nen­den Berei­che, in denen die SRAM-Zel­len für die Caches lie­gen. Unter­stellt man, dass auch bei Zen 2 die L3-Caches mög­lichst nahe bei den Ker­nen (also in den Chip­lets) plat­ziert wer­den, wes­halb ist dann der I/O-Chip so rie­sig? Dazu schweigt sich AMD lei­der noch völ­lig aus.

Denk­bar wäre, dass AMD zusätz­lich zu den L3-Caches, den jedes der 8 Chip­lets besitzt, noch eine wei­te­re Cache­s­tu­fe vor­ge­se­hen hat, dem­nach einen L4-Cache, der dann im I/O-Chip ste­cken könn­te. Qua­si wie frü­her bei den Sockel-7-Board, wo zusätz­lich zu den On-Die-Caches noch ein Cache auf dem Main­board plat­ziert war; hier dann eben nicht auf dem Main­board, son­dern auf dem Chip­trä­ger. Doch ist das wahr­schein­lich? Bei einem Pro­zes­sor, des­sen L3-Cache ohne­hin schon ver­vier­facht wur­de? Zudem hat San­dra kei­nen L4-Cache aus­ge­le­sen (was aber nichts hei­ßen muss, da San­dra sicher­lich noch kei­ne Rome-Unter­stüt­zung hat­te).

Eben­falls denk­bar wäre, dass der L3-Cache nicht mehr in den Chip­lets steckt, son­dern im I/O-Chip plat­ziert wur­de. Dann wür­de des­sen Grö­ße ange­sichts von 256 MB L3-Cache pas­sen und AMD kann sie ja in Sli­ces a 16 MB orga­ni­siert haben. Aber müss­ten dann nicht die Chip­lets wesent­lich klei­ner sein, wenn sich dort kein gro­ßer L3-Cache mehr befin­det? Eigent­lich schon. Aller­dings muss bedacht wer­den, dass AMD die FPU von 128 auf 256 Bit auf­ge­bohrt hat. Man erin­ne­re sich an die Umstel­lung von K8 auf K10, als AMD von einer 64 auf eine 128 Bit FPU ging, wie sehr das den Bereich der Ker­ne auf­ge­bläht hat obwohl (oder weil) die Fer­ti­gung mit 65 nm gleich geblie­ben war. Die neue 256-Bit-FPU bei Zen 2 gibt es sicher­lich nicht umsonst. Ob die­se allein aller­dings erklä­ren kann, dass die Chip­lets so groß sind wie sie sind?

Der Inhalt ist nicht verfügbar.
Bitte erlaube Cookies, indem du auf Übernehmen im Banner klickst.

Über all das kann natür­lich in unse­rem Spe­ku­la­ti­ons­be­reich im Forum dis­ku­tiert und debat­tiert wer­den.