Infos über K8L

Jungs, nicht offtopic werden, das ist hier nicht der xbox G5 Thread

Also back to topic mit der Frage an @dresdenboy:
Wo hast Du Dein nettes Avantar her ? Gibts das auch irgendwo größer ?

Scheint mir bisher entgangen zu sein ...

ciao

Alex

Opteron schrieb:

Also back to topic mit der Frage an @dresdenboy:
Wo hast Du Dein nettes Avantar her ? Gibts das auch irgendwo größer ?

Scheint mir bisher entgangen zu sein ...

Zum Vergrößern anklicken....

Du brauchst nicht an dir zu zweifeln - ich habe das erst heute vormittag geändert Quelle: geheim, bzw. in den EXIF-Daten *g* Es fand nun auch schon hier Verwendung in einem frischen RWT-Thread, wo jemand im Startposting - wahrscheinlich aus bekannten Architekturschemata u. solchen aus AMD-Patenten - eine zukünftige AMD-Architektur gezeichnet hat.

Dresdenboy schrieb:

Du brauchst nicht an dir zu zweifeln - ich habe das erst heute vormittag geändert

Zum Vergrößern anklicken....

Gut, dann bin ich ja beruhigt und frag auch nicht weiter, wo es herkommt Hoffentlich ist da kein Wasserzeichen drin, sodass Deine Quelle nachvollzogen werden kann...
Aber gut zu sehen, dass es mittlerweile "handfestes" Silizium gibt, da erhöhe ich meine persönliche "Rev.H - Mitte 2007" Wahrscheinlichkeit entgültig auf 100%

Edit:
Hmm, wenn man das Bild genau anschaut, stellt man fest, dass es nicht genau dem Foto von der Präsentation entspricht. Die unteren beiden cores sind beim Präsentationschema an der "xbar zu den oberen 2 cores gespiegelt". D.h. die FPUs liegen immer aussen. Bei dresdenboys Bild liegen die FPUs der unteren beiden Kerne aber an der xbar, anstatt aussen am Rand. Fragt sich, wo der Fehler liegt .. hat AMD das Design geändert oder damals im Juni ein Azubi das Präsentationsphoto mit viel Unwissen und Photoshop angefertigt ?

Edit2: Würde eingentlich Sinn machen, dass der I-Cache an der xbar liegt, von daher zweifle ich jetzt leider eher dresdenboys Bild an.

Edit3: Wird immer besser, die ursprüngliche Presentation auf der SPF entspricht dresdenboys Foto:
http://www.heise.de/bilder/73197/0/1

Fazit: War wohl doch ein Praktikant beim Analyst Day am Werkeln ?
Edit4: Jetzt ist alles klar, dresdenboy hat selbst Photoshop benützt, ist ja laaangweilig

Allerdings stellt sich die Frage, wie das passieren konnte, dass AMD selbst 2 "unterschiedliche" cores zeigte. Sachen gibts ...

ciao

Alex

Armer Alex Gleich zur Aufklärung: Es ist nicht echt.

Aber das Bild von Heise ist interessant. So, nun schau nochmal genau auf meinen Avatar *g* PS: Erinnerst du dich an meinen Avatar mit einem K8 mit 512 kB L2?

Dresdenboy schrieb:

Armer Alex Gleich zur Aufklärung: Es ist nicht echt.

Aber das Bild von Heise ist interessant. So, nun schau nochmal genau auf meinen Avatar *g* PS: Erinnerst du dich an meinen Avatar mit einem K8 mit 512 kB L2?

Zum Vergrößern anklicken....

Stimmt da war ja mal was. Du böser Bube, Du
Aber immerhin haben wir jetzt das Geheims des Codenames "K8L" gelüftet. Das steht für "Links" und wurde auf der SPF gezeigt. Auf dem Analystday wurde dagegen das K8R design präsentiert

*duck und wegrenn*

Alex

@Opteron: Der war gut

Ok, back to work:
Romus@SI hat etwas Hübsches entdeckt:
http://www.ixbt.com/editorial/amd-guiseppe-amato-conf-part1.shtml (engl.)
http://www.ixbt.com/editorial/amd-guiseppe-amato-conf-part2.shtml (engl.)

Infos u. Slides aus der AMD-Konferenz, aus welcher schon etwas zur Verfügbarkeit des K8L im Q2/07 zitiert wurde. Es soll demnach wohl auch QC-Athlon-FX geben. Natürlich gibt es dort noch viel mehr zu erfahren Z.B. wird der L3-Cache wohl eine Art "not exclusive" Cache darstellen u. L1/L2 bleiben wie gehabt exklusiv. Der Quadcore Die Plot wird jetzt übrigens so überschrieben, als gäbe es nur diese Quad-Core-Architektur, welche übrigens für den Opteron "Barcelona" heißt

.

Opteron schrieb:

Allerdings stellt sich die Frage, wie das passieren konnte, dass AMD selbst 2 "unterschiedliche" cores zeigte. Sachen gibts ...

Zum Vergrößern anklicken....

Also rein von der Logik her macht doch ein gespiegeltes Die mehr Sinn, oder? Ich mein, an die Xbar müssen doch von allen Cores die gleichen Elemente angeschlossen werden... Daher denke ich dass dieser Plot der richtige is: http://www.ixbt.com/editorial/amd-guiseppe-amato-conf/100-enl.png

Wenn man doch nur Russisch lesen könnte.

Sonic schrieb:

http://www.ixbt.com/editorial/amd-guiseppe-amato-conf/100-enl.png

Zum Vergrößern anklicken....

Der Link tut es leider nicht!

Captn-Future schrieb:

Wenn man doch nur Russisch lesen könnte.

Der Link tut es leider nicht!

Zum Vergrößern anklicken....

Wahrscheinlich gibt es da einen Referrer-Check. Direkt vom Artikel aus lässt sich das Bild aufrufen. Evtl. geht auch das Kopieren u. direkte Einfügen in die URL-Zeile.

Und wenn der Translate-Service nicht mehr geht (meine "engl."-Links), versuch mal http://babelfish.altavista.com/

Dresdenboy schrieb:

http://www.ixbt.com/editorial/amd-guiseppe-amato-conf-part1.shtml (engl.)
http://www.ixbt.com/editorial/amd-guiseppe-amato-conf-part2.shtml (engl.)

Zum Vergrößern anklicken....

Interessant, mal schauen, ob auch noch ein englischer Bericht auf http://www.digit-life.com folgt. Die Sache mit dem "non-exclusive" L3 war ja eigentlich klar, das Teil soll ja auch core to core Kommunikation abfangen, das ginge mit einem exclusive Cache recht schlecht .. Insgesamt ist das aber wg. dem Multicore Ansatz ein neuer Ansatz, wie schrieb schon David Kanter:

...and the L3 cache is certainly not inclusive (although this does not mean it is exclusive)

Zum Vergrößern anklicken....

Sonic schrieb:

Also rein von der Logik her macht doch ein gespiegeltes Die mehr Sinn, oder? Ich mein, an die Xbar müssen doch von allen Cores die gleichen Elemente angeschlossen werden... Daher denke ich dass dieser Plot der richtige is:

Zum Vergrößern anklicken....

Ja klar, macht das Sinn, dass der Instruction Cache in xbar Nähe liegt, ansonsten gäbe es wohl dicke Timing Probleme, wenn die Daten für die "unteren" 2 cores erst mal quer über das Die übertragen werden müssten.

Captn-Future schrieb:

Wenn man doch nur Russisch lesen könnte.
Der Link tut es leider nicht!

Zum Vergrößern anklicken....

Ja wie schon erwähnt, mit etwas Glück gibts demnächst die englische Version auf digit-life. Ausserdem hat bokill @Orthy.de vielleicht auch noch einen Bericht dazu in Arbeit, zumindest war er bei nem "AMD event", wird wohl der gleiche gewesen sein.
Wegen dem "defekten" Link, habs mal anderweitig hochgeladen:



Gleiche Folie, wie beim Analyst Day, nur Hypertransport 3.0 fehlt, was ja schon früher aufgefallen war.

Abgesehen davon, ist der Dieshot von der russischen Seite etwas besser, und man erkennt am "Anfang" der xbar, gleich nach dem L3 Cache, eine gleichmäßige Struktur, die wie Cachezellen ausschauen. Bleibt die Frage, was das in der xbar soll. Falls es L1 Zellen sind ist die Größe ca. auch um die 64kB, falls es schon die dichteren L2 Zellen sind, wäre der Puffer noch größer, ca. 400 kB.

Vielleicht ist es auch irgendwas unwichtiges, Antihyperthreading oder trace cache ist es auf alle Fälle bestimmt nicht
Ist mir nur gerade aufgefallen. Der neue AMD mobile core hat ja auch noch eine schwarzes Viereck auf den Die Plots. Falls das dann ebenfalls Cache Strukturen sind,
ist das wohl Teil des neuen XBar designs.

ciao

Alex

Dresdenboy schrieb:

Z.B. wird der L3-Cache wohl eine Art "not exclusive" Cache darstellen u. L1/L2 bleiben wie gehabt exklusiv.

Zum Vergrößern anklicken....

Was da zum L3-Cache steht, ist reine Spekulation. Die wissen es einfach nicht. Ich halte es nicht für unmöglich, daß der L3 auch exclusiv wird. Sonst bietet der einfach zu wenig Vorteile. Die Zugriffe auf Daten aus den anderen L2s könnte man auch viel günstiger mit einer Art gemeinsamen L2 Tags abfangen (oder einfach Zugriff auf die "fremden" L2 Tags bevor man zur SRQ geht), da muß man keine 2MB L3-Cache draufhauen, wo praktisch auch nur das gleiche drinsteht wie in den L2s.
Die Caches, die weder inklusiv noch exklusiv sind, heißen ja deshalb auch meistens "non-inclusive", weil sie eben immer noch "fast inklusiv" arbeiten. Bei den Intel-CPUs zerstört nur der Prefetch in den L2 die Inklusivität. Bei den weit weniger aggresiven Prefetch-Mechanismen von AMD wäre der L3 praktisch inklusiv.

Opteron schrieb:

und man erkennt am "Anfang" der xbar, gleich nach dem L3 Cache, eine gleichmäßige Struktur, die wie Cachezellen ausschauen. Bleibt die Frage, was das in der xbar soll.

Zum Vergrößern anklicken....

Snoop-Filter?!? Da wird gespeichert, welche CPU welche Speicherbereiche im Cache hat, damit in größeren Multi-Sockel-Systemen nur ein Request an eine bestimmte CPU nötig ist und kein Broadcast an alle.

Gipsel schrieb:

Snoop-Filter?!? Da wird gespeichert, welche CPU welche Speicherbereiche im Cache hat, damit in größeren Multi-Sockel-Systemen nur ein Request an eine bestimmte CPU nötig ist und kein Broadcast an alle.

Zum Vergrößern anklicken....

Möglich ... dann stellt sich wieder die Frage, was der für 2008 angekündigte Probe Filter ist. Naja vielleicht ist er ja bis dahin deaktiviert

Dazu noch Neues von Inquirer:

http://www.theinquirer.net/default.aspx?article=34433

Kurzfassung: Es gibt 2 QuadCore Kerne, sie Unterscheiden sich aber nur im Hypertransport. Der 2007er QC hat bleibt bei HT2.0, die 2008er Chips folgerichtig HT 3.0

ciao

Alex

Kurzfassung: Es gibt 2 QuadCore Kerne, sie Unterscheiden sich aber nur im Hypertransport. Der 2007er QC hat bleibt bei HT2.0, die 2008er Chips folgerichtig HT 3.0

Zum Vergrößern anklicken....

Was soll das für einen Sinn haben? Oder hat man Probleme mit HT 3.0?

Wenn es doch so kommt, ist es sicher blöd. Denn der AM2-Quad-Core passt dann auf ein AM3-Board, aber er wird wegen dem fehlenden HT3.0 wahrscheinlich nicht so gut sein wie sein CPU-Kollege mit HT3.0

aylano schrieb:

Wenn es doch so kommt, ist es sicher blöd. Denn der AM2-Quad-Core passt dann auf ein AM3-Board, aber er wird wegen dem fehlenden HT3.0 wahrscheinlich nicht so gut sein wie sein CPU-Kollege mit HT3.0

Zum Vergrößern anklicken....

HT3.0 ist nur wichtig für Mehrprozessorsysteme. In Desktopboards ist so ein HT Kanal vergleichsweise wie das Nildelta breit aber es dröppeln nur Wassermengen in Größenordnungen des nächsten Dorfbaches durch

Eventuell wurde HT3 aufgeschoben, da Sun auch auf den HT Zug aufspringt, aber noch ein paar Änderungswünsche hat. Eventuell gibts dann 2008 auch wieder einen neuen Sockel, aber das weiss im Moment keiner, ausser die AMD Leute (und eventuell die Sun Kollegen )

ciao

Alex

Opteron schrieb:

Möglich ... dann stellt sich wieder die Frage, was der für 2008 angekündigte Probe Filter ist. Naja vielleicht ist er ja bis dahin deaktiviert

Zum Vergrößern anklicken....

Du hast ihn doch gestern erst in der XBar entdeckt

Im Ernst: Noch weiß man es nicht. Aber es sieht nach Snoop Filter aus. Ergibt aber bei HT 3.0 erst recht Sinn, bei so vielen möglichen Sockeln und vor allem: cacheline-event-verursachenden Cores.

aus: http://www.computerbase.de/news/hardware/prozessoren/amd/2006/august/amd_opterons_sockel_f/

Opteron schrieb:

Eventuell wurde HT3 aufgeschoben, da Sun auch auf den HT Zug aufspringt, aber noch ein paar Änderungswünsche hat. Eventuell gibts dann 2008 auch wieder einen neuen Sockel, aber das weiss im Moment keiner, ausser die AMD Leute (und eventuell die Sun Kollegen

Zum Vergrößern anklicken....

Es könnte ja bei der I/O-Virtualisation noch Abstimmungsbedarf bestehen / bestanden haben.
Der jetzige K8L ist ja schon seit Wochen fertig, während die bei HTr3 noch nicht der Fall ist.

Die rein elektrischen Daten, bzw. ob z.B. der So.F die nötigen Taktraten und HF-Eigenschaften dafür hat, dürfte aber umgesetzt sein,

Es könnte ja bei der I/O-Virtualisation noch Abstimmungsbedarf bestehen / bestanden haben.
Der jetzige K8L ist ja schon seit Wochen fertig, während die bei HTr3 noch nicht der Fall ist.

Zum Vergrößern anklicken....

Kommt das auch für Destop-CPUs (ausnahme FX)


Schließlich steht da beim Stern, der bei 2007 und 2008 markiert ist
"planned features for future AMD Opteron processor-based systems"

http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1158568718

Hypertransport 3.0 ab Q4'2007

Wobei AMD ja dann gleich die DDR2/3 Kombicontroller integrieren will, welche ja gerade in der Enddefinition bzgl. reg. DRAM sind.

Wenn man noch die Vorlaufzeiten vom Samples über Final Design bis Ladentheke berücksichtigt ist AMD also heute schon nahe der ersten Realisierung von Hypertransport 3.0 in echtem CPU-Silicium.

Ich habe mich auf WO mal aufgrund entspr. Anstosses mit den möglichen Yields des K8L u. von dessen Derivaten befasst. Das wollte ich eh schon einmal tun.
Hier nun die Ergebnisse:

Erste Rechnung:

Ich habe dazu mal die Daten des Wafer-Tools von geek.com modifiziert. Unter "Quickselect" stehen die Größen für Rev. F, G und den Quadcore.

Bei "Die Spacer" muss man wohl 0.5 mm eintragen (man muss dazu erstmal Ziffern löschen), da das dann bei Rev.G etwa mit dem 300mm-Wafer auf Image_0084f (siehe http://amd-images.de/PICS/process/zips/Image_0084f.zip) besser übereinstimmt.

Es kann in der Produktion natürlich auch weniger sein. Aber mit diesen Zahlen komme ich auf etwa 202 Die-Kandidaten pro 300mm-Wafer. Und der Großteil der Wafer wird nichtmal QC enthalten. Auf dem Analyst-Day waren ja auch schon Wafer mit 65nm-Dual-Cores zu sehen. Deren Größe war ca. 9,1 x 15 mm, also <140 mm².

Wenn der gesamte ~290mm²-Chip bei einer Defect Density von 0,25/cm² funktionieren müsste und nur aus Logik bestünde, wären die Yields wohl bei ca. 30%. Da Caches aber meist reparabel sind u. Chips mit weniger Cores auch verkaufbar, wird die Rechnung kompliziert. Aber ich habe sie einmal durchgeführt:

Dies ist ein Beispiel für K8L-Yield, wenn Caches mit redundanten Zellen ausgestattet sind u. Dies nur mit wenigen defekten Cores/HT-Links dennoch verwendet werden können:


Da hätten wir 34 vollständig defekte Dies (grau), 128 volle Quad Cores (grün), 34 Triple Cores (gelb) und 6 Dual Cores (cyan). Defekte Cores/HT-Links sind grau. Wenn XBar, DDR-Pads u. ähnliche kritische Bereiche getroffen wurden, galt das Die auch als defekt. Hellgrüne Dies sind welche, wo min. 1 HT-Link defekt ist.

Ich habe die Dies so plaziert, dass ich auch auf die 202 Kandidaten komme, wie in dem Wafer Tool von Geek.com. Ich habe eine Defect Density von 0,25/cm² angesetzt.

Über 1000 Wafer gemittelt sind es übrigens:
17,0% defekt
0,1% SC
2,1% DC
18,7% TC
62,1% QC



Zweite Rechnung mit (für mich) plausibleren Ergebnissen:

Da ich die Yield-Modelle selbst noch nicht implementiert habe, griff ich zum Gross/Net-Die-Calculator von ICKnowledge (http://www.icknowledge.com/misc_technology/die_calculator.xls), um das Yield des Barcelona-Cores etwas genauer zu bestimmen. In einer Dissertation am Fraunhofer-Institut in Dresden u. aus anderen Quellen sowie auch als Voreinstellung im Calculator findet man Werte eher um 0,5 Defekte/cm².

Das führt bei der bisher wahrscheinlichsten Die-Größe für den Barcelona zu Yields von 28% bis 41%. Das scheint mir alles wirklich zu niedrig, da die Yields für die aktuellen Cores auch recht niedrig wären, wo doch die Gesamt-Yields (jene ~70%) ja noch Line Yield (war bei AMD vor 3-4 Jahren bei 96%) u. andere Faktoren enthalten, wo auch noch Verluste auftreten. Das reine Die-Yield müsste dann etwas höher liegen, somit die Defect Density eher niedriger, wie z.B. bei 0,25 Defects/cm².

Für den kleinen Winchester ergäbe das z.B. 63-82% u. den Barcelona wiederum 43-58% Die Yield.

Davon ausgehend, habe ich nochmal gerechnet:
Über 1000 Wafer gemittelt sind es nun:
27,3% defekt (55/Wafer)
0,4% Single Core (fast 1/Wafer)
4,6% Dual Core (9/Wafer)
23,2% Triple Core (47/Wafer)
44,5% Quad Core (90/Wafer)

Beispiel-Verteilung (ohne komplexe Yield-Simulation):

Da sind hier 53 defekte Dies, 1 Single Core (hier fliegt nix weg), 9 Dual Cores, 45 Triple Cores (jetzt versteht man Fred Weber sicher besser) und 94 Quad Cores.

Naja, da die Triple Cores weniger sind als die Quad Cores, lassen sie sich schwierig in der Produktpalette unterbringen, während die Dual Cores (wofür die TCs auch genutzt werden können) ja auch noch durch entsprechende Wafer mit dedizierten Dual Cores im Volumen "unterstützt" werden.

Dresdenboy schrieb:

Naja, da die Triple Cores weniger sind als die Quad Cores, lassen sie sich schwierig in der Produktpalette unterbringen, während die Dual Cores (wofür die TCs auch genutzt werden können) ja auch noch durch entsprechende Wafer mit dedizierten Dual Cores im Volumen "unterstützt" werden.

Zum Vergrößern anklicken....

Klingt logisch und wird sicherlich am Anfang der Fertigung so von AMD auch umgesetzt.

Später = 45nm & ZRAM als L3-Cache erscheint auch wirtschaftlich machbar einfach auf Duzal-Core zu reduzieren.

Das Thema redundante SRAM-Zellen beim L2 erscheint vernünftig, denn es ist ärgerlich wg. weniger defekter SRAM-Linien gleich einen ganzen bzw.dann als downgrade zum Dual-Core einen ganzen Quad zu verlieren.
AMD beschreibt sein Quad-Design als 'für 65nm und kleiner' entwickelt, was gerade bei der Einführung von 45nm so die Yieldrate unabhängiger von den vielen Transistoren des L2 macht.

@DDB - respect:

BavarianRealist@WO hat einen Hinweis auf kursierende AMD-Rev.H-Samples gefunden:

As for the quad-core processors, the sources disclosed that some server ODMs have already received samples of AMD's Revision (Rev) H and Intel's Xeon 3200 and have started developing supporting motherboards.

Rev H-based servers are expected to ship in the second quarter of 2007, while shipments of Xeon 3200-based servers will begin in January 2007, the sources indicated.

Zum Vergrößern anklicken....

http://www.digitimes.com/systems/a20060920A7032.html

Falls das stimmt, erinnert mich das wieder sehr an die Dual-Core-Geschichte mit dem Timing der Tape-Out-Meldung usw. Per Rocket Lots wäre sogar der Start für First Silicon Mitte Juli plausibel. Aber AMD würde doch auch selbst erst umfangreichere Tests fahren, bevor Samples an Entwickler gehen, die darauf angewiesen sind, dass die CPUs schon möglichst erwartungsgemäß arbeiten.

Dresdenboy schrieb:

Falls das stimmt, erinnert mich das wieder sehr an die Dual-Core-Geschichte mit dem Timing der Tape-Out-Meldung usw.
Per Rocket Lots wäre sogar der Start für First Silicon Mitte Juli plausibel. Aber AMD würde doch auch selbst erst umfangreichere Tests fahren, bevor Samples an Entwickler gehen, die darauf angewiesen sind, dass die CPUs schon möglichst erwartungsgemäß arbeiten.

Zum Vergrößern anklicken....

Nun, die Quad-Core arbeiten bei geringerer Spannung, dafür aber etwas höheren Ampere-Spitzen.
Allein aus elektrischen Gründen wären frühe Samples nicht schlecht für die Hersteller von Mainboards.

Das Final-BIOS für Quad-Core hingegen hat noch Zeit. beim Debugging ändern sich die elektrischen Parameter nicht mehr.

Wie 'digitimes' schon aufführt, Q2'2007 bzw. Waferstarts Anf. 2007 sind jetzt in der Planung bei AMD. Q1'2007 ist die 65nm schon deutlich in der Nutzung bei der Fab36 und AMD hätte noch 4 Monate um das Final-Stepping zu erstellen bzw. es demnächst zu testen. Erscheint nicht unrealistisch, schließlich war der Quad-Core kein Schnellschuß sondern ein jahrlang schon in der Entwicklung sich befindendes Produkt mit Zielrichtung 65nm (sonst eben zu großes DIE).
Es kam nur die eSiGe Fertigung wg. Strombedarflimitierung dazu, was aber den reinen Schaltungsentwicklern eher noch mehr Zeit zur Reife des Designs brachte.

Hier noch ein interessanter Auszug aus Digitimes:

As for the quad-core processors, the sources disclosed that some server ODMs have already received samples of AMD's Revision (Rev) H and Intel's Xeon 3200 and have started developing supporting motherboards.

Rev H-based servers are expected to ship in the second quarter of 2007, while shipments of Xeon 3200-based servers will begin in January 2007, the sources indicated.

http://www.digitimes.com/systems/a20060920A7032.html

@Spacedust:
Das habe ich doch 2 Posts über dir schon zitiert

@K8L:
Charlie mailte mir auf den Hinweis zum Digitimes-Artikel als Antwort, dass die Samples schon einige Wochen unterwegs sind u. die Performance noch schlecht sei ("said to suck"). Aber das ist erstes Silizium u. dass es arbeitet, sei erstmal wichtiger als Leistung.