AMD: Quad-Core 65nm ab Q1'06 ?!

http://www.the-inquirer.net/?article=23747 ?

Gerücht oder Gag eines AMD-Mitarbeiters ?


Ein Quad-Core mit 4* 1M und Socket 1207 (Quad-Channel RAM ?)
würde in 65nm ca. 150-275 mm2 benötigen (150mm2, falls AMD das kompakte 65nm L2-Design der IBM-Entwicklung verwenden könnte

Auf den 300 mm2 Wafern der Fab36 ergäbe dies (bei 50% Yieldrate)
ca. 200 bis 125 DIEs ja Wafer.

Auch könnte Quad-Core die relativ hohe TDP erklären, der für Socket F im Gespräch sind.

Ganz viel Spekulatius.
Aber was spricht denn dagegen 2 90nm-Dual-Core-Die auf einem Package miteinander via HTr. zu verbinden und den Rest sprich 2 Dual-Channel-Mem-Controller und die restlichen HTr-Links nach draussen zu legen.

Ich glaube es wäre ein zu großer Schritt auf 65nm und gleichzeitig auf einen Quad-Core zu gehen.

Grüße,
Tom

mocad_tom schrieb:

aus diesem Posting

Ganz viel Spekulatius.
Aber was spricht denn dagegen 2 90nm-Dual-Core-Die auf einem Package miteinander via HTr. zu verbinden und den Rest sprich 2 Dual-Channel-Mem-Controller und die restlichen HTr-Links nach draussen zu legen.

Ich glaube es wäre ein zu großer Schritt auf 65nm und gleichzeitig auf einen Quad-Core zu gehen.

Zum Vergrößern anklicken....

Hauptprobleme beim Quad sind:
- Thermische Daten und Stromversorgung
- Größe des DIE (=Fehlerwahrscheinlichkeit bei der Fertigung & Kosten)

Bei zwei DIEs auf einer Package haben wird genauso das thermische Problem.

Kann AMD das Design von IBM beim 65nm L2 übernehmen, würde dieser ziemlich schrumpfen.
Auch wäre ein gemeinsamer L2 oder zwei Cores mit je einem gemeinsamen L2 und dies im Doppelpack möglich. (Solch ein Design wäre dann auch Nachfolger der heutigen Single-Core A64, die AMD lt. eigener Auskunft ja einstellen will)
AMD hat ja für die 65nm Linie den K8 abgeändert, was schon Pazifica & Co. sowie ein neuer Socket andeuten.

AMD verkauft zudem ja gut beim Opteron die zwei-Socket Produkte, was dann beim Quad-Core zu acht Cores auf einem Dual-Socket Board führen kann.

Wer mehr benötigt soll ja in weiterer Zukunft auch noch einen 8-fach Core erhalten können.

Zudem - AMD hat ja schon vor Jahren das Tandem HT-Links und Multi-Core entwickelt, wobei eben bisher erst HT-Links und Dual-Cores in der Fertigung sind.

Zur Thermischen Seite eine Anmerkung
AMD kann jetzt schon 25Watt CPUs mit 1,8Ghz liefern ergo dürfte ein 1,8GHz Quadcore theoretisch selbst in 90nm machbar sein.
Entscheidend wäre imo der Support von DDR-2 800, der dann dem Quadcore die gleiche Bandbreite zur Verfügung stellen würde wie heutiger DDR1-400

Ray2k schrieb:

aus diesem Posting
Zur Thermischen Seite eine Anmerkung
AMD kann jetzt schon 25Watt CPUs mit 1,8Ghz liefern ergo dürfte ein 1,8GHz Quadcore theoretisch selbst in 90nm machbar sein.
Entscheidend wäre imo der Support von DDR-2 800, der dann dem Quadcore die gleiche Bandbreite zur Verfügung stellen würde wie heutiger DDR1-400

Zum Vergrößern anklicken....

Nur dürften 1,8 GHz kaum in 2006 noch ein Verkaufserfolg werden.
Da wären Dual-Socket Lösungen mit je einem Dual-Core für die Anwender sinnvoll.

Es muss Takt vorhanden sein, aber auch Ersparnis bei den Stromkosten.
Und natürlich sind solche Designs nur auf 300mm und eben 65nm sinnvoll.


Welche Speicherdesigns AMD dann tatsächlich mal unterstützen wird muß man sehen.
Auf einem Dual-Socket Board haben wir heute ja schon 2* 128 Bit Anbindung (128 Bit je Socket), was bei 1207 statt 940 Socket-Pins einen auf Ideen kommen läßt.
Sicherlich auch alles min. in DDR-II umgesetzt (AMD hat ja bei einem der jüngeren GEODE-Produkte bereits einen DDR-I /DDR-II Controller integriert - die Technologie dafür ist also produktionsreif).

@rkinet:
So "undicht" ist der L2-Cache auf dem K8 übrigens nicht. Die eigentlichen SRAM-Zellen belegen fast genau die Hälfte der als L2-Cache sichtbaren Fläche. Dazwischen befindet sich irgendwelche Logik (unter dem Mikroskop war kein eindeutiges Muster erkennbar). Wenn es also ein Problem mit der Dichte gibt, dann eher deshalb, weil die Lücken zwischen den Blöcken zu groß sind


@mocad_tom:
Ein Quadcore in 65nm wäre kein größerer Aufwand als irgendein neuer Core in 65nm. Die Cores werden ja dann sehr wahrscheinlich die gleiche Funktionalität aufweisen und sich deshalb gleichen (wenn auch gespiegelt). Und irgendein neuer Core wird ja einmal kommen. Siehe auch SKYNETs Bemerkung zum K10, auch wenn die Existenz dadurch nicht bewiesen ist. Es paßt zumindest in den Zeitrahmen.

Dresdenboy schrieb:

aus diesem Posting
Ein Quadcore in 65nm wäre kein größerer Aufwand als irgendein neuer Core in 65nm. Die Cores werden ja dann sehr wahrscheinlich die gleiche Funktionalität aufweisen und sich deshalb gleichen (wenn auch gespiegelt). Und irgendein neuer Core wird ja einmal kommen. Siehe auch SKYNETs Bemerkung zum K10, auch wenn die Existenz dadurch nicht bewiesen ist. Es paßt zumindest in den Zeitrahmen.

Zum Vergrößern anklicken....

Intel startet mit einem 155Mio-Transistoren-Federgewicht ins 65nm Zeitalter und AMD macht es mit einem 410Mio-Tr-Prozessor.

Vllt. nehmen sie zwei 65nm-Dual-Core-Die auf ein Package - aber zu mehr lasse ich mich nicht hinreissen.

Grüße,
Tom

mocad_tom schrieb:

Intel startet mit einem 155Mio-Transistoren-Federgewicht ins 65nm Zeitalter und AMD macht es mit einem 410Mio-Tr-Prozessor.

Vllt. nehmen sie zwei 65nm-Dual-Core-Die auf ein Package - aber zu mehr lasse ich mich nicht hinreissen.

Zum Vergrößern anklicken....

Es kommt nicht auf die Transistoranzahl an, sondern auf die Fläche. Und von dieser wären bei AMD auch noch in deiner Annahme 4 MB an reparablen L2-Caches. So ein Chip wäre für einige Zeit noch kein Desktop-Kandidat und mit 220-260 mm² (falls L2 redesigned wird) kein unproduzierbares Supermonster mit Yields von 1 pro Wafer

Angenommen, die Anandtech-Thread-2-Sync-Werte stimmen.
Weiterhin angenommen, die nächste HTr-Generation hält einzug(1,4GHz).

Was spricht dagegen 2 65nm-Opteron-275-Dies auf dem Package miteinander zu verkabeln.
Die laufen dann sowieso millionenfach vom Band.

mocad_tom schrieb:

Angenommen, die Anandtech-Thread-2-Sync-Werte stimmen.
Weiterhin angenommen, die nächste HTr-Generation hält einzug(1,4GHz).

Was spricht dagegen 2 65nm-Opteron-275-Dies auf dem Package miteinander zu verkabeln.
Die laufen dann sowieso millionenfach vom Band.

Zum Vergrößern anklicken....

Wenn die Thread-Ping-Pong-Ergebnisse einen festen Bezug zur Realität in der Anwendungswelt hätten, könnten wir sie natürlich für solche Ideen benutzen. Aber was nützt eine CPU, die am schnellsten sich identische Daten hin-und-her-kopieren kann, wenn neue Daten lange brauchen. Sonst könnten wir auch sagen, daß die HT-CPU die beste überhaupt wäre

Gegen 2 275-Dies auf einem Package spricht nur, daß man dann entweder 4 Speicherkanäle haben müsste (dafür gibt Sockel-F nicht genug Pins her), oder man hat eine langsame Lösung, wo sich nun 4 schnelle Cores eine Speicheranbindung teilen. Die Bandbreite wirkt sich zwar auf die Wartezeit von Cores aus, wenn diese auf einen zu beendenden Speichertransfer warten müssen, aber die gesamte Konfiguration wäre nicht gerade vorteilhaft, wenn zu den Speicherlatenzen noch für 2 Cores die Latenz durch den Weg HT->IMC->RAM erhöht wird.

Hier könnte man überhaupt viel herumspielen und experimentieren: 4 kleinere Cores mit 1 DDR2-IMC, 4 K8-Cores mit mehr Cache und 1 IMC, 4 K8-Cores mit 2 IMC (bei entspr. Sockel). usw.

Dresdenboy schrieb:

aus diesem Posting
Wenn die Thread-Ping-Pong-Ergebnisse einen festen Bezug zur Realität in der Anwendungswelt hätten, könnten wir sie natürlich für solche Ideen benutzen. Aber was nützt eine CPU, die am schnellsten sich identische Daten hin-und-her-kopieren kann, wenn neue Daten lange brauchen. Sonst könnten wir auch sagen, daß die HT-CPU die beste überhaupt wäre

Zum Vergrößern anklicken....

Die SRQ verbessert zwar die Latenz und die Bandbreite, dennoch kann man einen Schnellschuss mit 32bit 1,4GHz-Htr als Zwischenschritt auch durchgehen lassen. Intel packt im moment 2 SingleCore-Prozessoren auf ein Package und einen FSB, der mit einer CPU schon eng wird.

Gegen 2 275-Dies auf einem Package spricht nur, daß man dann entweder 4 Speicherkanäle haben müsste (dafür gibt Sockel-F nicht genug Pins her), oder man hat eine langsame Lösung, wo sich nun 4 schnelle Cores eine Speicheranbindung teilen.

Zum Vergrößern anklicken....

FB-DIMM-Spekulatius für den Sockel F?
Oder vielleicht zwei Single-Channel-DDR2-800-Mem-Controller?

Die Bandbreite wirkt sich zwar auf die Wartezeit von Cores aus, wenn diese auf einen zu beendenden Speichertransfer warten müssen, aber die gesamte Konfiguration wäre nicht gerade vorteilhaft, wenn zu den Speicherlatenzen noch für 2 Cores die Latenz durch den Weg HT->IMC->RAM erhöht wird.

Zum Vergrößern anklicken....

Es gibt ja auch heute schon diese Low-Budget-Dual-Boards von Tyan wo nur an einem Sockel Speicherbänke verdrahtet sind.

Hier könnte man überhaupt viel herumspielen und experimentieren: 4 kleinere Cores mit 1 DDR2-IMC, 4 K8-Cores mit mehr Cache und 1 IMC, 4 K8-Cores mit 2 IMC (bei entspr. Sockel). usw.

Zum Vergrößern anklicken....

Mich würde interessieren, ob die aktuelle SRQ schon für 4 Cores ausgelegt ist.
Laut den Specs hatte der erste Opteron schon eine dualfähige SRQ.
Vllt. hat der jetzige Dual-Opteron(stepping E6) schon eine quadfähige SRQ.

Ich finde auch die Design-Entscheidung bei der XBox2 sehr interessant. Um eine etwas schwächere Speicheranbindung kaschieren zu können werden 10MB embeddedDRAM reingepackt.

Grüße,
Tom

mocad_tom schrieb:

FB-DIMM-Spekulatius für den Sockel F?
Oder vielleicht zwei Single-Channel-DDR2-800-Mem-Controller?

Zum Vergrößern anklicken....

2 single-channel-DDR2-IMCs vs. 1-dual-channel-DDR2-IMC wird im Serverbereich IMO keinen Stein verrücken.

mocad_tom schrieb:

Es gibt ja auch heute schon diese Low-Budget-Dual-Boards von Tyan wo nur an einem Sockel Speicherbänke verdrahtet sind.

Zum Vergrößern anklicken....

Das sieht aber nicht nach dem Zielmarkt für ein frühes Leistungsmonster wie den Quad-Core-Opteron aus.

mocad_tom schrieb:

Mich würde interessieren, ob die aktuelle SRQ schon für 4 Cores ausgelegt ist.
Laut den Specs hatte der erste Opteron schon eine dualfähige SRQ.
Vllt. hat der jetzige Dual-Opteron(stepping E6) schon eine quadfähige SRQ.

Zum Vergrößern anklicken....

So einfach geht das nicht. Sie wird wohl mit dem K8-Kern-Nachfolger kommen.

Hector Ruiz hat bei der offiziellen Vorstellungsfeier des Dual-Core-Opteron den Quad-Core für April 2007 angekündigt - angenommen das Inquirer-Gerücht ist wirklich weit hergeholt.

In Q1 2006 kommen die neuen Sockel.
Angenommen die neuen Sockel leben 2 Jahre, dann wird selbst der Sockel S1 einen Dual-Core sehen und der Sockel M2 einen Quad-Core bekommen.

Der Dempsey ist für H1/2006 angesetzt - dieser setzt auf FB-DIMM.
"Blackford: Lindenhurst successor for the Dempsey dual core processor. EM64T. Dual Independent FSB. FB-DIMM Support. Scheduled for H1'06"
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2265

Der Sockel F wahrscheinlich auch.
Grüße,
Tom

mocad_tom schrieb:

Der Dempsey ist für H1/2006 angesetzt - dieser setzt auf FB-DIMM.
"Blackford: Lindenhurst successor for the Dempsey dual core processor. EM64T. Dual Independent FSB. FB-DIMM Support. Scheduled for H1'06"
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2265

Der Sockel F wahrscheinlich auch.

Zum Vergrößern anklicken....

"Dual Independent FSB" entspricht dem Vorteil der K8 mit Hypertransport für I/O und dem IMC.

Was der Sockel F macht, ist noch nicht klar. Aber ich hatte auf P3DNow und SI schonmal vorgerechnet, daß die Pinzahländerung zu einer HT-Erweiterung auf 32bit passt. Aber die FB-DIMMs (mit DDR1 oder DDR2) sollen IMO nur die Speicherkapazität von Xeon-Systemen aufbauen, da dort ja eine Speicherbank für mehrere CPUs zuständig ist und nicht mehrere Bänke "zusammengeschaltet" werden, wie beim Opteron. Dafür gibt es eine erhöhte Latenz - genau das, was der IMC ja reduzieren soll.

So macht es noch keinen Sinn, FB-DIMMs für AMDs CPUs mit IMC einzusetzen, auch wenn AMD min. ein Patent hat, was in die Richtung eines solchen Speichersystems geht. Die SMT-Patente kamen ja auch noch nicht zum Einsatz, sonst gäbe es nicht das DivX-Debakel bei THG

mocad_tom schrieb:

aus diesem Posting

Hector Ruiz hat bei der offiziellen Vorstellungsfeier des Dual-Core-Opteron den Quad-Core für April 2007 angekündigt - angenommen das Inquirer-Gerücht ist wirklich weit hergeholt.

Zum Vergrößern anklicken....

Nun,
a) auch der X2 sollte ja erst später kommen ...
b) Intel hat ja bereits per D 840 einen Pseudo-Quad im Angebot.
c) AMD hat die Entwicklung weiterer Single-Core eingestellt (egal ob Opteron A64)
d) die Fab36 bietet genügend Waferfläche für einen Quad
e) der neue Socket F ist für Dual-Core Opterone niemals wirklich nötig

Aber, wenn AMD den Quad bis Mitte 2006 bringen sollte, würden wir im Sommer/Herbst '05 eine Vorstellung durch AMD erleben und bis Jahresende '05 Sammples an erste OEMs raus gehen.


Beim Quad und auch zukünftigen Budget-Dualcore ist für mich die Frage ob AMD nicht das Dual-Design effektiver gestaltet.
Wie wäre es damit:
- die beiden Cores nutzen gemeinsame L2, L1, Decoder und die SSEx - Unit
- dabei wird der Instruktions-L1 zu einem inklusiv-Cache oder L0/L1
- es gibt zwei exklusive L2-Datencaches, an denen der L2 hängt
- ein Quad besteht aus zwei solcher Units per crossbar Kopplung

Im Vergleich zum X2 würde der Core etwa 2/3 der Fläche von zwei K8-Cores benötigen, aber sich auch mit kleinen Caches vertragen. Ein DC-Sempron mit gemeinsamen 512k-L2 läge in 65nm dann bei ca. 60 mm2, ein DC Athlon mit 2M-L2 etwa bei 100 mm2.
Ein Quad mit 2* 2M läge dann bei 200 mm2 und würde keine nenenswerten Zusatzaufwand bei der Entwicklung benötigen.
Auch würde eine engere Anbindung der beiden Cores die Integer-Performance nochmals erhöhen, während die eine gemeinsame SSE-Unit (die ist eh nie voll ausgelastet) kaum Verluste bringen würde.

Ein solches Design wäre zudem auch ein besser Ersatz für Intels-HT, was nahe legt, daß AMD sich schon viele Jahre damit hat beschäftigt. (s. auch L0-Cache Patent von AMD)
Es erscheint mir unwahrscheinlich, daß AMD das SMT-Design der Intel/IBM Konkurrenz nur mit echten Mehrfachkernen beantworten wollte oder will.

AMD mußte schon vor Jahren damit rechnen, daß zumindest logische Multicores die zukünftige CPU-Technik auch am Desktop bestimmen wird. Und das Kosten /Nutzenverhältnis für rein 'physikalische' Kerne ohne gemeinsame Nutzung von nur teilweise ausgelasteten Units schlecht ist.

Dies gilt ja beim Desktop für das DRAM (daher überhaupt Multicore),
den L2 (s. aktuell Yonah) und
die FloatingPoint (s.Office/Internet PCs).
Dafür ist gesteigerte Integerleistung und Multitasking (Virenscanner, mehrere laufende Applikationen) ja absehbar auch zukünftig eine realistische Alltagssituation.



am K8-Schema skizziert:
- der L1 o. L0 & L1 würde 6 statt 3 paralle Stufen bedienen
- Core 0 und Core 1 teilen sich die Floating/Point = SSE
- Core 0 nutzt einen eigenen L1-Datencache für Integer
- Core 1 nutzt einen eigenen L1-Datencache für Integer und Floating/Point = SSE
- L2 steht beiden Cores zur Verfügung (also 2* exklusiv L1 Datencache, 1* Instruktionscache)
- (Quad-Core = Dual-Version dieses Designs)



---
http://www.computerbase.de/news/hardware/prozessoren/amd/2005/juni/quad-core-cpu_amd_anfang_2006/
basiert (aber) auch auf der 'The Inquirer' Online-Meldung.

@rkinet
Danach hast du keine Athlon-CPU mehr.
Die Chip-Architekten bringen die CPU auf den richtigen Weg mit gezielten eingriffen an kleinen genau begrenzten Punkten und du willst die ganze Architektur niederreissen.
Der K8 hat immer noch den selben Core und den selben Cache wie der K7.
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2387&p=3
Da wird nur noch geshrinked und die zusätzlichen Befehlssätze im Laufe der Jahre dazugeklatscht.
Und die Core-Zahl nach oben gedreht.

Wenn sich der XBox2-Prozessor mit seinem besonderen SMT-Aspekt gut hervortut, dann kommt evtl. noch eine kleine Pipeline-Verlängerung + SMT + Gigahurzwahn dazu.

@ddb
>So macht es noch keinen Sinn, FB-DIMMs für AMDs CPUs mit IMC einzusetzen.
Jeder Core will anständig mit Speicherbandbreite gefüttert werden.
Die Serverhersteller wollen endlich richtig dicke RAM-Bestückungen ausliefern.
Mit parallel nach draussen gelegten Speicherbänken wird die Verkabelung immer schwieriger.
Es kann nicht angehen, das pro Sockel940 nur 8GB RAM installiert werden können.
Aber es stimmt schon, das man sich die schönere(sprich serielle) Speicheranbindung druch mehr Latenz erkauft.
Deshalb favorisiere ich auch ein Modell aus
OnPackage local Storage mit ganz zackig getakteten GDDR3 Modulen oder embeddedDRAM
und FB-DIMM als Hauptspeicher
http://www.planet3dnow.de/vbulletin/showthread.php?p=1946644#post1946644
Grüße,
Tom

mocad_tom schrieb:

aus diesem Posting
@rkinet
Danach hast du keine Athlon-CPU mehr.
Die Chip-Architekten bringen die CPU auf den richtigen Weg mit gezielten eingriffen an kleinen genau begrenzten Punkten und du willst die ganze Architektur niederreissen.
Der K8 hat immer noch den selben Core und den selben Cache wie der K7.
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2387&p=3
Da wird nur noch geshrinked und die zusätzlichen Befehlssätze im Laufe der Jahre dazugeklatscht.
Und die Core-Zahl nach oben gedreht.

Zum Vergrößern anklicken....

a) natürlich wäre dies ein Athlon und eben ergänzt um schon lange von AMD patentierten Lösungen wie dem L0-Cache. Ganz für den Papierkorb dürfte AMD kaum Patente erstellen.

b) Der heutige X2 und auch der Smithfield benötigen einigen Verwaltungsaufwand um die Cores zu koordinieren. Bei HT-Software oder typ. Serverapplikationen kein großes praktisches Problem, mit Einführung der Virtualisierung und dem Bedarf die beiden Cores einzeln oder im Doppelpack als virtuelle CPUs zur Verfügung zu stellen dürfte dies sich aber ändern.

c) Zitat: Da wird nur noch geshrinked und die zusätzlichen Befehlssätze im Laufe der Jahre dazugeklatscht. Da stellt sich wieder die alte Grundsatzfrage, ob bei AMD einige hundert Schaltungsentwickler sitzen (und die erst 2004 angeheuerten Neuen), die täglich Kaffe trinken, Internet glotzen und freitags dann mal wieder drei CPU-Gatte optimiert haben.
Oder eben seit Jahren an einem Neudesign arbeiten ...

d) s. b) - Ein Quad-Design = 2* neues Core per Crossbar wäre für Serverapplikationen weiderum kein Problem.

e) Das Problem DC-Turion - zwei vollständige K8-Cores, also das X2 Konzept, schlucken eben überproportional Strom. Im Desktopbereich zeigen die Spezifikationen bei den CPUs wieder leicht nach oben, für AMD im Mobilbereich tötlich.
Je weniger Komponenten und je mehr abschaltbar ist, desto besser. Auch dürfte die Core -Syncronisation per Crossbar auch einiges an Strom benötigen.

f) Sollte AMD Zugriff auf die kompakten 65nm SRAM = Cachestrukturen haben, die IBM eh mit Partnern entwickelt hat, würde bei AMD der Core im Cachebereich überproportional schrumpfen können, d.h. die Corelogik auf ca. 60%, die Caches aber auf ca. 30%.
Mit wahrscheinlich wenig Designaufwand (der K8 wird eh für Pzifica an vielen Stellen verändert) könnte man den Decoder (s. HT oder SMT) für den zusätzlichen Bedarf aufbohren und eben die Anzahl der AGUs und ALUs einfach verdoppeln. Zusätzlich müßte am Decoder einiges verändert werden - aber s. HT/SMT - was aber für AMD eh auf der Agenda seit Jahren gestanden haben müßte.

g) AMD hat bei (echten) Dual-Core in der Fertigung etwa 1 Jahr Vorsprung vor Intel (ab Yonah) und hat sich seit Ewigkeiten mit den Auswirkungen von diversen Multicore-Designs beschäftigt. Es wurde auch ein SMT/HT Konzept immer verworfen, was aber reines Multicore mit jeweils vollwertigen Cores nicht wirtschaftlich ersetzen kann.
Problem für AMD war natürlich bisher immer die Notwendigkeit der Akzeptanz von x86-64, da man mit x86 only oder IA64 am Markt alle Änderungen am Core einfach sich hat sparen können. Jetzt ist die Entwicklung klar und man kann alle Idden umsetzen.
Zudem hat man die 300mm /65nm Fertigung bald zur Verfügung, die man aber auch nicht beliebig mit Mammut-Core beaufschalgen kann, da sonst Yieldrate und Kosten aus dem Ruder laufen würden.

h) AMD hat mit der Fab36 eine $2,5 Milliarden Investition am Hals. Da kann und konnte AMD beim Schaltungsdesign nicht Däumchen drehen, besonders da Intel ja auch nie schlägt.

so, dies meine ersten Gedanken dazu.

Der AMD Quad-Core wird kommen - ob Anf. 2007 oder deutlich früher.
Und er ist schon weit entwickelt, sonst hätte AMD nie ihn in börsenrelevanten Meetings vorgestellt. Da ist also Luft nach vorne hin - sobald die Fab36 läuft.

a) Der L0-Cache wird schon nochmal eine Rolle spielen - später. Seit x86-64 gibt es wieder genug Register - wenn dort wirklich ein Flaschenhals wäre, hätte man früher schon versucht ihn zu lockern.

b) Du kannst zwei physikalische Cores nicht soweit zusammenfassen, das eine virtuelle dabei rausspringt. Aus zwei Cores 5 virtuelle Cores geht, allerdings wird diese eine ungerade virt.CPU relativ fest auf eine phys.CPU festgelegt. Ein ping pong von virtuellen CPUs wird immer Leistung kosten egal ob nun bei einem shared Cache oder einem unified Cache.

c)Du unterschätzt notorisch den Aufwand, der zu leisten ist um eine solche Architektur/Infrastruktur aus dem Boden zu stampfen. Selbst die kleinen Änderungen
- Umsortierung der Pins von S940 auf S939
- Optimierung der Cache-Latenz beim Die-Shrink von 130nm auf 90nm
- integration von SSE3
- 90nm Chip mit 2,8MHz
- Reduzierung der Stromaufnahme mittels Transistoroptimierung um den Core klar Schiff für Turion und X2 zu machen
- Integration von Pacifica/Presidio, DDR2-RAM-Controller und HTr 2.0b
- Entwicklung einer Vierport-SRQ
nehmen genug Zeit in Anspruch.

Was wurde denn für den K8 wirklich neu entwickelt - immerhin 4 Jahre Entwicklungszeit?
-integrierter Mem-Controller
-x86-64 Erweiterungen
-SRQ
-Hypertransport und ccHTr
Die Liste ist ganz schön kurz.

e) >Auch dürfte die Core -Syncronisation per Crossbar auch einiges an Strom benötigen.
Der Crossbar wird nur dann wirklich aktiv, wenn ein Cache-2-Cache-Abgleich erfolgen muss. Beim Yonah wird !jeder! L2-Cache-Zugriff durch den Cache-Controller(ein 3Mio-Transistor-Monster) erfolgen. Wenn AMD es schafft beide Cores voneinander unabhängig zu Takten werden die 65nm X2-Turions vielleicht noch sparsamer als der Yonah.

f) die bisherigen ALUs und AGUssind schon nicht voll ausgelastet. Man macht den Core nur unnötig fett.

g) ja nur her mit SMT, aber wohlüberlegt - wenn ich das hier richtig verstanden habe:
www.eecs.harvard.edu/~bclee/documents/lee2005-wced-pipe.pdf
eigent sich dazu aber eine etwas längere Pipeline, die schneller getaktet ist etwas besser.
Ausserdem müssen zuerst noch die Scheduler auf (2 Logische Cores) * 2 physikalische Cores optimiert werden - siehe Ergebnisse bei Pentium EE.

Grüße,
Tom

mocad_tom schrieb:

aus diesem Posting

a) Der L0-Cache wird schon nochmal eine Rolle spielen - später. Seit x86-64 gibt es wieder genug Register - wenn dort wirklich ein Flaschenhals wäre, hätte man früher schon versucht ihn zu lockern.

b) Du kannst zwei physikalische Cores nicht soweit zusammenfassen, das eine virtuelle dabei rausspringt. Aus zwei Cores 5 virtuelle Cores geht, allerdings wird diese eine ungerade virt.CPU relativ fest auf eine phys.CPU festgelegt. Ein ping pong von virtuellen CPUs wird immer Leistung kosten egal ob nun bei einem shared Cache oder einem unified Cache.

c)Du unterschätzt notorisch den Aufwand, der zu leisten ist um eine solche Architektur/Infrastruktur aus dem Boden zu stampfen. Selbst die kleinen Änderungen
- Umsortierung der Pins von S940 auf S939
- Optimierung der Cache-Latenz beim Die-Shrink von 130nm auf 90nm
- integration von SSE3
- 90nm Chip mit 2,8MHz
- Reduzierung der Stromaufnahme mittels Transistoroptimierung um den Core klar Schiff für Turion und X2 zu machen
- Integration von Pacifica/Presidio, DDR2-RAM-Controller und HTr 2.0b
- Entwicklung einer Vierport-SRQ
nehmen genug Zeit in Anspruch.

Was wurde denn für den K8 wirklich neu entwickelt - immerhin 4 Jahre Entwicklungszeit?
-integrierter Mem-Controller
-x86-64 Erweiterungen
-SRQ
-Hypertransport und ccHTr
Die Liste ist ganz schön kurz.

e) >Auch dürfte die Core -Syncronisation per Crossbar auch einiges an Strom benötigen.
Der Crossbar wird nur dann wirklich aktiv, wenn ein Cache-2-Cache-Abgleich erfolgen muss. Beim Yonah wird !jeder! L2-Cache-Zugriff durch den Cache-Controller(ein 3Mio-Transistor-Monster) erfolgen. Wenn AMD es schafft beide Cores voneinander unabhängig zu Takten werden die 65nm X2-Turions vielleicht noch sparsamer als der Yonah.

f) die bisherigen ALUs und AGUssind schon nicht voll ausgelastet. Man macht den Core nur unnötig fett.

g) ja nur her mit SMT, aber wohlüberlegt - wenn ich das hier richtig verstanden habe:
www.eecs.harvard.edu/~bclee/documents/lee2005-wced-pipe.pdf
eigent sich dazu aber eine etwas längere Pipeline, die schneller getaktet ist etwas besser.
Ausserdem müssen zuerst noch die Scheduler auf (2 Logische Cores) * 2 physikalische Cores optimiert werden - siehe Ergebnisse bei Pentium EE.

Zum Vergrößern anklicken....

a) Im Patent wird von 6* Decode-Unit gesprochen (http://patimg1.uspto.gov/.piw?docid...6367001'.WKU.%26OS=PN/6367001%26RS=PN/6367001)
Und das Patent ist jetzt 3 Jahre angemeldet.

(L0-Patent -Übersicht zur L0 Integration: http://patimg1.uspto.gov/.piw?docid...6367001'.WKU.%26OS=PN/6367001%26RS=PN/6367001)

b) ? es ging um die Integration von zwei Cores, die möglicht gemeinsam Resourcen direkt nutzen. Es gäbe ja dabei zwei exklusive L1-Datencaches, die sich mit dem L2 so synchronieren wie heute L1-I und L1- Cache des K7/K8. Der L1-I wäre zukünftig eben inklusiv, d.h. vielleicht 128k als Kopie vom L2 oder DRAM.
Bei allem gehe ich übrigens davon aus, daß AMD zukünftig in 65nm genauso kompakte (SRAM) Caches wie Intel oder IBM nutzen wird/kann.

c) AMD hatte ja lange Zeit dafür gehabt und sich dafür auch SMT verkniffen.

e) Das unabhängige takten könnte bei gesplitteter Vcc tatsächlich gut funktionieren

f) Etwa vier statt sechs Units ? Soviel Ersparnis bringt dies auch wiederum nicht und AMD müßte mit Performanceeinbrüchen im zweistelligen Prozentbereich rechnen. Da wäre das Design wieder fragwürdig und am Markt mit Problemen verbunden.

g) Das Design wäre ja kein SMT, da keine 'primitiven' Einheiten (wie ALU etc.) mehrfach genutzt werden müssen.

Ok, das L0-Patent ist durch die Zerteilung in zig Schemata unübersichtlich.
Aber die ganzen Bereichen gehen über ein getuntes konventionelle K7/K8 Design hinaus (s. Anlage). Natürlich könnte AMD diese Entwicklungen strecken oder überhaupt nie verwirklichen. Aber gerade die Erfordernisse von preiswerten Designs für den Massenmarkt und machbaren Designs für Quad und Okta-Cores lassen mich auf Änderungen am Core hoffen.
Zudem wird auch Intel (s. Yonah und später HT) versuchen die Zahl der Cores zu erhöhen, ohne gleich Transistormonster zu erhalten. Ein fiktiver Yonah-Nachfolger mit zusätzlich HT und dann noch zwei Units davon auf einem Core hätte 4 physikalische Cores, 8 logische und alles bei nur' 2* 2MB oder 2* 4 MB -L2.
Sowas könnte Intel schon locker mit 65nm in der Sub-150 mm2 DIE-Flächen Klasse fertigen.
Solche oder ähnliche Designs dürften AMD-Ingeniueren schon vor Jahren als 'Drohung' nachts im Traume erschienen sein. Gegen obiges Performancemonster mit vielleicht ein echter Quad-Core helfen, aber nicht zu gleichen Fertigungskosten.

Gruß Ralf

---

Anlagen:

Teilschema K8:




K8-DIE mit Beschriftung (groß) http://velox.stanford.edu/group/images/upro/amd_k8.jpg


noch ein Patent zum Core - auch vor 3 Jahren veröffentlicht:
(allerdings mit 'nur' drei Units)
http://patimg1.uspto.gov/.piw?docid...367006'.WKU.%26OS=PN/6367006%26RS=PN/6367006

a) vllt. wurde dieses Patent nur abgeschlossen um gegen Netburst ein Ass im Ärmel zu haben, nach der Misere also nicht mehr unbedingt relevant

b) Man hat jetzt 2 Cores auf einem Die und damit schon relativ viel Sync-Bandbreite bei geringen Latenzen. Aktuelle Multi-Thread-Software reagiert positiv darauf. Ob sich der Yonah wegen des Shared-Cache vom X2 absetzen kann wage ich zu bezweifeln.

g) SMT ist nicht übel - im Gegenteil. Intel hat sich damit hervorgetan, wie wenig Transistoren für SMT eingebaut werden mussten. Dort haben sie wohl an der falschen Stelle gespart. Ein intelligentes SMT-Design kann die Execution Units effizient auslasten. Wobei man hier streiten könnte, ab welchem Zeitpunkt handelt es sich um ein SMT-Design und ab wann um zwei eigenständige Cores, die sich Ressourcen teilen.

Ist zwar ein haufen Marketinggeblubber drin:
http://www.cs.utexas.edu/users/cart/arch/fall03/KallaSlides.pdf

Ich hatte ein schöneres Dokument wo gezeigt wird an welchen Stellen aufgebohrt wurde um SMT zu optimieren - wird noch nachgeliefert.

Grüße,
Tom

mocad_tom schrieb:

aus diesem Posting
vllt. wurde dieses Patent nur abgeschlossen um gegen Netburst ein Ass im Ärmel zu haben, nach der Misere also nicht mehr unbedingt relevant

Zum Vergrößern anklicken....

Vorschlag: mal abwarten

Mein Tip: 50% Chanche für das eine oder das andere als Lösung von AMD.

@mocad_tom:
Meinst du dieses Bild:


Übrigens würde SMT dem K8 auch etwas bringen, aber im Durchschnitt deutlich weniger als dem P4, da z.B. ein auf einen Speicherzugriff wartender Thread (wurde da etwa nicht prefetcht? *schimpf*) mit geringeren Latenzen zu kämpfen hat u. z.B. ein Thread, der sich durch einen falsch vorhergesagten Sprung nicht mit einer so großen Strafe rechnen muß, wie beim P4. Aber diese Fälle würden mit SMT zumindest den anderen Thread weiterlaufen lassen. Ein weiterer Vorteil wäre die befehlsgranulare Parallelausführung. Dann hätte AMD auch bei THGs Stresstest bei DivX eine Chance

Das Bild hatte ich im Hinterkopf für ein mäßig implementiertes SMT.

Zum Power5 hatte ich noch ein Dokument, wo aufgezeigt wurde, welche Flaschenhälse geweitet, welche Stages redundant angelegt wurden und wo nichts gedreht werden musste, da bereits im Überfluss vorhanden.

Bei all dieser Multi- und Many-Core-Diskussion wird total die Single-Thread-Performance ausser acht gelassen. Evtl. war dieses Gerücht gezielt gestreut( back-2-Topic ), um Intel noch weiter in eine Richtung forschen zu lassen - dabei hat AMD ein 4,5GHz-65nm-Monster im Labor laufen der jeden Quad-Core-Yonah von der Strasse fegt.

Einfach mal wieder zurück besinnen - Theorie:

100Transistoren mit 2GHz bringen genau so viel Rechenleistung
wie
50Transistoren mit 4GHz

Grüße,
Tom

mocad_tom schrieb:

Das Bild hatte ich im Hinterkopf für ein mäßig implementiertes SMT.

Zum Power5 hatte ich noch ein Dokument, wo aufgezeigt wurde, welche Flaschenhälse geweitet, welche Stages redundant angelegt wurden und wo nichts gedreht werden musste, da bereits im Überfluss vorhanden.

Zum Vergrößern anklicken....

Stimmt, du meintest ja "optimieren", nicht "implementieren" Aber auch das Intelsche SMT hat seine Berechtigung, da sonst noch mehr Leistung brach gelegen hätte.

Gleich auf der ersten Seite unten:
http://docencia.ac.upc.edu/ETSETB/SEGPAR/microprocessors/power5 (1) (mpr).pdf
Allerdings hatte ich irgendwie noch mehr erwartet.

Hier wird erklärt wie beim Power SMT auf die Thread-Timeslices einfluss genommen wird:
http://arstechnica.com/articles/paedia/cpu/xbox360-2.ars/5

Die Xenon-CPU ist schon was schönes

In meinem Vor-Vorgänger-Post - das verlinkte Dokument - dort auf Seite 11.
Dieses Diagramm veranschaulicht etwas die Einflussnahme.

Grüße,
Tom