AMD A-serien "Kaveri" försenas till 2014

Excavator är inte utvecklad än i den mån att de är inte färdiga, folk har inte gått vidare till andra jobb eller uppgifter och det handlar om många nya features samt annan arkitektur, Steamroller är färdig och har varit det länge vid det här laget. När det gäller tillverkning hade vi kunnat vänta oss desktopvarianterna sent i år och notebook någon gång i vår. Mainstream är notebook så det ser inte bra ut att skjuta på produkter som knappt används ändå, men nu vet vi inte vad dokumenten säger som de har kollat på. Kisel har de redan demonstrerat, så det vore synd om de har problem i Dresden. Större ramp-up var aldrig väntad fören nästa år i kanalen ändå.

50 miljoner dollar är inte särskilt mycket i den branschen. Sen tror jag knappast man kan få 50 miljoner genom Kickstarter. Det är löjligt mycket pengar för privatpersoner.

TSMC och GloFo hänger inte alls med Intel på kisel-sidan. Jag skulle tro förseningen handlar om problem med kisel-processen hos TSMC/GloFO snarare än några design-problem på AMD:s sida.

Men AMD har skjutit upp alla sina processorlanseringar i över tio år nu. Ofta så har det inte varit på ny process. Så varför ska man alltid skylla på tillverkningssidan? 28nm är inget purfärskt heller så det är ganska orimligt att felet skulle vara där.

Tror AMD helt enkelt har för vana att aldrig ha några som helst felmarginaler i sina tidsangivelser. Annars skulle vi inte se dessa förseningar VARJE gång.

Snarare helt rimligt. Hur många CPU:er kan du lista som tillverkas på en process under 32 nm som inte är Intel? Det som finns är GPU:er, som bekant inte riktigt samma sak. Så 28 nm är "purfärskt" vad gäller CPU-tillverkning. Du är bekant med problemen att tillverka CPU:er under 32 nm? Tittar du tio år bakåt så har Intel många förseningar de med. AMD har även många släpp som gjorts på utannonserad tid, dvs utan förseningar.

Mindre än 32nm:
Fujitsu SPARC 64X
Oracle SPARC T5
Ti OMAP 5
Qualcomm Snapdragon 800
Samsung Exynos 5
nVidia Tegra 4
Rockchip RK3188
MediaTek MT6589T
HiSilicon K3V3

Finns säkert fler. Och jag har inte läst om att någon skulle ha speciella problem med processorer på 28nm över huvud taget. Däremot vet jag att AMD alltid blir tagna på sängen när de inte kan släppa första revisionen av en processor.

Intel har verkligen inte många förseningar jämfört med hur många släpp de gjort. Har de ens haft en enda sedan Prescott 2004? Vilka processorsläpp har AMD gjort enligt plan?

Typ inga, men för det mesta har det bara framkommit när de planerar att starta tillverkningen när vi tittar bakåt, inte lansera produkterna. Tittar vi sedan K8 har de snarare haft problem att designa chip dessutom. Dresden hade problem med Trinity också, men hur som helst är Kaveri en färdig produkt att de skulle behöva göra en ny tape-out och revision är nog inte så troligt och vi har ingen aning vilket produktsegment eventuella förseningar berör. De bör ha gått ganska långt i tillverkningen redan och kommer det några innan nyår så håller de på och tillverkas just nu. Det enda som eventuellt skulle komma ut i år var ju FM2+-varianten. Även om de mobila (bärbara) lär börja tillverkas i år med.

Det är för övrigt samma process som Samsung i Texas använder här 28 nm Common Platform. Däremot inte ren (bulk) HKMG, AMD kör normalt sett SOI och inte lågförbrukningsprocessen de har. ST/ST-E har dock demonstrerat FD-SOI-chip på Common Platform och lanserat produkter på det, antar att dessa är tillverkade i Dresden hos GF. Hur som helst inte exakt samma sak. GF ska dock börja producera i deras New York/Malta-anläggning också, men jag vet inte om AMD kommer få något därifrån. Det är hur som helst en av anläggningarna (Dresden, Singapore eller Malta NY) som måste börja tillverka och lista ut allt innan de för över produktion till en annan anläggning.

Att de inte ens skulle skicka ut färdiga chip till recensenter i år har jag lite svårt att tro utan mer detaljerad information. Någon större lansering och ramp-up hade jag däremot aldrig väntat mig. Produkterna är för den delen inte så intressanta i desktopsegmentet att det blir någon större rusning.

Nvidia har ju bevisligen haft problem med 28 nm fast de är ju kända för att trassla till tillverkningsnoder som andra inte har problem med förr. Skulle gissa att det mer är relaterat till deras design än generella problem med 28 nm.

Vad menas med att Kaveri är en färdig produkt och inte behöver en ny tapeout? Enligt källan så ska de första produktionskandidaterna levereras i Oktober, och om inget är fel med dem ska produktion gå igång i December.

Ja det är ju ingen försening speciell för 28nm, utan det är den traditionella processövergången för nVidia.

Det vet jag iofs inte, men en wafer tar upp till ca 3 månader på sig att bli färdig. Kaveri är både en produkt för desktop och notebook, så jag har ingen aning om vilken de syftar på. ES-chip ska ju skickas ut nu iaf. De har demonstrerat kisel tidigare och folket som designat och jobbat med verifikation har gått vidare till annat i stort sett, alla features som ska finnas där har varit klart ganska länge och har fungerat så vitt vi vet annars skulle de behöva jobba om designen och det verkar det inte handla om. Notebook har de alltid syftat på att komma senare, det är åtminstone inget nytt. Fast ska de inte ha produktionskisel fören februari blir det ju problem på båda segmenten. Varför de nu inte skulle producera något mellan sep-oktober till december, självklart gör dem det om produktionskandidater är tillgängliga och fungerande.

Känns som det är mer fel hos AMD än deras produktion om de inte skickar ut produktionsexemplar av Kaveri till recensenter i år.

Som sagt så ska provtillverkningen av produktionskandidater göras i oktober. Processorn är alltså inte en färdig produkt, det ska testas och utvärderas och kanske finslipas och göras en ny stepping. Att visa upp ett experimentellt ingenjörsexemplar betyder inte att det är färdigutvecklat. Ibland kan de första exemplaren visas ett år innan processorn är färdig för marknaden.

Och de bestämmer sig för förseningar innan de ens skickat ut ES till sina partners? Det är inte de första kiselproven det handlar om. Folk som jobbat med det har redan hunnit tagit andra jobb. Utöver simulering har de redan hunnit testa kisel. Det är omöjligt att säga vad dokumenten syftar på för produkt när vi inte har dokumenten och det inte återges i artiklarna baserade på dessa. Får vi t ex Kaveri för notebooks i februari hos tillverkarna så är det i ganska god tid. Då hinner de ut med produkter innan sommaren till handeln. Vi får helt enkelt se hur det går för dem först. Steamroller är antingen färdigdesignad eller trasig vid det här laget. Mindre ändringar när det rör produktionen finns det fortfarande utrymme för. Är inte designen fungerande kommer den dras med de problemen oavsett vilka workarounds de sätter in.

Ja de kan bestämma sig för förseningar om de inser att de inte kommer hålla tidsplanen oavsett när de inser detta. Det är inte ovanligt, tvärtom så är det ju så här det brukar vara från AMD, de försenar produkter både tidigt och sent i utvecklingsprocessen hela tiden. Du ser allt extremt svart eller vitt. Den grundläggande designen kan fungera, men det kan fortfarande behövas en ny stepping innan den kan släppas.

Det utvecklas parallellt och flera delar av Steamroller blev färdigt för länge sen. Arkitekturen kom 2011. Kollar man vad folk jobbade på så blev många av ändringarna från Piledriver/BD osv utvecklat och implementerat senast förra året för Steamroller. Många har varit fria att helt arbeta med nästa generation länge några har varit fria sedan drygt 2012, men återstår att se hur AMD kommer satsa på det. Det är alltså upp till 4-5 års arbete som skiljer BD och Excavator åt i bästa fall. Det är något som varit planerat länge, och de har anställt en del gamla talanger. Det gäller bara att dessa resurser används. När var och hur återstår att se. Det är inte bara ingenjörsbeslut. Vi vet t ex inte om de kommer lansera excavator för servrar först heller, det finns ju t ex inga Steamrollers för flera sockets. Något ska de lansera iaf, de väntar knappast till sub 20nm om de behåller grejerna och planerna de arbetat med även om de har förseningar.

Det är såklart arkitekturförändringar och IPC-förbättringar i grunden som gäller efter Steamroller. Steamroller är ju egentligen bara breddad i front-end. Annars inte mycket förändringar, och det gör den fortfarande ganska svag. Jaga frekvenser har ju aldrig lyckats och det är ganska orelevant i mainstream eftersom bärbara inte kommer köra 5-6 GHz. Nuvarande Piledriver hade ju behövt vara 50-70% snabbare per kärna för att matcha Haswell i prestanda.

Workstation (8-20 kärnor) kan likaväl köra serversocket som när AMD64/K8 kom och som LGA2011 hos Intel. FM2+ och efterföljare behöver passa bättre för spelarna osv istället. Server och bärbara är där de behöver etablera sig, server hade de ett tag en god del men har tappat. Professionella bärbara (företagsklienter) har de aldrig tagit sig in på ännu. Blir ganska löjligt om t ex AMD inte har något annat alternativ än att sitta på Intel-laptops själva Så ser det ju faktiskt ut däremot. Behöver chipset, management osv för att komma in där också.

Vi har ju inte mycket belägg för att thread fusion faktiskt var något de arbetade på. Men det skulle förklara hur ett företag som annars gjort framgångsrika processorer fick för sig att tillverka något som Bulldozer som redan för en lekman ser ut att vara fullproppad med felprioriteringar.

Vad skulle vinsten vara om de hade separerat FPU-resurserna i Steamroller? Som det är nu kan ju de båda FPU:erna sammarbeta som en 256-bitsenhet. Betydligt mycket bättre om de satt fast med varsin 128-bit enhet som i Phenom II. Eller missar jag något?

Sedan känner jag att när de fixar frontenden med extra decoder och bättre branch prediction med mera så borde den vara stark nog till att mata mer än två ynka heltals-enheter per kärna. Intel klarar ju att utnyttja mer och nå högre IPC, så rimligtvis borde det finnas en hel del scenarion då sådan kapacitet är ett plus.

Svårt att säga, beror ju på pipeline på de båda. Behövs främst separata för AVX2 och liknande 256-bit operationer. Annars kommer du förlora en del throughput. Fast det enda jag kan säga och sett att de gjort är AVX2. För att det ska löna sig med 256-bit operationer så behöver du nog dubbla 256-bit FPUer, men du har också sånt som 1 LSU per kärna (2 per modul) i BD (till 3 generation iaf), denna matar FPUn också, det finns ingen anledning att spara in på transistorer där, det är all jävla cache som tar upp plats iaf, L3 och L2. I APUer gpuer också, tänk om gpuer hade varit lika beroende av cache, cachehantering och prestanda är verkligen något som är viktigt inte delade resurser. Decoders/LSU matar också FPUn. I bärbara varianter kan du normalt sett inte ha miljarder transistorer i onödan och har ofta nerskalad cache-mängd, så man kan hoppas att de så småning om bättrar sig och inte bygger med så mycket eller behöver så mycket i framtiden om de ska användas i mainstreamklienter.

Utan egna decoders så har AMD mycket mindre instruktioner per cykel än med tidigare designer, särskilt när det är flertrådat. Står ganska klart att det är för klent för entrådat/enkärnigt också. En quad går ju från 8 ops per cykel till 16 när varje heltalspipeline föregås av egna avkodare. Ner från 12 för K8/FAM10 till 8 hos BD alltså. Bara för att du gått från 3 st ALU/AGU till 2 st (4 pipelines) betyder det inte att det räcker med 2 avkodade instruktioner per heltalsenhet/cykel. Nehalem/Sandy/Ivy har t ex bara 3 vanliga ALUs. Men avkodaren klarar 4-5 ops per cykel. Scheduling och dylikt måste vara mycket mer avancerat för AMD i BD (Bulldozer – Excavator) än de jobbat med tidigare det även utan att de byggde ihop det och de måste mata två kärnor. 256-bit instruktioner tar 2 macro-ops och är möjligen därför begränsad av LSU, även om heltalskärnorna tar 2 instruktioner per cykel max och BD tar 2 instruktioner per tråd max så har du ju SIMD också, om de kan trycka igenom mer instruktioner. Så det finns utrymme där särskilt med andra förbättringar. Inte så mycket de behöver för att matcha, men Trinity/Richland är t ex inte "good enough" för spel på laptops. 30% mer Ops per cykel, lägre strömförbrukning, ny process, bättre styrning av klockfrekvenser osv är önskvärt där, inte för att tävla mot Haswell/Broadwell men för att inte flaska. När det är dags för Skylake så är det förhoppningsvis mot Carrizo APU och Excavator, vi får se var de tar konceptet där och var de tar det efter BD. Hade varit kul med mer än 2007 års prestanda iaf, det ska vi väl se nu. Det duger inte idag och Intel är relativt billigt. När det gäller APUerna som kommer nu (nästa år för bärbart) får de se till att köra GPUn hårt, Intel har ju redan 700 GFLOPs i GT3.

Men varför skulle AVX2 kräva att de inte är delade? Varför inte bara ha två 256-bit enheter som delas precis som dagens 128-bit enheter?

Men även i Steamroller så är 16 ops inte lika flexibelt som hos Phenom II. En Steamroller Quad har ju 8 ALU + 8 AGU medan Phenom II har 12ALU/AGU. Nu tror ju jag att Steamroller kan komma ifatt Phenom II i IPC ändå, men jag tror nog att en hypotetisk Phenom III hade klått Steamroller rätt bra ändå.

Två 256-bit FPUer betyder ju två pipelines, de är lika delade som exekveringsenheten för heltal om varje kluster får två FPUer dvs dedikerade decode-enheter och fullt oberoende pipelines under en gemensam front-end/instruction fetch/branch prediction med två decode-kluster. En 512bit 2x256bit 4x128bit 8x64bit FPU med en delad pipeline är onödigt komplicerat och kan nog uteslutas. Du skulle i princip inte kunna mata den med några instruktioner. Du spar inget kisel på onödig komplexitet plus att det är stora ändringar som inte hör hemma i en utveckling av tidigare arkitektur. Varje heltalsenhet har egen pipeline och scheduler, precis som hos Intel. Det ter sig troligt att FPU går åt samma håll. Innan BD hade AMD en scheduler och pipeline per FPU-enhet (per kärna) också. De behöver med andra ord in med nya instruktioner och duplicera den gamla FPUn om de inte ska starta om från grunden. Då får du mer kraft, iaf för 256-bit-operationer, breddar du inte FPU går ju 256-bit på halvfart. LSU har redan möjlighet per heltalskärna att snacka med FPUn. Allt beror på hur mycket de kan bygga om.

Hammer kan utvecklas lite till och kan vara ett snabbt alternativ, och är mycket enklare tack vare att varje ALU/AGU har egen scheduler och lane. Tack vare att varje kärna har egen front-end med instruction fetch, branch prediction, och decode samt egen L1I är det enklare där också. Men Hammer kunde aldrig använda alla heltalpipelines. Man måste med andra ord komma förbi flaskhalsarna där också. AMD har ju också Jaguar och efterföljare. De behöver inte riktigt gå tillbaka till en design inspirerad av slutat av 90-talet.

Sen får du tänka på att du ska mata FPU och göra minnesoperationer också. Att bara köra fler Stars-kärnor är inte heller vägen framåt och Steamroller är snabbare än BD á la 2011. Excavator handlar allt om HSA, de behöver ju få in context switching och sånt i gpun där också.

Det är ju fler förändringar. Visst hade de kunnat gjort en starkare Bobcat/Jaguar/Puma+, men de hade t ex gått ifrån K7/K8:as 3 avkodare med 3 ALU/AGU med egna pipelines och 3 FPU (FPU med delad pipeline) iaf. Men visst hade de kunnat gjort på annat vis istället. De behövde gå vidare och har idag två vägar att välja de kan göra en starkare version av deras "mindre" arkitektur eller uppgradera BD tills de kan ersätta den med en ny. Att bara gå tillbaka till Llano löser inget, inte fler kärnor heller. Haswell är t ex fortfarande byggt på Nehalem. Prestandaförbättringar finns det utrymme för, sen ska man inte glömma att FAM10 Phenoms är halvtrasiga de med. FAM10/Llano var för den delen faktiskt slöare än eller hamna på samma prestanda som Yorkfield Core 2 Quad. Ska AMD platsa på bärbara så måste de upp i minst Nehalemprestanda, eftersom de är så lågt klockade.

Excavator är det enda jag kan säga hyfsat säkert AVX2 och HSA. Det AMD verkligen kallar riktig HSA med fast context switching och pre-emption, redo för deras arbete med HSAIL eller andra miljöer där man kör i stort sett vanlig riktig kod på grafikkretsen och kan byta mellan arbetssätten. IMC hos Llano är långt efter Steamroller och Excavator. Något som är viktigare i deras strategi än snabbaste chippen eftersom de vill få in gpgpu på riktigt.

Pga deras strategi och utveckling ligger det närmare att göra starkare versioner av deras andra CPU-arkitektur tänk Jaguar som i konsolerna fast förbättrad och förenklad gpgpu-kapacitet, starkare FPU och högre klockad CPU. Jaguar är inte jätte jätte snabb, men den spöar mobila Trinity-modeller klock för klock. Trinity / Richland har varit hopplöst slöa i bärbara och de högre klockade quad-coren får stryk av Intels lågt klockade dual-core. De är inte snabba nog att driva runt CPU-begränsade spel på bärbara. Utan att skilja stort i prestanda mot Intels quad-core dito då.