AMD K12 -Spekulation

Opteron

Redaktion
☆☆☆☆☆☆
Mitglied seit
13.08.2002
Beiträge
23.645
Renomée
2.254
  • SIMAP Race
  • Spinhenge ESL
  • BOINC Pentathlon 2012
Hier darf über den kommenden AMD K12 spekuliert werden.

Meldung dazu:
AMD aktualisiert Langzeitplanung: AMD K12 in Arbeit | Planet 3DNow!.

4099__x_amd_core_update_2014_033.png


Eventuelle Anhaltspunkte die man hat:

- Apples 6way-Cyclone-Design, eventuell im Frühstadium noch von Keller beeinflusst
- Aussage Kellers, dass die Ausführungseinheiten ("engine") des ARM-Kern größer als der neue x86-Kern werden würde
- Betonung Kellers, dass man den besten Kern entwerfen möchte und sowohl Bulldozer als auch Jaguar-Techniken (high-density Design) verwenden möchte
- Lisa Su verwies bei Fragen nach Finfet-Produkten auf die Kerne für 2016 (also K12 und den neuen x86)

Gerüchte aus dubiosen Quellen:
- Angeblich verwendet AMD zukünftig SMT/Hyperthreading

Spekulationsvorschlag:
Ein Zwitter aus BD und Jaguar ist zwangsläufig irgendwo zw. K10 und Intel Core, ein mittelgroßer Kern mit viel, aber nicht zuviel Takt.

Eckdaten wären ca.:
Relativ breit: 8way (entspräche ~4way bei x86), überschüssige Einheiten durch SMT beschäftigen
Taktziel: ~4 Ghz (sollte in 14nm Finfets nicht das Maximum, sondern eher konservativ sein)
ALUs: 4 Pipes
AGUs: 3 Pipes (Apple hat 2, da wären 3 nicht verkehrt, auch für SMT)
FP: 3 128 bit Pipes (Kaveri zeigt ja, dass 3 Pipes reichen und 4 zuviel waren ^^)
Cache: 2x32kB-64kB

Zum Vergleich: Alpha EV8:
ALUs: 8 Pipes (vermutlich inkl. 4 AGUs)
Load-Store: je 2
FP: 4
Cache: 2x64kB
 
Eckdaten wären ca.:
Relativ breit: 8way (entspräche ~4way bei x86), überschüssige Einheiten durch SMT beschäftigen
Taktziel: ~4 Ghz (sollte in 14nm Finfets nicht das Maximum, sondern eher konservativ sein)
ALUs: 4 Pipes
AGUs: 3 Pipes (Apple hat 2, da wären 3 nicht verkehrt, auch für SMT)
FP: 3 128 bit Pipes (Kaveri zeigt ja, dass 3 Pipes reichen und 4 zuviel waren ^^)
Cache: 2x32kB-64kB
Das würde schonmal gut aussehen, bei einem breiten Design wie Intel reichen dann auch 4 Kerne bei den APUs aus, wenn die dann auf i5-4670 Niveau liegen sehe ich kein Problem, bis dahin gibt es bestimmt auch schon GCN3, hoffentlich schafft man es dann endlich richtig Leistungsstarke APUs zu präsentieren.
 
Auf der ALU Ebene sollte x86 relativ ähnlich zu ARM sein. Die x86 Decoder generieren ja schließlich in der Regel 1-2 µOPs pro x86 Instruktionen, manchmal sogar deutlich mehr.
Da die Decoder bei ARM deutlich simpler ausfallen sollten, kann man sich dann durchaus auch 8 statt 4 leisten. Ob man so viele braucht ist die nächste Frage.
Wenn bei x86 keine 4 ALUs ausgelastet werden können, wird das mit ARM allerdings auch nicht plötzlich besser.
Wenn kein SMT eingesetzt werden soll würde ich eher schätzen, dass von jeder Pipeline max 3 Stück vorhanden sind und selbst mit SMT sollte das eigentlich noch ausreichend sein.
Bei den Caches würde ich schätzen, dass es sich an Jaguar orientiert, wobei der L2 hoffentlich mit vollem Kern Takt laufen wird.

Ich hoffe bei der Pipeline Länge bleibt man noch etwas konservativ und geht nicht zu sehr in Richtung Bulldozer.
 
Taktziel: ~4 Ghz (sollte in 14nm Finfets nicht das Maximum, sondern eher konservativ sein)

4 GHz würde ich nicht erwarten wegen thermischer Probleme. Sieht man ja auch bei Intel, die ja schon FinFet verwenden.
 
Vielleicht schafft es AMD wie Intel Gleitkomma-Berechnungen und Ganzzahl-Berechnungen in den gleichen Ausführungseinheiten zu berechnen. Das würden die Kerne noch etwas schrumpfen.
 
4 GHz würde ich nicht erwarten wegen thermischer Probleme. Sieht man ja auch bei Intel, die ja schon FinFet verwenden.
Das ist bei Intel kein Problem, die verwenden da nur ne billige Leitpaste unter dem Deckel, das ist das Hauptproblem. Soll angeblich mit dem in Kürze erscheinenden Haswell-Refresh behoben sein.

Vielleicht schafft es AMD wie Intel Gleitkomma-Berechnungen und Ganzzahl-Berechnungen in den gleichen Ausführungseinheiten zu berechnen. Das würden die Kerne noch etwas schrumpfen.
Das "Risiko" ist wohl eher gering. Intel hat die immer noch unterschiedlichen Ausführungseinheiten "nur" an den gleichen Ports hängen. Alle sind mit 128bit angebunden, wenn jetz aber ein 256bit Befehl kommt, werden die 128bit der jeweils anderen Ausführungseinheit genutzt. Da die Einheiten am gleichen Port hängen kann pro gleichen Takt ja kein Befehl für die andere kommen.

Glaube aber nicht, dass das so kommen wird, den alten DEC-Leute wurde wohl eingebleut INT+FP zu trennen, alle AMDs seit dem K7 waren so geplant. Dass sie das nun umwerfen glaub ich nicht. Theoretisch sollte ne bessere Trennung auch für SMT besser sein, denn dann hat man automatisch meh Ports, die pro Takt dann häufiger frei sind. Denke mal die DEC EV8-Entwickler kamen da nicht von ungefähr drauf.

Intel hat beim Haswell ja auch nen neuen INT-Port angeflanscht, damit das Design besser balanciert ist.

Denke bei nem nagelneuen Design wird man wieder sauber trennen. Intels Sache bei 256bit ist sicherlich praktisch und spart ne Menge Leitungen, aber die ARM-ISA kennt keine 256bit Befehle, also stellt sich das Problem sowieso nicht.
 
Mit K12 kommt vermutlich mit ECC Unterstützung, dazu Skybridge als gemeinsamer Sockel. Interessant könnte sein ob man damit als Privatkunde wieder wie bei AM3 die Möglichkeit hat günstig Boards mit ECC zu bekommen.
 
4 GHz würde ich nicht erwarten wegen thermischer Probleme. Sieht man ja auch bei Intel, die ja schon FinFet verwenden.

Wenn es einen 14nm SHP-Prozess gibt, wird das kein Problem. Wenn nicht, dann werden 4GHz schwer.
 
Das ist bei Intel kein Problem, die verwenden da nur ne billige Leitpaste unter dem Deckel, das ist das Hauptproblem. Soll angeblich mit dem in Kürze erscheinenden Haswell-Refresh behoben sein.
Wie WLP ist überdurchschnittlich und nicht das Problem. Schwierig ist der Abstand zwischen Die und IHS, der Spalt ist etwas zu groß.
 
Ich finde AMD sollte nicht zuviel Ressourcen auf ARM verschwenden. x86 ist noch längst nicht tot. Dafür ist über die Jahrzehnte eine viel zu breite Softwarepalette entstanden. Die wirft man nicht einfach so über Bord; zumal es bei ARM in der Hinsicht teils noch etwas mau aussieht. Und wenn sich AMD auf ARM einlässt, müssen sie sich früher und später mit Größen wie Samsung, Qualcomm und insbesondere Billiganbietern wie MediaTek anlegen. Da ist im Vergleich Intel das geringere Übel, da Intel behäbig und berechenbar agiert. Ich denke nicht, dass AMD sich solche Parallelentwicklungen leisten kann.

Ergänzung: Den Opteron X als zweites Standbein finde ich nicht verkehrt, aber ich denke AMD sollte mir ARM nicht in die "Breite" wechseln.
 
Was ist, wenn es AMD schafft "irgendwie" einen Zwitter aus x86 und ARM zu bauen?
Also eine CPU, die beides kann.
Zutrauen würde ich denen das.

Der Anfang im Beema mit Arm-Kern zum Testen und so?
So ala Story wie in der Radeon 7790 mit dem nicht frei geschalteten True Audio...
 
@Raspo: Solche Anläufe mit einer x86 Emulation in Hardware gab es immer wieder, sie sind jedoch meist gescheitert.

Der erfolgreichste war noch der Transmeta Efficeon. Allerdings basierte dieser auf VLIW und nicht auf RISC wie ARM.
 
@SPINA
Das halte ich für zu kurzsichtig gedacht.
Realistisch betrachtet hat sich schn seit Jahren oder gar Jahrzehnten gezeigt das man im x86er Markt so "wichtig" für die Industrie ist das die Eigenentwicklungen ohnehin nicht beachtet werden und vor allem wichtige Kunden nach Intels Pfeife tanzen. Im Gegenzug ist die ARM Architektur aber vor allem im Handy und Smartphone Bereich sehr weit verbreitet wärend Intel seine x86er Produkte in diesem Bereich ordentlich subventionieren muss.
ganz hart ausgedrückt kann man dann auch sagen das man sich das Geld für Eigenentwicklungen bei der x86er Architektur auch sparen und dieses in ARM Produkte investieren kann.

AMD macht in meinen Augen damit einen wichtigen Schritt um erfolgreicher zu werden. Sich vom x86er Sektor unabhängiger zu machen anstatt dort das Geld für Entwicklungen zu verbrennen die ohnehin nicht beachtet werden. Auf dem ARM Sektor gibt es zumindest einen halbwegs gesunden Konkurrenzkampf und Wettbewerb.
 
An einen ISA-Zwitter, der immer beides versteht, glaub ich nicht. Aber da AMD ja den Kram immer relativ modular hält, würd ich dennoch davon ausgehen, dass die CPUs sich nur wenig unterscheiden. Ich verstehe, warum man das macht. Man möchte alle Märkte, die irgendwie möglich sind abdecken.
Ich würd auch nicht eine ISA bevorzugen, niemand weiss, wie sich das weiter entwickeln wird. x86 wird man aus den Consumer-PCs nicht herausbekommen, genausowenig wie man ARMs in Smartphones ersetzen kann. Aber alle anderen Märkte sind für beide ISAs offen und keiner weiss, wie die sich weiter entwickeln. AMD tut gut daran beides zu haben.
 
Zuletzt bearbeitet:
Wie ich schonmal anmerkte, arbeiten die heutigen CPUs im Kern nicht ohnehin nach dem Risc Prinzip und der Code wird vom Decoder entsprechend vorgekaut?
So gesehen könnte ich mir durchaus vorstellen das man dies nach dem Sammeln von entsprechender Erfahrung mittel bis langfristig zumindest mit getrennten Decodern realisieren könnte, welche langfristig dann fusionieren könnten. Dann könnten der Code zwar vielleicht nicht parallel in einem Kern verarbeitet werden aber wenn genug Kerne zur Verfügung stünden wäre dies auch garnicht nötig. dann arbeiten ebend x Kerne mit dem x86er Code wärend der Rest für ARM Code zur Verfügung stehen würde.

Ist das jetzt zu viel Phantasie meinerseits oder ein durchaus machbares Produkt? :)
 
@sompe: Bei ARM sind jedoch viel schnellere Produktzyklen üblichen und der Wettbewerb mag gerechter sein, ist aber ungleich härter.
Ich sehe da keine guten Chancen für AMD abseits der Serverchips, wie dem neuen Opteron X. Letztere sind durchaus vielversprechend.

Bei Tablets und Smartphones dagegen wird AMD nicht punkten können. Weder mit Leistung, innovativen Features oder auch nur dem Preis.
AMD muss aufpassen, dass sie mit den ARM Kernen nicht zu viele der geschrumpften Entwicklerressourcen binden und darunter x86 leidet.

x86 hat seine Stellung sicher. Bei ARM ist das nicht gesagt. Da wäre noch MIPS. Man denke dabei vor allem an den Loongson III-B.
Die Stellung von ARM ist zur Zeit sehr stark, aber aus OEM Sicht ist ein Architekturwechsel in den üblichen Szenarien eher denkbar.
 
Zuletzt bearbeitet:
ARM und x86 auf einem Chip wäre doch letztlich nur eine weitere HSA-Variante. Mit GPUs hat man es auch hinbekommen, warum soll das nicht möglich sein?
 
@mariahellwig
möglich schon, aber welchen Sinn soll das ergeben? Entweder compiliere ich für ARM oder x86. Es bringt keinen Vorteil aus Softwaresicht beide Kerne gleichberechtigt zur Verfügung zu haben.
Wenn es ohne großen Overhead zu realisieren ist, würde es für AMD Sinn ergeben, da sie aus einem DIE beide Lager bedienen könnten. Der Chip würde dann aber im System nur als X86 oder ARM arbeiten (eventuell per BIOS auswählbar?).
GPUs machen Sinn, da sie einen anderen Aufbau haben und einen Mehrwert zur Beschleunigung von speziellem Code bringen, ebenso wie eine Videoeinheit, ein DSP, SSE, AVX etc.
ARM und X86 definieren aber beides nur eine CPU.
Wäre so, als wollte man Radeon und GForce Hardware auf einen Chip bringen.
 
HSA mit einem ARM, x86 und GPU ist schon möglich, aber das heißt nicht, dass die GPU dann auch x86 Befehle ausführt, oder eben der x86 Kern ARM Befehle.
Absolut unmöglich einen ARM/x86 Zwitterkern zu bauen ist es natürlich nicht, aber der Kern hätte massenweise Ressourcen die er nie gleichzeitig verwenden kann. Dadurch würden die Chips deutlich teurer als wenn man beide getrennt anbietet. Und letztlich kann dann der Kunde trotzdem nur entweder x86 oder ARM Befehle ausführen und nicht beides gleichzeitig. Das führt solch einen Kern dann ad absurdum.

Ich glaube auch nicht, dass AMD mit ihrem ARM Kern direkt auf Tablets abzielt. Zum einen wertet das natürlich die Server ARMs auf und zum Anderen ermöglicht sich dadurch vlt. auch ein neuer Markt and leistungsfähigeren Geräten, als Smartphones oder Tablets. Es muss ja auch nicht zwingenden Android auf ARM laufen. Ubuntu könnte hier interessante Geräte ermöglichen und Microsoft plant unter Umständen auch schon mehr in der Richtung.

Achtung wilde Spekulation:
Es wäre auch möglich dass AMD eine ARM APU mit relativ großer GPU für HPC entwickelt. Dies könnte man dann auch noch als GPU Karte verkaufen und das ganze als HSA Beschleuniger mit ARM Kern oder sowas in der Richtung vermarkten. Frei programmierbare DSPs haben wir auf den GPUs jetzt ja auch schon.^^
Oder sie nutzen den ARM Kern um die GPU Verwaltung vom Treiber in Richtung GPU zu verlagern und damit auch Bandbreite zu sparen.
 
Die Frage war nur ob es geht, nicht ob es sinnvoll ist.
Vielleicht Android und Windows auf einem System. Wir hatten das Thema schon mal. Alle bisherigen Ansätze beides zu vereinen sind nicht überzeugend.

Etwas lachen muss ich über Spinas Einschätzung dass AMD zu leistungsschwach und wenig innovativ ist um auf dem Markt zu bestehen.
 
Bin grad über diesen Artikel gestolpert:
http://www.elektroniknet.de/halbleiter/prozessoren/artikel/107338/
Wieweit hatte eigentlich Keller bei der Entwicklung was beizutragen?
Zumindest sieht man, was aus herkömmlichen ARM Kernen rauszuholen ist.
Nun, AMD hat Erfahrung mit solchen Architekturen. Ich denke daher, AMD konzentriert sich auf High-End ARM CPUs/APUs und geht damit der Konkurrenz Qualcomm und Mediatek aus dem Weg.
 
Die Frage war nur ob es geht, nicht ob es sinnvoll ist.
Eine "sinnvolle" Zusammenarbeit gibt es doch heute schon mit der TrustZone und dem Cortex A5 Kern.
...dass AMD zu leistungsschwach und wenig innovativ ist um auf dem Markt zu bestehen.
Ich bleibe dabei. Bei x86 hat AMD eine Menge Know-how. Bei ARM sind sie dagegen (am Anfang) ein kleiner Fisch.
Einen festen Stand müssen sie sich erst einmal hart erarbeiten. Das geht nicht über Nacht trotz der x86 Erfahrung.

Außerdem wollen wir Custom ARM Designs sehen. Solang AMD komplette Designs einkauft, bleibt nicht viel Spielraum.
Wie will man sich sonst von der Konkurrenz absetzen? Es gibt schon eine Menge gut ausgestatteter SoCs am Markt.

Das hat selbst nVidia trotz einiger Achtungserfolge mit dem Tegra zu spüren bekommen.
 
Zuletzt bearbeitet:
Ich bleibe dabei. Bei x86 hat AMD eine Menge Know-how. Bei ARM sind sie dagegen (am Anfang) ein kleiner Fisch.
Einen festen Stand müssen sie sich erst einmal hart erarbeiten. Das geht nicht über Nacht trotz der x86 Erfahrung.

Wenn es AMD schaft die einzelnen funktionen der CPU nur einmal zu designen und nacher 2 . verschiedene Die mit jeweils ARM Decoder oder x86_64 Decoder zu bauen denke ist das das maximum was amd da draus machen kann.
 
Außerdem wollen wir Custom ARM Designs sehen. Solang AMD komplette Designs einkauft, bleibt nicht viel Spielraum.
Wie will man sich sonst von der Konkurrenz absetzen? Es gibt schon eine Menge gut ausgestatteter SoCs am Markt.

Das hat selbst nVidia trotz einiger Achtungserfolge mit dem Tegra zu spüren bekommen.
Da liegt der Unterschied. nVidia will Tegra verkaufen, AMD bietet an, Chips nach Wunsch zu fertigen und nicht noch ein xtes SoC auf den Markt zu werfen.
Nach dem Motto: Was darfs denn sein? 1-8 Puma Kerne oder doch lieber ARM Kerne? etwas GPU dazu? Cache? 10GBit Ethernet, wieviele? USB3 PCIe? Memmory DDR3 oder 4 oder doch GDDR5? G3/4, LTE; sorry haben wir nicht im Programm.
Und demnächst kommen dann noch ein paar hausgemachte ARM Kerne hinzu.
Wer bietet sowas? Samsung, Apple produzieren für den Eigenbedarf. Broadcom, Qualcomm, Mediatek ?
Wer hat denn eine ARM-Architektur-Lizenz und CPU Erfahrung um überhaupt eigene ARM Kerne zu entwickeln?
ARM says there 10 companies with this license, Samsung, ST, Broadcom, Renesas, and LSI were named with terms range up to seven years max.
quelle:http://semiaccurate.com/2013/08/07/a-long-look-at-how-arm-licenses-chips/
Eine überschaubare Konkurrenzsituation.
Mal sehn, was draus wird.
 
Zurück
Oben Unten