AMD Zen - 14nm, 8 Kerne, 95W TDP & DDR4?

Du verstehst es nicht weil du von einer falschen Faktenlage ausgeht.
1. AMD hat in 2014 1 Mrd. $ an Forschung und Entwicklung ausgegeben
2. Das entspricht 19% des Umsatzes in 2014
3. AMDs CFO hat vor 2 Wochen im Conference Call eine Erhöhung des Budgets für Forschung und Entwicklung angekündigt

Also alles weitere von dir daraus Geschlussfolgerte ist obsolet.

Nein. Du hast einfach einen Satz aus dem Zusammenhang gerissen und diesen irgendwie widerlegt. Auch hast du nicht geschrieben wie nachhaltig der Etat erhöht worden ist. Ist es nur kosmetischer Natur um Partner zu beruhigen oder haben sie diesen verdoppelt.

Im Vergleich zu den Wettbewerbern sind die Kassen leer und damit die Möglichkeiten sehr gering. Und für die Vermarktung, um Produkte in den Markt zu drücken bleibt so gut wie nichts. Und somit werden wir auch kaum Produkte mit Zen sehen. Es ist und bleibt für den Handel und damit für die Hersteller uninteressant AMD Produkte zu vertreiben.

Um neue Märkte zu besetzen, z.B. dense server, fehlt AMD das Tempo und somit die Durchschlagskraft. Den Kauf von Seamicro würde ich in diesem Zusammenhang als Fehler bezeichnen, weil er Liquidität bindet, welche in anderen Bereichen fehlt. Ob es x86(Zen) oder GPUs oder etwas anderes ist, AMD kommt meist zu spät, weil man sich in zu vielen Baustellen verzettelt.
 
Da du gesagt hast die Investitionen seien Rückläufig ist überhaupt nichts aus dem Zusammenhang. Und wie hoch oder aus welchem Grund die Erhöhung des Etats sind spielt ja wohl auch keine Rolle wenn diese eben NICHT fallend sind wie du behauptest. Einfach dies als Fakt nehmen und dann kannst du gerne weiter argumentieren oder vergleichen mit anderen Unternehmen. Ich mag halt einfach nicht dauernd von fallenden Etats lesen wenn ich 1 Woche zuvor von den Unternehmensleitern in verantwortlicher Position das Gegenteil gelesen haben - was soll das andauernd? Lass es doch einfach weg.

--- Update ---

Um neue Märkte zu besetzen, z.B. dense server, fehlt AMD das Tempo und somit die Durchschlagskraft. Den Kauf von Seamicro würde ich in diesem Zusammenhang als Fehler bezeichnen, weil er Liquidität bindet, welche in anderen Bereichen fehlt.
Wie kann das sein wenn man das führende Unternehmen in diesem Bereich kauft? einerseits fehlt Tempo und andererseits hat man Liquidität gebunden? Das eine kann man nicht ohne das andere haben. Also was jetzt sollen sie neue Märkte erobern oder in die Forschung investieren oder auf der hohen Kante Liquidität herstellen?

Eben vor 1 Woche haben sie bekannt gegeben alle Kredite umgeschuldet zu haben auf Zahlbeginn März 2019 - da sind 1,3 Mrd. Dollar die für die nächsten 4 Jahre frei geworden sind. Weitere 100 Mio werden aufgenommen in 2015. Das steht alles in den Slides zum Conference call hier im Thread:
http://www.planet3dnow.de/vbulletin...ffen-koennte?p=4979840&viewfull=1#post4979840
 
Mir ist schon klar das ein neuer Name ein neues Produkt suggeriert aber nur weil ein schlechtes Bier ein neues Etikett hat wird es nicht besser, eigentlich sollte man glauben das verstehen auch Investoren. Sonst hätten sich deutsche Kaufhauskette auch einfachst "retten" lassen den Kaufhof hier hatten sie sogar neu dekoriert ;-).

Aber ich gebe gerne zu das in dem Bereich viele Dinge passieren die sich völlig meiner Logik entziehen aber das Argument erst auf die Plattform mit DDR4 zu warten macht immerhin Sinn und mit der massiven Umschuldung (die irgendwann ja bedient werden müssen) kann man zumindest den Eindruck gewinnen AMD will mit Zen und DDR4 (für die IGPU´s)nochmal probieren im Markt was zu erreichen.

Besser als den Laden komplett zu minimieren und auf Patentunternehmen zu machen aber der Zug (zum Glück) dürfte mit den Vereinbarungen mit Intel (2009?) eh abgefahren zu sein.

Leider stärkt das aber auch die Vermutung das man bis dahin die Erwartungen im CPU-Bereich (vielleicht abgesehen von Carizzo-L) völlig minimieren kann.
 
Naja, mittlerweile hat man sich an die Namensinflation gewöhnt. Das ist mMn nur Augenwischerei für die Investoren. Da kann man dann sagen unser neuer Chip xy ... und die Investoren haben von Technik Null Anhnung, die sind froh, wenn sie hören, dass es was Neues gibt.


Was meinst Du mit Trägerplatine?
Mir fallen 2 Gründe ein, die es geben könnte:
a) Carrizo braucht ne neue Infrastruktur, die Mainboardhersteller haben aber keine Lust nach AM1 und FM2+ schon wieder was Neues zu bringen, insbesondere da DDR4 vor der Türe steht, was abermals neue Boards bedingt. Intel kann sich sowas leisten, da deren Volumen deutlich größer ist, aber bei AMD rechnet sich das nicht. Da sind die Risiken groß, dass man auf ner Halde alter Boards sitzen bleibt.

b) Carrizo ist schlimmstenfalls langsamer,
b1) wegen eines billigen low-power Prozesses
b2) Wegen weniger Cache, schließlich gabs schon Gerüchte in Form authentisch aussehender AMD-Folien über nur 2x1 MB Cache

Sah man schon vor nem halben Jahr in dieser Meldung auf der Gerüchteschleuder wccftech:
http://wccftech.com/amd-carrizo-apu...ft-15w-tdp-4-x86-excavator-512-gcn-cores-soc/

Godovari hieß da noch Kaveri 2.0 und hatte SteamrollerB-Kerne und bei Carizzo sind nur 2x1 MB Cache genannt.


Ich meine das Package. Hätte man ja vllt. darüber regeln können.

@ b2): Carrizo muss deshalb nicht zwingend langsamer sein, falls der L2 zum Ausgleich schneller arbeitet.

Hoffentlich findet sich ein MoBo-Hersteller, der Carrizo auf eine Mini-ITX Platine lötet.
 
Ich meine das Package. Hätte man ja vllt. darüber regeln können.
Aso ja, das wär vielleicht gegangen ... aber Ende des Jahres kommt ja noch die neue, gemeinsame Sockelarchitektur Skybridge.
Vielleicht kommt da ja was passendes mit Carrizzo.
@ b2): Carrizo muss deshalb nicht zwingend langsamer sein, falls der L2 zum Ausgleich schneller arbeitet.
In einem der ersten BD-Arch-PDFs wurden 19 Takte Latenz für 1MB Cache genannt, für 2MB 21. Das merkt man also nicht wirklich ... da hab ich lieber die doppelte Menge Cache, v.a. wenn 2 Threads darauf zugreifen.
Das waren Zahlen für 32nm, bei 28nm kanns vielleicht 1 Takt weniger sein, wer weiss, aber die Welt isses in jedem Fall nicht.
 
In einem der ersten BD-Arch-PDFs wurden 19 Takte Latenz für 1MB Cache genannt, für 2MB 21.
Im aktuellen SOG stehen 20 Takte generell und 19 Takte für 30h-4Fh. Für Carrizo (Excavator) sagt uns das nichts. Der soll Gerüchten zufolge 60h-6Fh sein.

Bei Steamroller hat man die L2 Performance schon deutlich verbessert. Macht man ähnliches bei Excavator kann man 1 MB weniger durchaus kompensieren.
 
In einem der ersten BD-Arch-PDFs wurden 19 Takte Latenz für 1MB Cache genannt, für 2MB 21. Das merkt man also nicht wirklich ... da hab ich lieber die doppelte Menge Cache, v.a. wenn 2 Threads darauf zugreifen.
Beim alten K8 gab's doch auch mal einen L2-Cache-Änderung beim Die-Schrink. Die 90 nm Modelle konnten auf ihren 1 MB Cache in wohl 12 Takten zugreifen, die 65er dann auf den 0,5 MB Cache nur noch in 20 Takten. Der Unterschied war eher klein, es kostete vielleicht 5 % Geschwindigkeit. Wenngleich der L1-Cache damals größer war.
Eigentlich müsste man darauf schauen, wie viel Geschwindigkeit es kostet und welche Energieeinsparung bzw. welchen zusätzlichen Turbospielraum man sich damit eröffnet.
 
Im aktuellen SOG stehen 20 Takte generell und 19 Takte für 30h-4Fh. Für Carrizo (Excavator) sagt uns das nichts. Der soll Gerüchten zufolge 60h-6Fh sein.
Ne die Info war nicht aus dem SOG, sondern aus nem Artikel der AMD-Entwickler für ne Fachzeitschrift. Dem trau ich mehr als den üblicherweise mit Fehlern gespickten SOG.

Bei Steamroller hat man die L2 Performance schon deutlich verbessert. Macht man ähnliches bei Excavator kann man 1 MB weniger durchaus kompensieren.
Ja, aber das war doch nicht aufgrund von Latenzverbesserungen, sondern andere Sachen oder nicht?

Beim alten K8 gab's doch auch mal einen L2-Cache-Änderung beim Die-Schrink. Die 90 nm Modelle konnten auf ihren 1 MB Cache in wohl 12 Takten zugreifen, die 65er dann auf den 0,5 MB Cache nur noch in 20 Takten. Der Unterschied war eher klein, es kostete vielleicht 5 % Geschwindigkeit. Wenngleich der L1-Cache damals größer war.
Eigentlich müsste man darauf schauen, wie viel Geschwindigkeit es kostet und welche Energieeinsparung bzw. welchen zusätzlichen Turbospielraum man sich damit eröffnet.
Eben .. wie Du schon sagst, der Unterschied war klein, viel kann man da nicht erwarten, BD hat auch tiefere Puffer, die 1-2 Takte Unterschied sowieso wegstecken.
Von daher sind keine Cache-Wunder zu erwarten. Die gibts erst, wenn der L1-Cache vergrößert und auf WB umgestellt wird ^^

Beides seh ich bei Excavator nicht, das ist nur ne neue Kaveri-Revision nichts weiter. Mehr als Feintuning kann man da nicht erwarten.
 
Beim alten K8 gab's doch auch mal einen L2-Cache-Änderung beim Die-Schrink. Die 90 nm Modelle konnten auf ihren 1 MB Cache in wohl 12 Takten zugreifen, die 65er dann auf den 0,5 MB Cache nur noch in 20 Takten. Der Unterschied war eher klein, es kostete vielleicht 5 % Geschwindigkeit.
Im Schnitt war der Unterschied weniger als 5%. In normalen Anwendungen quasi kaum messbar. ~5% war es eigentlich nur in Spielen, die bekanntlich mehr von Cache profitieren.


Ja, aber das war doch nicht aufgrund von Latenzverbesserungen, sondern andere Sachen oder nicht?
Siehe zuvor, auch die Latenz wurde leicht verbessert (Steamroller == 30h-3Fh), trotz gleicher Kapazität. Bei weniger Kapazität sollte eigentlich noch mehr drin sein. Und dass es zusätzliche Verbesserungen gibt, kann man ja auch für Excavator nicht ausschliessen.

Mir ist ehrlich gesagt ein schneller L2 lieber als ein doppelt so grosser aber lahmer L2. 1 MB ist ja immer noch vergleichsweise gross. Cyclone hat zB auch nur 1 MB shared L2. Allerdings kann dort der lahme RAM noch mit einem L3 abgefangen werden. K8/K10 hatte auch nie mehr L2.
 
Zuletzt bearbeitet:
Was heißen noch gleich SOG und WB?
 
Siehe zuvor, auch die Latenz wurde leicht verbessert (Steamroller == 30h-3Fh), trotz gleicher Kapazität. Bei weniger Kapazität sollte eigentlich noch mehr drin sein.
Ok, wenn die Differenz gleichbliebe, wäre man dann bei 17 ...
Und dass es zusätzliche Verbesserungen gibt, kann man ja auch für Excavator nicht ausschliessen.
100%ig nicht, aber zu 99,9% schon. Wir reden von AMD, da gibts keine Wunder sondern nur jede 2. Woche neue Codenamen. Bin mir deshalb zu 99,9% sicher, dass Excavator ein debuggter Steamroller ist, auf der geleakten Folie stand auch schon SteamrollerB ... von daher ist das wirklich sehr, sehr sicher.
Mir ist ehrlich gesagt ein schneller L2 lieber als ein doppelt so grosser aber lahmer L2. 1 MB ist ja immer noch vergleichsweise gross. Cyclone hat zB auch nur 1 MB shared L2. Allerdings kann dort der lahme RAM noch mit einem L3 abgefangen werden. K8/K10 hatte auch nie mehr L2.
Ja aber der L2 ist bei BD-Chips auch für 2 Threads/2CPUs da. Cyclons L2 dagegen nicht, wobei Cyclone dann aber auch noch 64kB L1 WB hat. Da wird der L2 deutlich entlastet. Also das sind ganz verschiedenen Baustellen.

Was heißen noch gleich SOG und WB?
WB = Write Back, siehe https://de.wikipedia.org/wiki/Cache#Schreibstrategie

SOG = Software Optimization Guide, das gibts von AMD für jede Familie, beschreiben wie man besonders guten Asseblercode für diese schreibt, wodurch technischen Details genannt werden müssen. Für die BD-familie zB:
http://support.amd.com/TechDocs/47414_15h_sw_opt_guide.pdf
 
Ah, OK. Was ein SOG ist, wusste ich, ich konnte nur die Abkürzung nicht dem Inhalt zuordnen.
 
100%ig nicht, aber zu 99,9% schon. Wir reden von AMD, da gibts keine Wunder sondern nur jede 2. Woche neue Codenamen. Bin mir deshalb zu 99,9% sicher, dass Excavator ein debuggter Steamroller ist, auf der geleakten Folie stand auch schon SteamrollerB ... von daher ist das wirklich sehr, sehr sicher.
SteamrollerB ist der Kern in Kaveri. Das hat mit Excavator nichts zu tun. Nach den bisherigen Infos ist Excavator mehr als nur ein fehlerbereinigter Steamroller. Einen fehlerbereinigten Steamroller kann man daher eher zu 99,9% ausschliessen.

Ja aber der L2 ist bei BD-Chips auch für 2 Threads/2CPUs da. Cyclons L2 dagegen nicht
Doch, auch beim A7 und A8 wird der 1 MB L2 von 2 Kernen geteilt. Ich schrieb doch extra shared. Mehr ist es erst beim A8X. Dort teilen sich 3 Kerne 2 MB L2.
 
Wir wissen aber nicht, ob sich hinter dem Codenamen "Excavator" dasselbe verbirgt, was vor Jahren damit gemeint war. Auf der alten Folie stand schwammig "mehr Performance". Die könnte durch höhere IPC oder mehr Takt erreicht werden, aber was bisher von Carrizo bekannt ist, beschreibt keinerlei Leistungssteigerungen, nur Effizienzsteigerungen. Es ist also denkbar, daß man einfach den Kern (nach dem Meyer-Rauswurf) in eine andere Richtung weiterentwickelt hat als vor Jahren geplant war, aber den Codenamen weiterbenutzt hat, weil der schon mal auf einer Folie stand und es deswegen so aussieht, als würde man nach Plan weiteroperieren (sieht immer besser aus). Natürlich kann es auch einfach sein, daß nur über Effizienzsteigerungen geredet wurde, weil die für Notebooks viel wichtiger sind als Spitzenleistung.
 
Mit Excavator sollen ja zb. auch die high dense librarys für die FPU genutzt werden, wodurch deren Größe und Leistungsaufnahme deutlich sinken soll. Mit Steamroller gab es diese ja noch nicht und die FPU kann man auch nicht mit einem neuen Stepping austauschen.
Die Größe vom L2 würde sich wohl auch kaum verändern wenn Carrizo nur ein Kaveri Aufguss wäre.

Das Zen dann eine Weiterentwicklung von Excavator ist halte ich aber auch für relativ wahrscheinlich. Die Frage ist letztendlich ob man einen mehr oder weniger radikal umgebauten Kern dann noch als Nachfolger bennen kann, auch wenn Teile der Logik noch identisch sind. An der Pipeline (länge/breite ...) wird AMD denke ich auf Fälle etwas verändern wollen.
 
Natürlich kann es auch einfach sein, daß nur über Effizienzsteigerungen geredet wurde, weil die für Notebooks viel wichtiger sind als Spitzenleistung.
Mit funktionierendem Turbo läuft das erste im Notebook meist auf das zweite hinaus.

@tex_: Ich würde ja eher auf einen Jaguar++ mit einigen Bulldozer-Anleihen tippen. Aber streng genommen, wissen wir zu wenig darüber.
 
SteamrollerB ist der Kern in Kaveri.
Ne, SteamrollerB stand nur auf der Folie mit dem Titel "Kaveri 2.0" und statt Kaveri 2.0 heißts nun halt Godovari ...

Das hat mit Excavator nichts zu tun. Nach den bisherigen Infos ist Excavator mehr als nur ein fehlerbereinigter Steamroller.
Welche denn? Ich seh da nichts Handfestes, das irgendwelche Wunder zuließe. Versprochen ist bessere Perf/Watt, das konnte Richland aka "Trinity 2.0" auch. Jetzt kommt halt noch die integrierte SB dazu, wodurch der Spareffekt für den Gesamtsystemverbrauch größer ausfallen wird, aber das wars dann.
Doch, auch beim A7 und A8 wird der 1 MB L2 von 2 Kernen geteilt. Ich schrieb doch extra shared. Mehr ist es erst beim A8X. Dort teilen sich 3 Kerne 2 MB L2.
Ach stimmt ja, da hab ich mich durch ein Arch-Diagramm aufs Glatteis führen lassen. Bleibt als Argument also "nur" der 64kB L1 WB-Cache.

Wir wissen aber nicht, ob sich hinter dem Codenamen "Excavator" dasselbe verbirgt, was vor Jahren damit gemeint war. Auf der alten Folie stand schwammig "mehr Performance". Die könnte durch höhere IPC oder mehr Takt erreicht werden, aber was bisher von Carrizo bekannt ist, beschreibt keinerlei Leistungssteigerungen, nur Effizienzsteigerungen. Es ist also denkbar, daß man einfach den Kern (nach dem Meyer-Rauswurf) in eine andere Richtung weiterentwickelt hat als vor Jahren geplant war, aber den Codenamen weiterbenutzt hat, weil der schon mal auf einer Folie stand und es deswegen so aussieht, als würde man nach Plan weiteroperieren (sieht immer besser aus). Natürlich kann es auch einfach sein, daß nur über Effizienzsteigerungen geredet wurde, weil die für Notebooks viel wichtiger sind als Spitzenleistung.
Wäre möglich, aber wie schon gesagt, wir reden über AMD.
Was dort in letzter Zeit funktionierte war v.a. die Werbeabteilung mit blumigen Versprechungen und Codenameninflation, technisch gabs dagegen gute Hausmannskost, siehe Richland. Bei Carrizo lag das Augenmerk ganz sicher an der SB-Integration, nicht am Verbessern der µArch.

Würde mich freuen, wenns anders käme, aber ich glaubs nicht. In ein paar Wochen sind wir schlauer.

Mit Excavator sollen ja zb. auch die high dense librarys für die FPU genutzt werden, wodurch deren Größe und Leistungsaufnahme deutlich sinken soll.
Nachdem es Folien gibt,die von halbierten L2-Caches reden, ist das mit den HD-Libs (leider) zweifelhaft... denn wenn sie die verwendet hätten, bräuchten sie wohl kaum den L2 zu halbieren.
 
denn wenn sie die verwendet hätten, bräuchten sie wohl kaum den L2 zu halbieren.

Wieso haswell hat weniger pro kern (256kb), wenn es was bringt und wenig perf kostet kann man die Fläche auch für was anderes benutzen. Das eine schliesst das andere nicht aus.
Mal abgesehen davon gehe ich davon aus das amd mit zen das beste aus den katzen und den baumaschinen zusammenführt.
 
Haswell ist aber eine ganz andere Baustelle, weil er auf Fullspeed L3 Cache zurückgreifen kann...
 
Ne, SteamrollerB stand nur auf der Folie mit dem Titel "Kaveri 2.0" und statt Kaveri 2.0 heißts nun halt Godovari ...
Nein. Kaveri 2.0 ist das, was wir bereits haben. Godovari hat damit nichts zu tun. Wobei ich nach wie vor den Godovari Refresh anzweifle. Zum einen den Namen, zum anderen dass es mehr als nur ein paar neue Kaveri Modelle sein sollen. Sowas wie Richland erwarte ich nicht.

Welche denn? Ich seh da nichts Handfestes, das irgendwelche Wunder zuließe.
Es gibt verschiedene Anhaltspunkte. HDL, Cache, ISA Erweiterungen (AVX2), FPU Pipeline (?) usw. Wie viel das im Endeffekt bringt, ist an der Stelle nicht von Bedeutung. Sie erfordern aber einiges an Überarbeitung. Wesentlich mehr als eben nur eine Fehlerbereinigung.

Versprochen ist bessere Perf/Watt, das konnte Richland aka "Trinity 2.0" auch.
Ja, aber scheinbar in deutlich geringerem Umfang.

Jetzt kommt halt noch die integrierte SB dazu, wodurch der Spareffekt für den Gesamtsystemverbrauch größer ausfallen wird, aber das wars dann.
Bezogen auf den gesamten Prozessor kommt mindestens auch noch der vollständige HSA 1.0 Support und eine neue iGPU hinzu.


Haswell ist aber eine ganz andere Baustelle, weil er auf Fullspeed L3 Cache zurückgreifen kann...
Den Fullspeed L3 gab es nur bei SB. Mit Haswell wurde der L3 wieder von den Kernen entkoppelt.
 
Der L3 taktet unter Last auch bei HSW und BDW mit Kernfrequenz, einzig die Latenz ist minimal höher als bei SNB und IVB.
 
Haswell ist aber eine ganz andere Baustelle, weil er auf Fullspeed L3 Cache zurückgreifen kann...
Fullspeed ist nicht der Punkt, der L3 an sich ist der Punkt ^^
Die APUs haben bekanntlich keinen L3 .. die 1MB L2 sind alles, was den 2 Kernchen eines Carrizo-Moduls bleiben ...
Man hat also maximal 16kB L1 und 1MB L2 pro Modul / 2 Threads
Ein Intel i3-Kern hat dagegen maximal 32kb L1 / 256kB L2 / 2MB L3.
Single-Threaded steht also nur die Hälfte von Intels 2 MB zur Verfügung (und die haben noch nen schnellen, kleinen L2 zusätzlich). Das wird definitiv IPC kosten.
AMDs großer L2 mag lahm und nur auf L3-Speed von Intel sein, aber im Vergleich zu nem Speicherzugriff ist das immer noch ~10x schneller.

Nein. Kaveri 2.0 ist das, was wir bereits haben.
Achso Du beziehst Dich auf die längeren Verzögerungen vor dem Start? Stimmt da war was mit SteamrollerB... Ok, Punkt für Dich ;-)

Es gibt verschiedene Anhaltspunkte. HDL, Cache, ISA Erweiterungen (AVX2), FPU Pipeline (?) usw. Wie viel das im Endeffekt bringt, ist an der Stelle nicht von Bedeutung. Sie erfordern aber einiges an Überarbeitung. Wesentlich mehr als eben nur eine Fehlerbereinigung.
Naja, die Unterstützung neuer Befehlssätze bezieht sich oft nur auf neue Einträge im µRom. HDL schließe ich aktuell eher aus, da es Lecks zu nur 1 MB L2 gibt. FPU ... wird man sehen müssen, ob da wirklich Hand angelegt wurde oder nicht.

Es stellt sich auch die übergeordnete Frage: Macht das Herumdoktorn an der BD-Arch für ein paar Promill oder AVX2 noch großartig Sinn, wenn man die Arch. sowieso schon abgekündigt hat?

Also wenn Du recht haben solltest, würde das die Idee unterstützen, dass Zen ne Art Bulldozer wird, bei dem dann irgendwelche Teile aus dem aktuellen Design (z.B. FPU?) wiederverwendet werden könnten.
 
Es stellt sich auch die übergeordnete Frage: Macht das Herumdoktorn an der BD-Arch für ein paar Promill oder AVX2 noch großartig Sinn, wenn man die Arch. sowieso schon abgekündigt hat?
Wohl nur, wenn man die erarbeitete Logik hinterher noch für etwas anderes weiter verwerten / verwenden will.
 
Naja, die Unterstützung neuer Befehlssätze bezieht sich oft nur auf neue Einträge im µRom.
Aber nicht bei sowas wie AVX2. Es gab ja auch Gerüchte, dass die FP Pipeline auf 256-bit erweitert wird. Also AVX Instruktionen nativ verarbeitet werden, anstatt sie in 128-bit uOps zu zerlegen. Auch das würde einiges an Überarbeitung erfordern.

HDL schließe ich aktuell eher aus, da es Lecks zu nur 1 MB L2 gibt.
Das würde aber nicht ausreichen, um den Kern soweit zu schrumpfen, wie den ISSCC Ankündigungen zu entnehmen war. Ausser man hat den Kern noch an anderen Stellen abgespeckt, was ich ausschliessen würde. Man wird eher noch einiges an zusätzlicher Logik implementiert haben. 1 MB L2 macht gut 18% bei Steamroller aus, das Modul soll aber 23% kleiner sein. Zudem war den ISSCC Ankündigungen nicht zu entnehmen, ob da überhaupt der L2 inbegriffen war. Eine Modulverkleinerung von 23% würde jedenfalls perfekt zu den früheren Ankündigungen von HDL passen. Laut älterer AT Gerüchte sollte das auch nach Steamroller erstmals zum Einsatz kommen.

Es stellt sich auch die übergeordnete Frage: Macht das Herumdoktorn an der BD-Arch für ein paar Promill oder AVX2 noch großartig Sinn, wenn man die Arch. sowieso schon abgekündigt hat?
Wenn man sie auch 2016 noch nutzen will, macht das durchaus Sinn. Excavator wurde ja auch nicht erst vergangene Woche entwickelt.

Also wenn Du recht haben solltest, würde das die Idee unterstützen, dass Zen ne Art Bulldozer wird, bei dem dann irgendwelche Teile aus dem aktuellen Design (z.B. FPU?) wiederverwendet werden könnten.
K12 und Zen werden Neuentwicklungen. Das hat Keller unmissverständlich gesagt. Trotzdem wird man natürlich nicht alles neu erfinden, sondern vorhandene IP nutzen. Auch jene aus Bulldozer und Cat.
 
Aber nicht bei sowas wie AVX2. Es gab ja auch Gerüchte, dass die FP Pipeline auf 256-bit erweitert wird. Also AVX Instruktionen nativ verarbeitet werden, anstatt sie in 128-bit uOps zu zerlegen. Auch das würde einiges an Überarbeitung erfordern.
Für den Anfang könnte man die 512 Bit Vektoren auch in vier 128er zerlegen.
 
Zurück
Oben Unten