AMD: Dual-Core ist fertig entwickelt

http://bigcharts.marketwatch.com/news/articles.asp?guid={3E807307-581D-4AD3-8547-C39988145D1B}&newsid=815222301&symb=AMD&sid=373

Produktion / Auslieferung Mitte 2005

Fix doch mal bitte den link, will des heute noch lesen

Edit:
Hab selber nomma bissal danach gesucht. Hier der Link

Sehr gut, nun ist es also öffentlich. Die Testwafer liefen schon seit einiger Zeit durch die Fab. Im Press Release war aber noch nichts von den Versionen mit mehr Cache zu lesen. Aber das kann sich eigentlich jeder als einen der weiteren Schritte denken vor allem schon wegen der zu teilenden Speicherbandbreite.

Hier noch das Press Release von AMD selbst,

die Roadmap:


sowie ein Die floorplan:


Für mehr:
Anandtech's Artikel

Nicht schlecht,

erwähnenswert ist v.a. dass es auch einen S939er Version in Form des Toledo geben wird.
Diskussionswürdig dagegen ist die Aufteilung des DDR Interfaces. Laut anandtech haben ja beide Kerne jeweils ein Dual Interfaces. Soviel zum Thema Socket 1308

Naja es wird ja wohl eine Socket 940 Version geben, aber wie teilt sich dann das Interfaces auf ? Jeder Kern einen Channel ? Einer beide Channels ? Oder irgendwie "dynamisch"

ciao

Alex

Original geschrieben von Dresdenboy
Hier noch das Press Release von AMD selbst,

die Roadmap:
<schnipp>

Zum Vergrößern anklicken....

http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1087248616

Roadmap auch bei AMD ansonsten haettest du die News ja auch schreiben koennen

Mir war dummerweise grade der PC abgestuerzt als ich mti dem Tippen fertig war.

Original geschrieben von Opteron
Nicht schlecht,

erwähnenswert ist v.a. dass es auch einen S939er Version in Form des Toledo geben wird.
Diskussionswürdig dagegen ist die Aufteilung des DDR Interfaces.

Zum Vergrößern anklicken....

Grade um den Toledo rankten sich die Gerüchte um Einführung eines neues Sockels. Was lässt Dich denn so sicher sein, dass der Toledo für den Sockel939 gedacht ist?
Die Neuigkeit, dass der Toledo mit Dual Core daher kommt, könnte die Gerüchte eines neuen Sockels weiter anheizen.

So früh?

und so früh outen sie sich?

Zu Vergleichszwecken pinne ich da mal mein Dual-Core-Thread rein ...
Dual-Core K8Hammer; Wie?

Mein Gefühl sagt mir, dass die I/O-Einheiten (Hypertransport) mit noch etwas dazu irgendwie abgedeckt wurden. Scheint auch ein ordentliches Redesign drin zu sein ...

scheint jedenfalls keine 1:1 Umsetzung unserer angenommenen Pläne zu sein. Aber soo falsch lagen wir wohl auch nicht.

Andererseits ist wirklich nicht viel aus dem Pixelbrei zu sehen

MFG Bokill

Hier das Original AMD Bild, das ist noch pixeliger:


Bin ja gespannt, wie schnell Intel jemand abstellt, der mit Paint einen Dual Irgendwas zu malen

Opteron mit zwei Kernen für Server und Highend-Client-PCs

1. Taucht für Sockel 940 (kompatibel)

2. Nutzt alle Möglichkeiten von Hypertransport 2.0 aus (Hohe Taktfrequenz + Pre/Deemphasis? )

a. 1,0, 1,2 oder 1,4 GHz. Dies bedeutet bei 11,2 GB/s bei 1,4 GHz bei der bisherigen Bitbreite (16 Bit hin + 16 Bit zurück) von HTr.

b. Allerdings verspricht die Emphasisgeschichte da noch deutlich mehr herauszuholen.

3. Teuer

4. Vorerst nur für Profisysteme

Weitere Details vermutlich am 24.06.2004. HyperTransport Webcast. Advanced HyperTransport 2.0 Functionality

Das heutige Ereignis ist wohl mit dem PCI-SIG Developers. Conference 2004 Booth #20 San Jose Convention Center San Jose, CA June 14-15, 2004 zu erklären.

Folgende Mitglieder sind bei der PCI-SIG Developers Conference 2004 anwesend.

PCI-SIG Developers Conference 2004
June 14-15, 2004
San Jose McEnery Convention Center
San Jose, CA

Exhibitor List

Platinum Sponsors
AMD
Cadence Design Systems
Denali Software, Inc.
NVIDIA
Synopsys
Wavecrest


Gold Sponsors
Agilent Technologies
ATI Technologies Inc.
CATC
GDA Technologies
HP
Microsoft
NEC Electronics America
nSys
PLD Applications
PLX Technology
Verisity Design, Inc.


Exhibitor Sponsors
Advanced Switching Interconnect SIG
Artisan Components Inc.
Catalyst Enterprises, Inc.
FuturePlus
Hyper Transport Consortium
LeCroy Corporation
Mentor Graphics
Nital
PCMCIA
Tektronix, Inc.
TransEDA, Inc.
VMETRO
Xilinx, Inc.

Zum Vergrößern anklicken....

http://www.pcisig.com/events/devcon04/exhibitors

@ Avalox:
[ACHTUNG: ironie]
jaja genau, jetzt kommt sicher der Sockel900, da 39pins weniger besser wären...
[ACHTUNG: /ironie]



bei einem neuen Sockel würde sich AMD mehr als nur ins eigene Bein schießen...

Das dürfte manche wundern:

"AMD will also continue to offer three power ratings for its dual-core server processors, Weber said. The company currently offers chips rated at 30 watts, 55 watts, and 89 watts, and will continue to do so for dual-core chips, he said." (Fred Weber, AMD, gefunden auf Aces Hardware

hä ?


wie, was, warum ?

Interessant ist auch, das AMD keinen OneCore-Die mehr für die Opterons plant, es werden also alle Opterons auf Dual-Core umgestellt (zumindest nach heutiger Roadmap). Dort wird dem Wettbewerbern ordentlich Feuer unter em Hintern gemacht, falls alles so klappen sollte wie es angedacht ist.

DualCore-Athlon FX´s finde ich traumhaft, denn so gibt es ein echtes Unterscheidungsmerkmal zw. den beiden (dann drei) Desktoplinien und die Skynets dieser Welt kann AMD richtig schön ausnehmen. Das freut mich als Aktionär. Zumindest in der Theorie, denn normalerweise ist eine Verschiebung der Roadmap um ein Quartal, meistens Pflicht. Und da niemand so richtig weiß was Intel vorhat, wird man einfach mal abwarten müssen.

Aber ansonsten scheint man bei AMD recht optimistisch zu sein. Das gefällt mir.

Shearer

Original geschrieben von p4z1f1st
@ Avalox:
[ACHTUNG: ironie]
jaja genau, jetzt kommt sicher der Sockel900, da 39pins weniger besser wären...
[ACHTUNG: /ironie]



bei einem neuen Sockel würde sich AMD mehr als nur ins eigene Bein schießen...

Zum Vergrößern anklicken....

Ein Bein stellen? So wie mit den hohen Preisen? Da kann man geteilter Ansicht sein.

Ob nun 900 Kontakte oder 1878 Kontakte, daran sollte man sich nicht festklammern.

Aber Opteron hat doch ganz recht, solch eine Lösung mit 2 x Dual Mem. Controllern, würde doch im Sockel939 (unnötig) beschränkt werden. Das gilt ja insbesondere bei im Sommer 05 zu erwartenden höher getakteten CPUs. Warum sollte AMD überhaupt eine 2 x Dual Mem Controller Basis entwickeln? AMD hat keinen Sockel am Markt, welcher dieses unterstützt.
Aber wer weiss? Vielleicht kommt der Toledo ja schon mit DDR2 Ram Unterstützung...
Ein FX ist halt was für Enthusiasten

Nette News

Auf den Bildern ist wirklich nicht all zu viel zu sehen, aber die geschwärzten Flächen sind schon interessant. Im Mittelteil könnte sich dahinter der DDR2 DCT verstecken, an den Seiten könnte man sich noch ein 4tes HT Interface denken (irgendwas war da doch noch mit Cray... Das ganze mit HT2@1.4GHz und man kann wunderbar richtig große und sehr gut skalierende Systeme bauen...

@Opteron
> Naja es wird ja wohl eine Socket 940 Version geben, aber wie teilt sich dann das Interfaces auf ?

[ ] Jeder Kern einen Channel ?
[x] Einer beide Channels ?
[ ] Oder irgendwie "dynamisch"

Wobei man sich sehr gut vorstellen kann, das ein DC-Interface nur DDR1 und das andere nur DDR2 unterstützt.

Wie man an den Dual-Opteron-Boards, wo nur einer CPU am Speicher hängt, sieht man dass die Bandbreite eines DC-Speicherinterfaces groß genug ist um 2 Kerne ausreichend mit Daten zu versorgen. So gesehen würde es nur unnötig großen Layout/Verdrahtungsaufwand bedeuten ZWEI
DC Controller auf einem Dual-Core Die zu enablen.

@Shearer
>Interessant ist auch, das AMD keinen OneCore-Die mehr für die Opterons plant, es werden also alle Opterons auf Dual-Core umgestellt (zumindest nach heutiger Roadmap)

Wieso interessant? Ich wette darauf das AMD 05 nach wie vor Single-Core Opterons auf dem Markt anbieten wird und diese könnten durchaus von Singlecores abstammen.

Ich würde die Roadmap mal so interpretieren:

AMD wird vier gänzlich unterschiedliche* Produktlinien haben:

1) Legacy K7 Kern: Aus dieses Dies werden GeodeNX/Duron/Sempron Socket A/Athlon XP/MP gemacht

2) Low cost AMD64 Kern (1HT/512k L2 on DIE): Aus diesen Dies werden Athlon 64, Sempron und ein Teil der Mobile Athlon 64 Reihe abstammen. Coretechnisch wird der 130nm Newcastle durch den 90nm Winchester = Oakvile = Palermo = Georgetown = Sonora ersetzt werden.

3) Full AMD64 Kern (3HT/1MB on DIE): Aus diesen Dies kommen werden Opterons/Athlon 64 FX und ein teil der Mobile Athlon 64 kommen. Umstieg vom 130nm Sledgehammer = Clawhammer Kern auf 90nm Athens = Troy = Venus = San Diego

4) Dual AMD64 Kern (3-4HT/2x1MB on DIE): Darauf werden die Dualcore Produkte basieren (Egypt = Italy = Denmark = Toledo)

Produktlinien 3) und 4) gehören in den Premium Price Sektor. Dort wird man zu Beginn sicher keine so großen Stückzahlen haben so das ich mir schon vorstellen könnte, dass AMD beide Linien im Wechsel betreiben wird bis FAB36 fertig ist.

* Damit meine ich absolut unterschiedliche DIE Layouts/Größen

Ich interpretiere die Roadmap so, dass AMD von Single- auf Dual-Core umstellt, ansonsten würde der SingleCore in der Zeitline weiterlaufen, wie bspw. der Athlon MP (as market requires)

Interessant wäre zudem, wieviel Cores AMD denn dann nun tatsächlich in der Produktion haben will.

Derzeit haben sie Imho folgende Cores, die für unterschiedlichste Produkte eingesetzt werden:

T-Bred 256K
Barton 512K
Newcastle 512K
Sledgehammer 1024K

mit der Umstellung kommen dann nochmal 2 Cores hinzu (denen AMD 5 Namen gibt )

Shearer

Die vielen Codenamen erinnern mich gerade an einen gewissen User "Clawhammer" auf athlon.de, welcher meinte, daß jeder Codename (damals noch die beiden Hammer) ein unterschiedliches Die bedeuten. Das wären nun und erst Recht ab 90nm aber schon sehr viele verschiedene gleichzeitig hergestellte Dice für AMD gegenüber "ruhigen" K6-Zeiten

Mal eine ganz andere Theorie: Es könnte ja auch denkbar sein, dass die beiden Cores einen gemeinsamen DC-Speicherkontroller bekommen zusammen mit einem neuen Data-Prefetch, und dass dieser die Daten dann "intelligent" an die Cores verteilt. Dann bräuchte auch die Software diese Aufgabe nicht mehr zu erledigen, was sicherlich etwas schneller sein dürfte.
Das was mir an dieser Theorie nicht so ganz gefällt ist, dass Opteron und Anthlon 64/FX ja schon recht gut vom Dual-Channel profitieren. Dadurch ergibt sich die Frage, ob eine solche Lösung die CPU etwas bremsen würde.

Original geschrieben von Nightshift Das was mir an dieser Theorie nicht so ganz gefällt ist, dass Opteron und Anthlon 64/FX ja schon recht gut vom Dual-Channel profitieren. Dadurch ergibt sich die Frage, ob eine solche Lösung die CPU etwas bremsen würde. [/B]

Zum Vergrößern anklicken....

Zunächst sollte man mal die praktischen Aspekte beleuchten:
Ein Doppel-Dual-Channel-Interface ließe sich mit Sicherheit nicht gerade einfach auf Motherboards drauf bauen. Von den um die 1500 Leitungen mit denen die CPU gefüttert werden müsste erst mal abgesehen, stellt sich zumindest mir die Frage, wie die entsprechenden Speichersockel auf ein 4-fach oder gar 8-fach System integriert werden könnten.

Zudem bleibt das Argument von Fred Weber: Bandbreite steht ausreichend zur Verfügung, nur die Rechenleistung nicht.

@Nightshift

> Es könnte ja auch denkbar sein, dass die beiden Cores einen gemeinsamen DC-Speicherkontroller bekommen

Das ist eh klar, die Frage ist aber WIE der Memorycontroller an beide Cores angeschlossen ist. Die natürliche Variante wäre, dass die beiden Cores per SRQ and die XBAR angeschlossen sind und DORT der (aktive) Speicherkontroller hängt. Ich mein das in etwa so:


Es ist sehr unwahrscheinlich das AMD die Crossbar ändert -- das ist die eigentliche Schaltzentrale was IO anbelangt! Bedenke schlieslich muss das Memory ja auch per HT ansprechbar sein (=>z.B. für AGP Transfers)! AMD hat die SRQ von haus aus auf zwei Cores vorbereitet, deshalb ist es nur logisch anzunehmen, dass sie diese Architektur auch verwenden werden.

> zusammen mit einem neuen Data-Prefetch, und dass dieser die Daten dann "intelligent" an die Cores verteilt. Dann bräuchte auch die Software diese Aufgabe nicht mehr zu erledigen, was sicherlich etwas schneller sein dürfte.

Was meinst du den damit Letztendlich legt die Software immer fest von welcher Speicherstelle (Adresse) Daten gelesen/geschrieben werden. Ein Prefetcher kann nur raten bzw manchmal sogar wissen woher/wohin die nächsten Daten kommen/gehn könnten und diesen Speicherzugriff vorbereiten - inteligent verteilen kann er sie aber nicht.

> Das was mir an dieser Theorie nicht so ganz gefällt ist, dass Opteron und Anthlon 64/FX ja schon recht gut vom Dual-Channel profitieren.

Schau dir mal Benches mit Single vs. Dual Channel an... Es gibt kaum Szenarien wo das DC Interface seine Bandbreite ausspielen kann. Siehe auch Seemans posting.

@HenryWince:
Dein ASCII-Schema kommt ja sehr nahe an das Original heran

So, wie es geplant ist, macht es Sinn. Nicht die CPUs entscheiden über die Nutzung des MCT und die Speicherzugriffe, sondern die SRQ. Und da es eine Queue ist, werden wohl im Normalfall die ersten Anfragen zuerst abgearbeitet. Evtl. wird da auch optimiert (einige AMD Patente weisen in die Richtung), so daß z.B. zwei auseinanderliegende Zugriffe auf eine Speicherseite trotzdem hintereinander ausgeführt werden.

Dual Channel hilft bei dual cores wahrscheinlich sogar etwas mehr als bei single cores. Möglicher Grund: Bei konkurrierenden Zugriffen ist die Wartezeit der CPUs geringer, da der jeweils konkurrierende Zugriff schneller fertig übertragen wird.

Ausführlich:
Bei single core braucht die CPU ein Datum vom RAM, der MCT holt die entsprechende Cacheline (mit dem angeforderten Datum zuerst) und durch weitere Ausführung von Programmcode, Compileroptimierungen für Datenlokalität (d.h., es wird erstmal mit weiteren Daten dieser Cacheline gearbeitet) passiert es seltener, daß gleich eine weitere Cacheline gebraucht wird. Bei dual core ist es aber viel wahrscheinlicher, da ja der zweite Core nicht weiß, welche Daten der erste grad lud und bearbeitet, somit kann er keinen Nutzen daraus ziehen und fordert zu ca. 99.99% eine andere Cacheline an, weil er mit anderen Daten arbeitet.

> Dein ASCII-Schema kommt ja sehr nahe an das Original heran

Sollte es auch!

> ..passiert es seltener, daß gleich eine weitere Cacheline gebraucht wird. Bei dual core ist es aber viel wahrscheinlicher, da ja der zweite Core nicht weiß, welche Daten der erste grad lud und bearbeitet, somit kann er keinen Nutzen daraus ziehen und fordert zu ca. 99.99% eine andere Cacheline an, weil er mit anderen Daten arbeitet.

Jep, trozdem ist die durchschnittliche Wahrscheinlichkeit für einen Memory-Access in dem darauffolgenden Speicherabschnitt recht groß (bei Code sogar ganz klar). Evtl. kann es dann schon Sinn machen, dass der MCT ein entsprechendes Bank-Open Command vorausschauend macht. Immerhin kann der MCT ja einige offene Bänke verwalten.

BTW. Wenn beide Cores auf dem selben Speicher arbeiten gibts keine doppelten Zugriffe, dafür sorgt ja die Cache-Snooping Logik. Ich bin schon mal gespannt wie schnell ein Zugriff auf Daten im Cache der anderen CPU sein wird -- das dürfte gut abgehen, denn der HT Overhead fällt ja komplett weg.

Original geschrieben von HenryWince
Jep, trozdem ist die durchschnittliche Wahrscheinlichkeit für einen Memory-Access in dem darauffolgenden Speicherabschnitt recht groß (bei Code sogar ganz klar). Evtl. kann es dann schon Sinn machen, dass der MCT ein entsprechendes Bank-Open Command vorausschauend macht. Immerhin kann der MCT ja einige offene Bänke verwalten.

Zum Vergrößern anklicken....

Das sprach ich schon mit:

Evtl. wird da auch optimiert (einige AMD Patente weisen in die Richtung), so daß z.B. zwei auseinanderliegende Zugriffe auf eine Speicherseite trotzdem hintereinander ausgeführt werden.

Zum Vergrößern anklicken....

an.

Original geschrieben von HenryWince
BTW. Wenn beide Cores auf dem selben Speicher arbeiten gibts keine doppelten Zugriffe, dafür sorgt ja die Cache-Snooping Logik. Ich bin schon mal gespannt wie schnell ein Zugriff auf Daten im Cache der anderen CPU sein wird -- das dürfte gut abgehen, denn der HT Overhead fällt ja komplett weg.

Zum Vergrößern anklicken....

Snooping ist klar. Ich vermute, ein Zugriff auf den jeweils anderen Cache (sofern es so realisiert wurde) über die SRQ könnte mit 2-3x der Zugriffszeit auf den eigenen L2 vergleichbar sein.

PS: Ist das in deinem Avatar ein Power5?

Ja, dass es sowieso maximal ein DC-Controller war schon klar, nur wurde hier ein, zwei Mal für jeden Core ein DC-Controller angedacht. Wie allerdings was auch schon gesagt wurde ist dies nicht ohne Sockelwechsel möglich.
Ich fragte mich einfach nur: Gibt es einen DC-Controller für beide Cores zusammen, oder für jeden Core einen SC-Controller?

Was meinst du den damit Letztendlich legt die Software immer fest von welcher Speicherstelle (Adresse) Daten gelesen/geschrieben werden. Ein Prefetcher kann nur raten bzw manchmal sogar wissen woher/wohin die nächsten Daten kommen/gehn könnten und diesen Speicherzugriff vorbereiten - inteligent verteilen kann er sie aber nicht.

Zum Vergrößern anklicken....

ja, dass die Software dies immer festlegt ist klar, und auch, dass das Data-Prefetch nach gewissen Algorithmen geschieht und so Daten einliest die wahrscheinlich als nächstes gebraucht werden können. Dass dann dabei sowohl Daten sind die nützlich sind oder eben auch nicht ist logisch. Auch klar, dass der Prefetcher selber nichts verteilt, das müsste eine selbstständige Logikeinheit.

Und mit "intelligent" verteilen war folgendes gemeint: "Normale" Software ist ja erstmal für single-thread konzipiert, es sei denn man denkt direkt an smp oder smt. Mit Einzug von HT in die P4-Reihe ist aber auch vermehrt Software umgeschrieben worden, so dass sie ihre Threads auf die beiden virtuellen CPUs des P4s verteilen konnte, und davon profitiert.
Man nehme nun eine CPU mit zwei Cores, und diese bekommt eine Logik, die selber die Threads intern verteilt, diese Aufgabe also den einzelnen Programmen/der Software abnimmt, und somit bei jeglicher Software vom Dual-Core-Prinzip profitieren kann, und nicht nur bei extra dafür geschriebener Sofware. Damit würde Software nicht mehr extra auf dual-core zugeschnitten werden, sondern könnte auch so davon profitieren.
(Hat gaaaaarnichts mit dem Prefetcher zu tun, war nur mit in dem Satz zusammengemogelt )

Nur gibt das dann weitere Probleme? Ein solcher Verteilungsalgorithmus muss absolut ausgereift sein, sonst schadet er mehr als dass er nutzt.
(Klar war auch, dass die SRQ an den X-Bar angeschlossen ist und nicht der Core selber.)Aber kann das die SRQ? Ich denke mal eher nicht.

Schau dir mal Benches mit Single vs. Dual Channel an... Es gibt kaum Szenarien wo das DC Interface seine Bandbreite ausspielen kann. Siehe auch Seemans posting.

Zum Vergrößern anklicken....

Ja, nur fragte ich mich einfach, ob sich das nicht mit einem Dual-Core ändert....
Das Einsicht vermittelnde Interview mit Webber hatte ich auch zu dem Zeitpunkt noch nicht gelesen.
Aber die Frage ist damit geklärt, wenn die AMD-Ingenieure sagen, dass ein SC-Interface für Dual-Core reicht, dann nehme ich denen das einfach mal, gnädiger Weise aufgrund deutlich geringerer Kompetenz und Erfahrung, so ab.