News AMD Ryzen Threadripper: 1950X aus dem Handel hat vier echte 8-Kern-Dies

konkretor schrieb:
Ich verstehe die Aufregung nicht

Der Kunde bekommt das Produkt was beschrieben worden ist

Das hier ist (leider bisweilen "war") ein technisch affines Forum. Es interessiert also der technische Hintergrund und das "wie was warum" hinter dem Produkt.

MichiSauer schrieb:
Ich gehe davon aus, dass die Dummies aus den Außenbereichen der Wafer stammt, wo defektes Silizium nach der Belichtung vorliegen kann.
Das wäre auch nur logisch, um die Wirtschaftlichkeit des Gesamtprozesses zu erhöhen. In der Folge des Gesamtprozesses wird man hier ermitteln, inwiefern ein Chip defekte aufweist.
Natürlich selektiert AMD in einer gewissen weise. Allerdings habe ich nun schon mehrfach gelesen, dass die Yield Rate voll funktionsfähiger CCX sehr gut sein soll. Entsprechend wäre wenig "Abfall" vorhanden. Dieser wird in hohen Stückzahlen von den R3 und R5 aufgenommen (Epyc ist B2 Stepping).
 
@begu: sind die Defekte im I/O-Bereich, dann sind die Dice halt schlicht Schrott. Egal wie gut die Yields sind, es fallen immer Chips an, die nicht in ein Produkt wandern können. Egal wie niedrig man es platziert. 99,9% Verwendung der Chips wie vor kurzem mal irgendwo geschrieben wurde, entspricht sicherlich nicht einer 99,9% Yield-Rate. Durch Verwendung als Abstandshalter könnten diese Zahlen aber halbwegs realistisch sein. Immerhin wird der Abfall ja dann irgendwo verwendet.
 
Shadow Complex schrieb:
... ob ich einfach massiv auf dem Schlauch stehe und einen totalen brainfuck habe oder ob du die dich schlicht geirrt hast(Unwahrscheinlich).

irren ist menschlich, immerhin widersprach die Aussage

Holt schrieb:
Außerdem wird oben die Option 3 x16 + 1 x8 für die PCIe Lanes genannt, aber kein Board hat die und ich wette diese Option gibt es nicht, weil eben ein Die sehr wahrscheinlich nur 1 x16, 1 x8 und 2 x4 hat, man kann aber nicht die beiden x8 der unterschiedlichen Dies zu einem x16 zusammenfassen, weshalb ja eben auch kein Board diese Option anbietet.

der Abbildung, auf die sie sich bezog, wie auch vom Wadenbeisser in #89 hingewiesen wurde - Einsicht wurde da im Nachhinein aber auch vermisst ;)

@ScOuRgE_ - so ganz kann ich deiner Aussage nicht folgen.

ScOuRgE_ schrieb:
Die a und d haben den On-Wafertest bestanden und zeigen eine sehr gute Prognose. [...] Im Package-Test stellt sich heraus, dass Die a einen defekten Speichercontroller oder drei defekte Kerne in einem Cluster hat. Die d hingegen bestätigt die Prognose aus dem On-Wafertest und arbeitet fehlerfrei bei hohen Frequenzen.

Wie kann bei dem Testverfahren eine so große Diskrepanz zwischen dem On-Wafer-Test mit der sehr guten Prognose und dem Package Test entstehen? Solche elementar wichtigen Bausteine für das jeweilige Multi-Chip-Modul-Produkt dürften doch niemals defekt sein bevor der Packaging-Prozess gestartet wird.

Zweiter Punkt wäre folgender: ich stecke in den Mikroelektroniktestverfahren nicht so drin wie du, daher meine Frage: du sagtest, dass der On-Wafer-Test nie so detailliert wäre, wie der Package Test - gilt diese Aussage generell für, sagen wir mal, Packages mit einem Chip oder auch für MCM/MCP? Die Frage zielt dahin, dass AMD für einen gezielten Aufbau der TR Produkte mit dem Einsatz nur zweier funktionsfähiger Zeppelin-Dice ein gesteigertes Interesse daran hätte, dass die On-Wafer Tests so solide und aussagekräftig wie möglich sind. Sind dem Prüfverfahren auf dem Wafer technologische Grenzen gesetzt, die unüberwindbar sind? Besser als sehr gute Prognose hin zu Speichercontroller / drei Cores defekt sollten sie aber schon sein ;)
 
@über mir

Der Package-Test ist immer der entscheidende Test, da er über eine hinreichende Fault-Coverage >99.9999...% verfügt, um eine entsprechende Rejectrate von z.B. 1 ppm zu erzielen. Der On-Wafer Test gewährleistet das nicht, weil er über Nadelkarten auf dem Wafer durchgeführt wird. Aufgrund von Intereferenzen sind hier nur max. Frequenzen von 1 GHz möglich. Wenn dieser Test eine ähnliche Fault-Coverage erreichen sollte, müsste er also auch wesentlich länger durchgeführt werden und ein Test bei Betriebsfrequenz ist nicht möglich. Zudem werden nicht alle Pads kontaktiert. Entscheidend bleiben also immer die Built-in-Self-Tests innerhalb des Package-Tests bei höheren Frequenzen. Deswegen gibt es leider eine Reihe von Fehlern, die im On-Wafer Test nicht erkannt werden können, sondern erst im Package-Test. Wer hier die goldene Lösung findet, muss danach nicht mehr arbeiten ;). Die Beispiele, die ich angeführt habe, sollten auch nur examplarisch das Vorgehen veranschaulichen. Wie gut die Tests sind, ist AMDs Geheimnis, denn Design for Testability macht rund ein Drittel des CPU-Designs aus und ist eine eigene Wissenschaft für sich. Entsprechend kann sich AMD natürlich dafür entscheiden, tatsächlich zwei defekte Dies zu verlöten, aber das dürfte viel Ausfall produzieren. Die Aussage
Auf die Frage, ob für die nicht genutzten Dies im Vergleich zu Epyc letztendlich auch für sich genommen defektes Silizium zum Einsatz kommt, erklärt Prior: „Konzeptionell ist das der richtige Gedanke.“
sagt eigentlich auch schon alles. Schade, dass das Märchen vom unbelichteten Die nicht lange gehalten hat :D.
 
Zuletzt bearbeitet:
Hm, was spräche dagegen, auf das Substrat erst einen Chip zu flippen (ist doch wahrscheinlich BGA, oder?), dann den Test für den ersten Chip durchführen und wenn der erfolgreich ist, das Ganze dem nächsten Bandarbeiter in die ölige spanübersähte Pranke zu drücken? ;)
 
Der Interconnect der Dies muss ebenfalls getestet werden, man bräuchte extra Testautomaten (nichts mit Bandarbeiter ;)), die gezielt den jeweiligen Die kühlen könnten (normalerweise erfolgt der Package-Test mit Heatspreader zur Kühlung) und natürlich ist die Testzeit höher, da man jeden Die einzeln im Package testen muss. Zudem müsste das Substrat mindestens zwei Mal durch den Reflow-Ofen. Da dürfte der Spaß aufhören. Ich verweise jetzt mal für Interessierte auf weiterführende Literatur:

VLSI Test

Essentials of Electronic Testing

flappes schrieb:
Ja dann mach mal, du weißt es ja anscheinend besser als AMD ;-) ;-)

Boah super, dass du dich dazu bereit erklärt hast, für mich Spenden zu sammeln. Ich bräuchte dann ein SP3 Board und einen TR 1950X. AMD hat ja schon durchblicken lassen, dass es für SP3 wahrscheinlich Teile des Microcodes und EFIs veröffentlichen wird. Ich denke daher rührte auch die Angst, die zum Märchen des unbelichteten Dies geführt hat.
 
Zuletzt bearbeitet:
Benji18 schrieb:
@Raucherdackel!
denke die Dies sind ziemlich sicher "verdrahtet" wahrscheinlich ist aber im PCB des chips irgendwo ein cut damit die Kerne nicht funktionieren, denke das AMD diesen Chip durchaus nutzt um eventuell mal einen 32 Kerner zu bringen.
nicht nur eventuell, sondern ganz sicher. Dieser nennt sich Epyc und kommt im Serverbereich und hat "zufällig" den gleichen Sockel, der aber nur anders heisst.

Meine Vermutung, basierend auf zwanzig Jahre Erfahrung AMD CPUs und Boards frisieren (unter anderem S940 CPUs auf S939 Boards, Am2(+) CPUs auf AM3 Sockel und umgekehrt) sagt mir, dass Threadripper und Epyc vom selben Band runterfallen, und da so gut wie kein Unterschied herrscht. Epyc wird hundertprozentig auf TR4 Boards lauffähig sein, ganz einfach weils seit 20 Jahren schon so abläuft bei AMD. Und sollte mechanisch eine Sperre verbaut sein (Kerbe an der Seite des Packages versetzt oder so), kann man die wie üblich entfernen, mit Feilen. Früher gabs Pin rausbrechen, Silberleitlack, Bleistiftmod, usw...
 
Deine Vermutung ist aber falsch, da EPYC schon im neueren B2 Stepping gefertigt wird, während Threadripper noch mit B1 auskommen muss.
 
also mir würde dann ja eine CPU reichen, die 4 halb-funktionierende CCX hat und aber den jeweils vollen Cache, schon hätte man 16c/32t mit 64MB Cache. und da jeder CCX auf DualChannel RAM aufbaut, wäre es dann ja sogar OctaChannel RAM ^^ und das dann mit 3 DIMMs per Channel uiuiui, ein MB nur mit RAM-Slots feinfeinfein!
 
Mega-Bryte schrieb:
also mir würde dann ja eine CPU reichen, die 4 halb-funktionierende CCX hat und aber den jeweils vollen Cache, schon hätte man 16c/32t mit 64MB Cache. und da jeder CCX auf DualChannel RAM aufbaut, wäre es dann ja sogar OctaChannel RAM
Für 16C/32T und 64MB L3 Cache brauchst Du eine CPU mit 4 Zeppelin dies, auf denen jeweils beide CCX teilweise deaktiviert wurden. (also insgesamt 8 kaputte CCX)
 
Ich weiß echt nicht wieso man um dieses thema so ein riesen theater machen muss. Ist doch SHICE egal was da unter der Haube steckt! Hauptsache die nächste Sau, die sie durchs Dorf treiben kann. VÖLLIG uninteressant und sowas von WURSCHT.... echt. Könnte kotzen wie das aufgebauscht wird.
 
Äh, also wenn die Möglichkeit besteht, aus einem TR 1920X durch Aktivierung von jeweils sechs passenden Kernen der vermeintlich toten Dies auf einem SP3 Board einen fehlerfreien 24 Kerner bei 2,3 GHz freizuschalten, hat man damit mal eben 1800€ gespart. Deswegen sind dadrunter ja auch unbelichtete Dies ;).
 
hmm so was ähnliches hatten wir doch schon mal beim Phenom...
solange sie nicht aufgrund der hohen Nachfrage intakte Chips raushauen/drauf- müssen...
 
fehlen ja ein paar SMD Bausteine auf dem Die oder seh ich das falsch? Dachte auch zuerst, dass es sowas wie der Phenom II X4 ist, dessen 6MB L3 Cache auch verdächtig danach rochen, dass es eigentlich ein 6 Kerner ist.
hätte ja fast sinn gemacht, wenn man pro DIE ein paar Kerne deaktiviert dafür aber mehrere Dies verbaut.
 
Das Märchen vom unbelichteten Die hat nicht AMD erfunden sondern die versammelte IT Presse.
AMD hat die Teile immer nur Dummys genannt , den Rest hat die Presse hinein interprtiert
 
Raucherdackel! schrieb:
nicht nur eventuell, sondern ganz sicher. Dieser nennt sich Epyc und kommt im Serverbereich und hat "zufällig" den gleichen Sockel, der aber nur anders heisst....kann man die wie üblich entfernen, mit Feilen. Früher gabs Pin rausbrechen, Silberleitlack, Bleistiftmod, usw...

man sieht auf den Bildern ohne HS das SMD Bausteine am Rand fehlen an den Stellen wo vermutlich die "Dummy-Cores" sitzen, so einfach wird das nicht sein.. es ist aber wahrscheinlich schon so das Epyc und TR vom selben Band rollen.. und das immer 4 Cores verbaut werden und bei bedarf ein TR „kastriert“ wird... der Aufwand extra 2 defekte DIEs zu selektieren und zu verlöten ist irrsinnig und nicht wirklich vorstellbar.. Wahrscheinlich ist es billiger gleich zu kastrieren!

AMD mag sich aber nicht gern in die Karten schauen lassen... :rolleyes:
 
incurable schrieb:
Für 16C/32T und 64MB L3 Cache brauchst Du eine CPU mit 4 Zeppelin dies, auf denen jeweils beide CCX teilweise deaktiviert wurden. (also insgesamt 8 kaputte CCX)

da muß ich mal mathematisch einhaken: wieso 8 kaputte? können doch auch einfach nur vier von der 8core-Variante sein (Name?) und davon jeweils die Hälfte deaktiviert, also quasi ein halbgarer Epyc, bei dem auf jedem Die die Hälfte futsch ist! Korrigier mich, aber ein Threadripper besteht laut hiesigen Aussagen aus zwei funktionierenden CCX und zwei Dummies. Die beiden funktionierenden machen jeweils DualChannel und der ganze Prozessor outet sich nach außen wie ein zwei-Knoten-NUMA-System. Zumindest habe ich das so in der ct als Funktionsbeschreibung gelesen (ct 18, wenn ich nicht irre).

wenn ich demnach nicht zwei ganze und zwei dummies habe sondern vier halbgare, dann steigert das doch eigentlichden Cache, da der freigeschaltete Cache eines CCX in voller Höhe den verbleibenden Cores zusteht. wenn dann der gesamte Cache pro Die mit 16MB angegeben ist, habe ich im besten Fall 64 MB bei 4 halbgaren Dies und je nach Defekt nur noch 4 CCX a 4 ganzen kernen ODER 8 CCX a zwei funktionierenden Kernen, da es ja immer symmetrisch sein soll.
 
Im "Normalfall" werden defekte DIES gerade zu Beginn eines Fertigungsprozesses gegenüber der Konkorruenz nicht erwähnt, oder zumindest etwas diskreter behandelt, da diese Informationen für die Konkurrenz, möglichkeiten zur Einschätzung der wirtschaftlichkeit eines Halbleiterproduktes und Fertigungsprozesse geben kann.

Dies gilt es zu vermeiden.
Sicher könnte man nun alle RyZen und Threadripper auseinannder nehmen und nachsehen, doch die Wahrscheinlichkeit, dass dies jemand macht oder sich gar leisten kann/ möchte ist so gering, dass bei einigen wenigen "unter die Haube sehen" keine Rückschlüsse in ausreichendem Maße daraus gezogen werden können, ob das wirklich bei einem erheblichen teil der Produkte so umgesetzt wird bzw. werden muss.

Warum trotzdem belichtet, wurde bereits diskutiert und mit sachlichen Gedanken dazu bereichert.
 
Love Guru schrieb:
habe ich im besten Fall 64 MB bei 4 halbgaren Dies und je nach Defekt nur noch 4 CCX a 4 ganzen kernen ODER 8 CCX a zwei funktionierenden Kernen, da es ja immer symmetrisch sein soll.
Der L3 Cache ist Teil eines jeweiligen CCX, wenn 8x 8MB L3 Cache vorhanden sein sollen, müssen alle 8 CCXs der vier dies zumindest teilweise aktiv sein.
 
Zurück
Oben