Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsKein Selbstläufer: TSMC N3P kämpft mit Yield, SRAM skaliert auch bei N2 nicht
@Ned Flanders TSMC hält sich (natürlich) sehr bedeckt darüber, wie sie das Stacking und die Die Größen passgenau machen. Spekulatius meinerseits: wird wahrscheinlich mit "leerem" Silizium gemacht. Denn sonst wird's auch mechanisch weniger stabil.
@eastcoast_pete wobei mir unklar ist, wie man das 3D Stacking mit TSVs bewerkstelligen kann, wenn der L3 im CPU Die eine andere Strukturgröße hat als der im Cache Die. Die passen dann ja nicht aufeinander.
Was soll da das Problem sein? Es kommt nur darauf an dass TSV und Pad dieselbe Position bezogen auf den Die Rand oder eine definierte Position auf beiden Dies haben haben.
Die TSV haben einen weit höheren Pitch als die Metallisierung und außerdem muss so oder eine keep out area um den TSV eingehalten werden.
@eastcoast_pete wobei mir unklar ist, wie man das 3D Stacking mit TSVs bewerkstelligen kann, wenn der L3 im CPU Die eine andere Strukturgröße hat als der im Cache Die. Die passen dann ja nicht aufeinander.
Das eine hat mit dem anderen nichts zu tun. Du musst die TSVs halt an den richtigen Stellen platzieren und die Zwischenräume mit dem was du willst auffüllen. Ich glaub ihr habt keine Vorstellung davon wie RIESIG TSVs im Gegensatz zum Rest ist. Das ist wie wenn du mit Lego was baust und dann daneben den Bursh Kalifa. Das eine juckt das andere nicht die Bohne, außer das es halt da steht wo es steht.
Zudem kannst du Pads mehr oder weniger so groß machen wie du willst.
Also von daher da gibt es rein gar nichts. Ist halt full Custom ASIC Design was die da treiben.
SRAM wird nicht nur fuer caches gebraucht, sondern auch fuer die Sprungvorhersage und fuer die physischen Register (ca. 234x512 bits fuer die ZMM-Register des Zen5, also ca. 15KB, plus zusaetzlich Platz fuer Integer-Register etc.).
Das ist vollkommen richtig. Ist nicht zu vernachlässigen gegenüber dem 48 KiB L1 Cache.
240 integer register á 64 Bit => ~1,9 kiB
384 (AVX-512) FP register á 64 Byte => 15 kiB
192 flag register á 64 Bit => 1,5 KiB
Aber gegenüber 1MB L2 und ~32MB L3 Cache spielt der Platzbedarf keine entscheidende Rolle
Wenn es TSMC nicht hinbekommt, dann auf absehbare Zeit wahrscheinlich niemand. Hoffe die bekommen es soweit in fen Griff, dass die Preise nicht exorbitant hoch ausfallen.
Ich habe da mit 234 rename-Registern gerechnet, weil das bei Messungen herausgekommen ist (da muesste man aber wohl noch die 32 Architekturellen Register dazuzaehlen). Andererseits ist die offizielle Angabe 384 AVX-512-Register, das waeren dann 24KB.
Aber gegenüber 1MB L2 und ~32MB L3 Cache spielt der Platzbedarf keine entscheidende Rolle
Wenn man sich einen annotierten Zen 5 die shot anschaut, kostet der L1D (48KB) halb so viel Platz wie der L2 (1MB), vermutlich aufgrund von Multiporting, und die Vector Registers (AVX-512) kosten aehnlich viel wie der L1D cache (noch mehr ports). Das Integer Register file hat auch eine nennenswerte Groesse, und die BTBs und der Rest des Branch predictors auch. Und die 8 Kerne (samt L1 und L2) zusammen kosten doppelt so viel wie die 32MB L3.
Wenn ich mir anschaue, wie die Vektorregister und Vektoreinheiten organisiert sind, kann ich mir auch gut vorstellen, wie es zu dem Messergebnis kam, wo ein Teil der Vektorregister nicht beteiligt war: Wenn der Grossteil auf der einen Seite der AVX-512-Einheiten laeuft, dann werden vielleicht auch die Register auf der anderen Seite nicht allokiert.
Bezüglich Platzbedarfsdiskussion. Ja das kann man nicht einfach 1:1 vergleichen. Durch die kürzeren Zugriffszeiten und eben mehr Ports ist das Zeug in den niedrigeren Stufen massiv größer. Das darf man echt nicht unterschätzen!
SRAM bzw FlipFlops machen schon sehr viel des Platzbedarfes aus. Man muss ja bedenken das in den Pipelines am Ende jeder Stufe auch FliFlops hängen um die Zwischenergebnisse für den nächsten Takt zu speichern.
Edit meint
Und ihr habt keine Vorstellung davon wie riesig solche FlipFlops in den kritischen Pfaden werden können. Die müssen ja teils ziemlich viele weitere Transistoren treiben müssen selbst aber ne möglichst kleine Load darstellen. Dafür gibt es schon gewisse Designkonzepte aber klein und energiesparnd sind die definitiv nicht.
Dann ist ja zumindest AMD auf der sicheren Seite und kann voller Zuversicht
in die Zukunft blicken und so nebenbei Nvidia so eine richtige Breitseite verpassen.
Während AMD Zen 5 sowohl in N4 (8-Kern-CCDs für Ryzen/Epyc) als auch in N3 (16-Kern-CCDs für Epyc) fertigen lässt, ist für Zen 6 nur N2 angekündigt. Die Dense-CCDs machen also einen Node-Sprung, die Classic-CCDs machen zwei.
Während AMD Zen 5 sowohl in N4 (8-Kern-CCDs für Ryzen/Epyc) als auch in N3 (16-Kern-CCDs für Epyc) fertigen lässt, ist für Zen 6 nur N2 angekündigt. Die Dense-CCDs machen also einen Node-Sprung, die Classic-CCDs machen zwei.
Es macht nur bedingt Sinn die cpu weiter zu verkleinern gut den ccx auf 12kerne zu vergrößern bei gleicher Fläche macht Sinn darüber hinaus aber nicht.
mit n2p ist man schon potenziell bis zu 80% kleinere chips bei gleichen design davon nur 30% zu nehmen macht Sinn. und den rest in Takt zugeben zuzüglich den node taktgewinn daher sind die Gerüchte mit 6,8-7,0gh Realistisch.
mehr kerne bringen am desktop nix darum hat man ja dense cores in server chips und nein zen7 wird kein 16 kern ccx haben dass wird lediglich auf a16 mit bspd bis zu 8,3ghz Takt geben
Was auch notwendig ist für die neue Pc Ausrichtung mit vm basis in OS
viel wichtiger ist was man mit den igp macht und man den schritt zu cowop mit getrennten sram geht in gpu.
Das man auf ddr6 camm2 geht steht sicher. Unklar ist die Anbindung ich gehe von dual channel a512bit aus
Womit threaripper und desktop den gleichen sockel bekommen wahlweise mit threadripper bis 128 kernen oder apu 12 kernen bis 8,2ghz 4se a20cu a128alu
beide haben ne maxed tdp von 300w und nee basis igp in I/O die zusätzlich mit 2cu die deaktiv bei desktop ist.
naja sehe ich auch so.Es reichen ja auch 2x12 Kerne als Chiplet aus.Das sind ja dann eh 24 Kerne.Mehr kann man eh nicht erwarten und das mit Intel so viele Kerne ist ja auch ein Gerücht.Mit so vielen Kernen würden sie am Takt verlieren,mehr Kosten haben und weniger Gewinn.Das macht bestimmt keiner mit Verstand.So 16-24 Kerne wird also in Zukunft der Standard im Highend Desktop Markt bleiben.Wer mehr will,der Greift eh zu Xeon oder Threadripper.Das ist doch klar.Dem ist auch die höheren Kosten klar.
Ansonsten kann man zu beiden Herstellern mit weniger Kernen greifen und hätte mehr davon.Das mit dem höheren Takt,mal schauen.Die Abwärme steigt ja mit höheren Takt ebenso.Es sei denn man macht ne Fertigung das auf höhere Takt ausgreichtet ist oder fertig bei AMD und Co extra so das mehr Takt am Ende dabei raus kommt.
