Spekulationsthread: Was kommt 2011+

@28nm-HKGM von GF:

Globalfoundries würde kaum im Nachhinein die Kapazitätsplanungen weiter ausdehen, hätten sie Zweifel, dass diese auch benötigt werden. Dass nun jetzt im Nachhinein gleich weitere Erweiterungen geplant sind, dürfte wohl bedeuten, dass GF von seinen entwickelten Prozessen sehr überzeugt sein dürfte. Man hat vermutlich abgewartet, wie GF die 28nm-Schwierigkeiten löst. Und vermutlich hat man dieses sehr gut gelöst.

==> Meine Schlussfolgerung: GFs 32nm-SOI als auch 28nm-HKGM-Prozesse sollten SEHR GUT werden!

Wir hatten schon mal diese Diskussion, ob GFs Gate-First Vor- oder eher Nachteile gegenüber Gate-Last hat. Der entscheidende Vorteil ist im letzten Slide (hier: http://www.anandtech.com/show/3750/globalfoundries-plans-to-expand-dresden-and-ny-fabs-in-anticipation-of-2822nm) erwähnt:

"Design Compatibility with 45/40nm" ;D

Das sollte bedeuten, dass AMD seine CPUs als auch GPUs auch viel schneller/einfacher/günstiger auf 28nm-HKMG portieren können sollte, als sie etwa für den 28nm-Prozess bei TSMC bräuchten.

Zudem heißt es in dem Slide zum 28nm-HKMG:
"Ramping Production in 2010"
 
Dresdenboy schrieb:
Weitere Infos zu GF:
http://pc.watch.impress.co.jp/docs/column/kaigai/20100608_372754.html
Zum Vergrößern anklicken....
Hmm da ist mal wieder Zeit für ne Milchmädchenrechnung. Denn auf einer Folie steht, dass die 32nm SOI HKMG "performance" 50% besser als bei 45nm wäre.

Performance wird wie immer der übliche Mix aus Takt & Verlustleistung sein. Bleiben wir also also mal in den gleichen TDP Bändern, und kalkulieren damit den Taktspielraum beim K10 Design:

Aktuell in 45nm gibts 45W Propus mit max. 2,4 GHz. +50% ergäben damit dann 3,6 GHz für Llano (ohne GPU). Für die Sabine Desktop Plattform sollte man mit mehr TDP die 3,6 GHz inkl. GPU locker erreichen.

Für <30W Mobile CPUs wird man wohl weiterhin unter 3 GHz bleiben müssen. Aber naja, immerhin hat man ja die 4 Kerne plus GPU, ist ja auch was.

Ach und noch zum Spass das Ganze noch bei 125W:
z.Zt. 3,4 GHz +50% -> 5,1 GHz *lol*

Also da sollten doch für Zambezi 4 GHz locker-flockig drin sein, auch wenn so ein Bulldozer Modul "etwas" dicker als ein K10 Kern ausfallen wird *buck*

ciao

Alex
 
Zuletzt bearbeitet:
Opteron schrieb:
Performance wird wie immer der übliche Mix aus Takt & Verlustleistung sein. Bleiben wir also also mal in den gleichen TDP Bändern, und kalkulieren damit den Taktspielraum beim K10 Design:
Zum Vergrößern anklicken....
Ich bilde mir ein, nicht Performance-Steigerung sondern Energie-Einsparungen gelesen zu haben.
Bei 40% Energie-Einsparungen hat das dann s0 20-30% mehr Takt/Transistoren usw bedeutet.

Immerhin kommt ja High-K & 32nm und eventuell Ultra-Low-K gleichzeitig und da erwarte ich mir schon einen größeren Sprung als üblich. Vorallem, wenn man sah, wie viel High-K bei Intel und Ultra-Low-K bei Thuban gebracht hat.

Oder ist das wirklich nur Einbildung?
 
Zuletzt bearbeitet:
Opteron schrieb:
Performance wird wie immer der übliche Mix aus Takt & Verlustleistung sein.
Zum Vergrößern anklicken....
Ist das so üblich? Bei Performance gehe ich eigentlich immer von den Schaltzeiten der Transistoren aus. Über Takt und Verlustleistung der finalen Prozessoren sagt das erstmal recht wenig.
 
Alles was ich finden konnte.

Slide103.JPG


Slide161.JPG


Slide163.JPG


file.php


Na ja, da werden immer so von ca. 20% performance-Steigerung berichtet.
Also, da hören sich die 50% für 32nm mal nicht so schlecht an. Die Frage bleibt, ob die gleich am Anfang erreicht werden.

Sind eigentlich schon die Air-Caps umgesetzt worden?
Metal-Gates kommen AFAIK mit 32nm.

PS: jetzt sehe ich gerade, wo man 2007 auch nur von 20% "Mehr"-Performance von 32nm ausging.
Vielleicht war das damals so, weil man vielleicht dachte, z.B. ULK in 45nm in allen Dies zu produzieren, sowie High-K integiert zu haben.

Also, statt von 45nm-Ultra-Low-K & High-K/Metal-Gates zu 32nm-Air-Gaps mit 20%-MehrPerformance, dürfte es zu
45nm zu 32nm-Ultra-Low-K & High-K/Metal-Gates mit 50% Mehr-Performance gemeint sein, da ULK noch nicht weitflächig eingesetzt wird.
Ich würde mal daumen-mal-Pi schätzen, dass die Zeit für die Air-Caps-Integration zu kurz war und eventuell wie ULK als 32nm-Option kommt oder erst mit 22nm.
 
Zuletzt bearbeitet:
@mibo:
Stimmt. Aber Gaps und Caps sind verschiedene Dinge.

Opteron schrieb:
Hmm .. 2005, war das nicht die Zeit, als Andy Glew bei AMD war ?
Zum Vergrößern anklicken....
Ja ja, das passt alles schön ins Konzept ;)
Noch etwas Background von dem, der das bei AMD gemacht hat (hier aber mit Intel):
http://www.ece.cmu.edu/~omutlu/pub/mutlu_hpca03_talk.pdf

Ich habe doch nur mal geschaut, wofür 4 OOO pipelines ohne SMT u. Checkpoints gut sein könnten. Siehe auch Diskussionen bei AMDZone und SemiAccurate.

Übrigens war der Ontario-Wafer in einer Box, wie sie auch bei GF benutzt wird (zu sehen z.B. bei Fudzillas 32nm GF Report). Hans spekuliert doch schon, dass es 28 nm Dies waren.
 
Zuletzt bearbeitet:
mibo schrieb:
Ist nicht die Kapazität dieser Luft-Spalten das Interessante? Oder, welchem Zweck dienen die noch?
Zum Vergrößern anklicken....

Das ist teilweise richtig. Luft stellt ein Ultra-Low-k Material dar. Dadurch können die parasitären Leitungskapazitäten gesenkt werden und damit die Taktfrequenz erhöht werden. Allerdings heißt es nicht "Caps" da die Kondensatorwirkung nur parasitär ist und man diese eher versucht zu vermeiden, als mit dieser zu arbeiten.
 
Lynxeye schrieb:
Das ist teilweise richtig. Luft stellt ein Ultra-Low-k Material dar. Dadurch können die parasitären Leitungskapazitäten gesenkt werden und damit die Taktfrequenz erhöht werden. Allerdings heißt es nicht "Caps" da die Kondensatorwirkung nur parasitär ist und man diese eher versucht zu vermeiden, als mit dieser zu arbeiten.
Zum Vergrößern anklicken....

Danke für die Erklärung.
Ich dachte, dass man deshalb die air gaps auch als caps bezeichnet, weil deren Kapazität das Wichtige ist. Aber Deine Erklärung ergibt Sinn.
 
Dresdenboy schrieb:
Übrigens war der Ontario-Wafer in einer Box, wie sie auch bei GF benutzt wird (zu sehen z.B. bei Fudzillas 32nm GF Report). Hans spekuliert doch schon, dass es 28 nm Dies waren.
Zum Vergrößern anklicken....

Auch GF bietet einen 40 nm Low Power Prozess an, der laut Roadmap seit Anfang dieses Quartals in risk production ist.
 
gehört nicht zum thema aber egal

mich würde mal interessieren welche Architektur eigentlich ursprünglich nach dem K8 geplant war, K10 ist ja nur ein verbesserter K8, AMD soll ja einige neue Architekturen unabhängig von Bulldozer verworfen haben, ist dazu noch einiges bekannt?
 
Duplex schrieb:
gehört nicht zum thema aber egal

mich würde mal interessieren welche Architektur eigentlich ursprünglich nach dem K8 geplant war, K10 ist ja nur ein verbesserter K8, AMD soll ja einige neue Architekturen unabhängig von Bulldozer verworfen haben, ist dazu noch einiges bekannt?
Zum Vergrößern anklicken....

Laut Charlie gab es bei bei AMD zwei Architekturen zwischen Hammer und Barcelona, die beide aber aufgegeben wurden.

Die eine Architektur zielte darauf einen Netburst ähnlichen Takt mit der selben bis höheren IPC eines K8 zu erreichen. Das ist aber, offensichtlich, an der selben Stromverbrauchs- und Wärmeproblematik gescheitert die später auch Prescott den Garaus machte.

Die nächste war eine sehr komplexe, auf massiv parallele Programme ausgelegte Architekur, die FB-DIMM verwendet hätte. Allerdings waren FB-DIMMs dann doof :P, die Single-Thread Performance zu niedrig und der Stromverbrauch zu hoch, also hat man den Stecker gezogen.
 
also 2 uninteressante Architekturen, der P4 hat es gezeigt und auf der anderen Seite hatte der K10 zuwenig IPC, 3,6 Ghz @140w ist das max. beim K10.5 @45nm, höhere Taktraten sind nur in 32nm möglich. Ich bin schon gespannt ob ein Llano ohne IGP mit 4 Ghz @125w kommt...
 
Triskaine schrieb:
Laut Charlie gab es bei bei AMD zwei Architekturen zwischen Hammer und Barcelona, die beide aber aufgegeben wurden.

Die eine Architektur zielte darauf einen Netburst ähnlichen Takt mit der selben bis höheren IPC eines K8 zu erreichen. Das ist aber, offensichtlich, an der selben Stromverbrauchs- und Wärmeproblematik gescheitert die später auch Prescott den Garaus machte.

Die nächste war eine sehr komplexe, auf massiv parallele Programme ausgelegte Architekur, die FB-DIMM verwendet hätte. Allerdings waren FB-DIMMs dann doof :P, die Single-Thread Performance zu niedrig und der Stromverbrauch zu hoch, also hat man den Stecker gezogen.
Zum Vergrößern anklicken....

Wobei man nicht vergessen sollte, dass trotz allem die besten Ideen dieser Architekturen am ende im Bulldozer stecken werden. zum Beispiel kann das Design mit shared FP von der zweiten genannten Architektur stammen und der ersten genannten könnte Bulldozer einige low latency Strukturen verdanken ... es kursierte ja auch etwas von höherem Takt an bestimmten Einheiten des BD.

Was ich sagen will ist nur, dass nicht alles von vorherigen versuchen für umsonst war, es gibt den Ingenieuren einen viel besseren Überblick über was geht und was nicht und einen Schatz an neuen guten Ideen die man jetzt in den BD bauen kann.
 
Die Compilerbauer plaudern wieder mal aus dem Nähkästchen:
Hi,
We are in the process of adding a feature to GCC to take advantage of a new hardware feature in the latest AMD micro processor. This feature requires a certain mix, ordering and alignments in instruction sequences to obtain the expected hardware performance.

I am asking the community to review this high level implementation design and give me direction or advice.

The new hardware issues two windows of the size N bytes of instructions in every cycle. It goes into accelerate mode if the windows have the right combination of instructions or alignments. Our goal is to maximize the IPC by proper instruction scheduling and alignments.

Here is a summary of the most important requirements:

a) Maximum of N instructions per window.

b) An instruction may cross the first window.

c) Each window can have maximum of x memory loads and y memory stores .

d) The total number of immediate constants in the instructions of a window should not exceed k.

e) The first window must be aligned on 16 byte boundary.

f) A Window set terminates when a branch exists in a window.

g) The number of allowed prefixes varies for instructions.

h) A window set needs to be padded by prefixes in instructions or terminated by nops to ensure adherence to the rules.
Zum Vergrößern anklicken....
http://gcc.gnu.org/ml/gcc/2010-06/msg00402.html

ciao

Alex
 
Dresdenboy schrieb:
Cool. Das GCC Posting habe ich mir mal ausgedruckt für unterwegs. V.a.: Was ist der "accelerate mode"? High frequency?
Zum Vergrößern anklicken....
Ist die Frage, über was sich das "window" nun erstreckt ... nur Fetch oder Fetch+Decode ?
In letzterem Fall könnte man sich überlegen, dass er FastPath Instr. damit meint. Aber wenns nur um Fetch geht ... *noahnung*
Ich les mal bei Gelegenheit nochmal das Decoder Patent durch, vielleicht findet sich da was.
 
Mag sich jetzt ein bisschen blauäugig anhören - aber geht es, dass man eine CPU von OoO auf In-Order umschaltet, um sich Shadow-Register/Register Renaming/Reordering..... zu sparen.

Während Phasen ohne Branches werden stur alle Execution Units ausgelastet, die Anordnung der Befehle wird statisch zur Compile-Time vorgegeben. Ein paar Pipeline-Stages werden übersprungen/kurzgeschlossen, weil sie nicht benötigt werden.
 

Ähnliche Themen

S
HP Victus Gaming Knaller, mit Phoenix aus der Asche?
Antworten
17
Aufrufe
2K
NEO83
NEO83
Onkel_Dithmeyer
News AMD APUs im Wandel der Zeit: Llano | A8-3870K
Antworten
19
Aufrufe
3K
Onkel_Dithmeyer
Onkel_Dithmeyer
E555user
News CDNA Whitepaper - Unterschiede zu RDNA
Antworten
2
Aufrufe
1K
E555user
E555user
pipin
Kontron COM Express® Module mit AMD Ryzen™ Embedded R1000 SoC
Antworten
0
Aufrufe
793
pipin
pipin
eratte
News Intel/ARM/AMD: Sicherheitslücken Meltdown & Spectre V1, V2 etc. (Links in Post 1)
29 30 31
Antworten
763
Aufrufe
100K
drSeehas
D
Zurück
Oben Unten