AMD to transition to 28nm bulk in 2013 (digitimes)

[SocketF]

But AM3 is dead in the serverspace after the next release. And the Pilediver FX is the last on the desktop. Then its steamroller dualco..^H^Hmodule APUs instead on FMx platform. Also why the APUs is far ahead on the CPU uarch.

The big question is: Will there be a desktop version of the "new server plattform 2013" later in 2014, i.e. sth similar to intel's 2011 socket, or not?

Given a slow DDR4-ramp up, it would make sense to start with DDR4-server parts first, e.g. one year after the Piledriver start, around Oct./Nov. 2013 and then to launch the desktop parts later in 2014.

But the question is: Is there still a market for an AMD enthusiast platform? It all depends on how good Steamroller will be (I assume all 28nm processors will be Steamroller based). Yes, there will be Haswell, too, but it won't raise the single-thread IPC bar much higher, the improvements are imo only for FMA and to improve SMT performance. I won't expect more than +5% in the usual benchmarks / games.

Thus Steamroller should be able to get closer to Intel's single-thread IPC, but then the question is "by how much" and how well the 28nm process scales with high clocks. They probably kept the 5-Module design of Komodo and deactivate 1 module for the desktop part for higher clocks, lets hope that plan will go well

 

[Medu]

You got that unquestionable body of evidence speaking against SOI and in my opinion you'd got an even more compelling story coming from within AMD itself - Bobcat wasn't implemented in SOI.

So here you have a product that is geared towards the very sorts of markets that SOI is supposed to best serve - low-power mobile ICs - and you've got THE company that has the most experience implementing ICs in SOI electing to go with Bulk-Si when designing a mobile low-power IC.

We laypeople may never know what is rotten in Denmark, but clearly there is something rotten in Denmark.

AMD didn't have experience in SOI GPU's, at the time, which is probably why they went with TSMC for Bobcat.

 

[ShintaiDK]

Thus Steamroller should be able to get closer to Intel's single-thread IPC, but then the question is "by how much" and how well the 28nm process scales with high clocks. They probably kept the 5-Module design of Komodo and deactivate 1 module for the desktop part for higher clocks, lets hope that plan will go well

And before that it was Pilediver, always the nextgen...never reaches the goal. the difference only keeps expanding. AMD will never get close to Intel IPC. Only slower and slower.

 

[NostaSeronx]

SOI both PD-SOI and FD-SOI only improve the highest clock you can run at the lowest voltage.

Bulk on LP: 1.0 GHz @ 0.5 Volts <-- Same Leakage v
Bulk on GP: 1.5 GHz @ 0.5 Volts
SOI: 1.8 GHz @ 0.5 Volts <-- Same Leakage ^

Bulk on GP: 3 GHz @ 1.0 Volts
SOI: 3 GHz @ 1.0 Volts

SOI Substrate is about 5x more expensive than Bulk Substrate. You also suffer FEOL, BEOL, and capacity/yield issues with SOI if it isn't mature.

Thus, Steamroller should be able to get closer to Intel's single-thread IPC, but then the question is "by how much" and how well the 28nm process scales with high clocks. They probably kept the 5-Module design of Komodo and deactivate 1 module for the desktop part for higher clocks, lets hope that plan will go well

Steamroller is going for lower clocks than Bulldozer and Piledriver. While the FPU might be double clocked though but not the cores or the front-end.

 

[Rvenger]

And before that it was Pilediver, always the nextgen...never reaches the goal. the difference only keeps expanding. AMD will never get close to Intel IPC. Only slower and slower.

According to the AT article you may be wrong. (Which is a good thing for the enthusiast community and AMD if this follows through)


http://www.anandtech.com/show/6347/amd-a10-5800k-a8-5600k-review-trinity-on-the-desktop-part-2/2

For the foreseeable future I don't see AMD closing the single threaded performance gap. Jim Keller's job is to fix this problem, but it'll probably take 2 - 3 years to get there.

 

[Ajay]

Steamroller is going for lower clocks than Bulldozer and Piledriver. While the FPU might be double clocked though but not the cores or the front-end.

That's bad news, even if SR has 15% higher IPC, then the net throughput might not change at all. Well, it could be good new for notebook chips and even servers (so long as the module count goes up). High density datacenters are pretty sensitive to cooling requirements (their biggest operating expense).

If SOI is 5 times the cost of Bulk, then how much more expensive is FD-SOI.

Double pumping the FPU makes sense in narrowing the gap between Haswell and SR, but how do you deal with the disparity with the L1$ (which, I imagine would have to run at the core clock)? Hmm, I think the was some discussion on this when comparing the P4 uArch to Bulldozer - maybe search will be my friend.

 

[Idontcare]

According to the AT article you may be wrong. (Which is a good thing for the enthusiast community and AMD if this follows through)


http://www.anandtech.com/show/6347/amd-a10-5800k-a8-5600k-review-trinity-on-the-desktop-part-2/2

I think you are misinterpretting Anand's statement.

One person is not going to wave a magic wand and close a gap that was created at the expense of billions and billions of R&D dollars. It doesn't work like that.

But you can spend billions and billions of dollars and not get anywhere, having the wrong people will do that for you.

So all Anand is saying is that at least with Keller in place, AMD won't be spending billions to get nowhere. But wherever Keller is taking them it won't be available for the market for 2-3 yrs because that is the design cycle for these ICs.

But no matter how awesome Keller is, he isn't going to single handidly bring down Intel, even if he had $100B at his disposal. And he has even less than his counterpart at Intel when it comes to R&D budget.

For this to be a "K8 part deux" it will take a serious misstep by Intel at the exact same time.

 

[Ajay]

According to the AT article you may be wrong. (Which is a good thing for the enthusiast community and AMD if this follows through)


http://www.anandtech.com/show/6347/amd-a10-5800k-a8-5600k-review-trinity-on-the-desktop-part-2/2

Jim Keller would have to have come in to AMD with a clear idea on what needed to be done just to make a significant impact on Excavator. I really hope he succeeds, but time is against him unless GF can accelerate it's process roadmap.

 

[Rvenger]

I think you are misinterpretting Anand's statement.

One person is not going to wave a magic wand and close a gap that was created at the expense of billions and billions of R&D dollars. It doesn't work like that.

But you can spend billions and billions of dollars and not get anywhere, having the wrong people will do that for you.

So all Anand is saying is that at least with Keller in place, AMD won't be spending billions to get nowhere. But wherever Keller is taking them it won't be available for the market for 2-3 yrs because that is the design cycle for these ICs.

But no matter how awesome Keller is, he isn't going to single-handedly bring down Intel, even if he had $100B at his disposal. And he has even less than his counterpart at Intel when it comes to R&D budget.

For this to be a "K8 part deux" it will take a serious misstep by Intel at the exact same time.

I am sure Jim probably has a whole team focusing on this issue as well don't you think? I didn't think he himself would single-handedly fix the issue but he could have his team focus in a different direction.

EDIT: Then again on the flipside of things... 2-3 years might be too late for AMD.

 

[AtenRa]

If SOI is 5 times the cost of Bulk, then how much more expensive is FD-SOI.

The SOI(PD & FD) wafers may be more expensive but the end product may be close to Bulk price process because of fewer(Less) stages in the manufacturing process. So at the end, your product could cost the same to manufacture.

There are other factors effecting total manufacturing cost, like Gate First that according to GloFo it is cheaper than Gate Last, the production volume (the more you produce the cheaper it gets, most of the time) and more.

 

[Olikan]

And before that it was Pilediver, always the nextgen...never reaches the goal. the difference only keeps expanding. AMD will never get close to Intel IPC. Only slower and slower.

mmm...
sandy to ivy = ~7%
bulldozer to triny = ~7%
ipc diference stayed the same (yes, a shamefull 70%)

meanwhile, ST is supposed to have 30% more ipc, while haswell 10%

btw... bulldozer get 20% more ipc with one core disabled in the module...so is not that unreal ST reach 30%

 

[pelov]

I am sure Jim probably has a whole team focusing on this issue as well don't you think? I didn't think he himself would single handedly fix the issue but he could have his team focus in a different direction.

I think it has less to do with his own abilities as an engineer and more to do with his influence. He has the ability to point AMD in a direction where the money is rather than targeting clock speeds and moar coars. Keller is the type of person that when he says "Shutup and listen to me" people will listen.

The issue AMD has is whether they'll be able to survive the 2 or 3 years to get there.

 

[AtenRa]

btw... bulldozer get 20% more ipc with one core disabled in the module...so is not that unreal ST reach 30%

Don't thing so, Single thread in the Module is not like a single core(Phenom). The module is designed to work with 100% efficiency when we have two threads. Although a single core inside the Module would have all the resources available i believe the execution units (Int and FP) of the single Core of the Module are not able to calculate what the Front end can feed.
Also, the design is such that BD can have more performance scaling the more threads it gets.

 

[pelov]

The module is designed to work with 100% efficiency when we have two threads.

That's not true. You forgot the 20% CMT tax

He's right, but he's not stating it the right way. When tasked with 2 threads on a single module, there's a dip in performance (depending on the workload) by ~20% due to the shared front end. When splitting the threads to different modules altogether that tax is avoided, but then you have to factor in the loss of efficiency and the turbo scaling as well.

 

[Olikan]

That's not true. You forgot the 20% CMT tax

He's right, but he's not stating it the right way. When tasked with 2 threads on a single module, there's a dip in performance (depending on the workload) by ~20% due to the shared front end. When splitting the threads to different modules altogether that tax is avoided, but then you have to factor in the loss of efficiency and the turbo scaling as well.

bulldozer decoders don't work like that...
they jump from one core to another, starving both cores...this happen even with one core off

more here:
http://www.xtremesystems.org/forums/showthread.php?275873-AMD-FX-quot-Bulldozer-quot-Review-%284%29-!exclusive!-Excuse-for-1-Threaded-Perf
http://www.xtremesystems.org/forums/...-Threaded-Perf

 

[pelov]

That looks to be about 20%. It's also a pretty good benchmark because it's light on cache. TechReport did something similar by assigning threads to specific cores, 0>3, and then noting the disparity between the scores. The average was about what the benchmark above shows. 20%

The thread scheduler fix that was jointly released by AMD and Windows didn't actually do what happens above because when splitting the threads across modules rather than within modules, the power consumption spikes up as soon as you've powered up modules.

 

[Ajay]

[switched quote order]

bulldozer decoders don't work like that...
they jump from one core to another, starving both cores...this happen even with one core off

Wow, that's something I hadn't read b/4, unless your talking about the Windows OS problem. But if this is the hard coded behaviour of the scheduler - shame on AMD! Man, that MPU is a freaking disaster

I wonder what was fixed in Vishera (PD 2.0). Supposedly it has been improved more than Trinity.

mmm...
sandy to ivy = ~7%
bulldozer to triny = ~7%
ipc diference stayed the same (yes, a shamefull 70%)

meanwhile, ST is supposed to have 30% more ipc, while haswell 10%

btw... bulldozer get 20% more ipc with one core disabled in the module...so is not that unreal ST reach 30%

Well, if it really is 30% (which is somewhat plausible given how terrible Bulldozer is) Then that's a different story. We could see lower clocks but still have higher throughput for SR. I buy the best system for my needs, but it sure would be nice to see AMD make this kind of jump. Then there is some hope that Excavator will actually be competitive in some areas with Haswell - maybe even "int the ball park" integer performance. I realize that Excavator will be one year behind Haswell, but Haswell's successor isn't likely to add much in the way of IPC.


PS This is sort of like setting up a fantasy football team b/4 the rosters as set, so I'm musing about things that could be.

 

[Ajay]

I think you are misinterpretting Anand's statement.

One person is not going to wave a magic wand and close a gap that was created at the expense of billions and billions of R&D dollars. It doesn't work like that.

But you can spend billions and billions of dollars and not get anywhere, having the wrong people will do that for you.

So all Anand is saying is that at least with Keller in place, AMD won't be spending billions to get nowhere. But wherever Keller is taking them it won't be available for the market for 2-3 yrs because that is the design cycle for these ICs.

But no matter how awesome Keller is, he isn't going to single handidly bring down Intel, even if he had $100B at his disposal. And he has even less than his counterpart at Intel when it comes to R&D budget.

For this to be a "K8 part deux" it will take a serious misstep by Intel at the exact same time.

Well put. I think Keller could have some impact on Excavator, but really, it'll be the next CPU in the cycle after Excavator that will be a all "Keller & team" part. I just don't see a "K8 part 2", because Intel seems to be firing on all cylinders. If Haswell comes up significantly short in some area (first new uArch since core2) then that would be an opportunity for AMD, but Intel is clearly lowering release expectations so that they have the room to get it right.

All** AMD needs to do is narrow the gap sufficiently that folks in general won't care (it's 5% slower, but 10% cheaper sort of thing). Eh, if wishes were horses, beggar would ride.

**which is a major undertaking.

 

[happysmiles]

AMD has already priced their top Trinity APU against Intel i3

i3 not i5 or i7.

it beats it in some and loses in some. In the gaming side it wins either way IN THE PRICE POINT.

 

[Olikan]

Wow, that's something I hadn't read b/4, unless your talking about the Windows OS problem. But if this is the hard coded behaviour of the scheduler - shame on AMD! Man, that MPU is a freaking disaster
I wonder what was fixed in Vishera (PD 2.0). Supposedly it has been improved more than Trinity.

nop, the windons fix was more about the core parking and FPU
...the decoder jumping is a hardware poor design, and will be fixed in steamroller

Vishera will be able to execute more instructions per clock...most important: 4 movs, instead of 2 per clock

 

[NostaSeronx]

The SOI(PD & FD) wafers may be more expensive but the end product may be close to Bulk price process because of fewer(Less) stages in the manufacturing process. So at the end, your product could cost the same to manufacture.

Should not could 65-nm through 32-nm SOI for AMD has been the worst for AMD. 130-nm and 90-nm did what SOI was advertised to do but 65-nm, 45-nm, and 32-nm performed worse than Bulk.

Vishera will be able to execute more instructions per clock...most important: 4 movs, instead of 2 per clock

That's for Komodo which was killed off and delayed to Steamroller.

That's bad news, even if SR has 15% higher IPC, then the net throughput might not change at all. Well, it could be good new for notebook chips and even servers (so long as the module count goes up).

It's 45% more IPC not 15% more IPC. The Front-end is getting doubled in power you have one 64B window instead of one 32B window. You have 8 decoders which are divided in to two portions one for Thread A and one for Thread B. The execution cores now operate like AGLUs where the EX units don't need the AGLU units to read from memory. The floating point is less redundant which allows it to have a higher clock than before. The L2 core interface is renewed or changed to have more, cache and performance. Execution Speed has been doubled at every point. Which leads to a 45% increase in instructions per cycle being executed.

 

[Idontcare]

I am sure Jim probably has a whole team focusing on this issue as well don't you think? I didn't think he himself would single-handedly fix the issue but he could have his team focus in a different direction.

EDIT: Then again on the flipside of things... 2-3 years might be too late for AMD.

Of course I don't mean Keller as in himself, I mean all that he has the ability to influence and direct through direct-reports and peers.

My point was more to say that even if Keller is God's gift to the microprocessor world, be it his personal engineering prowess or his ability to rally talented engineers to do miraculous things in his wake, it still takes money - lots and lots of money - to design the kinds of complex microprocessors that Intel is spending billions to design right here and now.

Today's CPUs take thousands of talented engineers, not dozens, to create. And it takes lots of money to hire thousands of talented engineers.

There is a reason AMD is in no danger of Via rising up and fielding a product that challenges them. Likewise for Intel from AMD.

The SOI(PD & FD) wafers may be more expensive but the end product may be close to Bulk price process because of fewer(Less) stages in the manufacturing process. So at the end, your product could cost the same to manufacture.

There are other factors effecting total manufacturing cost, like Gate First that according to GloFo it is cheaper than Gate Last, the production volume (the more you produce the cheaper it gets, most of the time) and more.

The choice to go SOI or to not go SOI is one of accounting - as in the financial kind - through and through.

SOI provides an immediate time-zero improvement in a key set of parametric parameters (mostly relating to leakage).

Basically your process development engineers don't have to spend time and effort designing a process flow that delivers on those parametrics, they are baked into the node by virtue of the SOI itself.

Now the natural question for management is "can we get the same electrical results delivered by SOI but without resorting to using SOI wafers?" And the process development engineers respond "of course, but it will cost you about 100 process development engineers working on it for 4 yrs and you will need to burn through an extra $100m per year in R&D money to support their development efforts".

So the accountants sit back and run some numbers. "If we don't go with SOI but we spend R&D money to get the same benefits then we are going to spend an extra $400m upfront in R&D costs - does that cost us money in the long run?"

So now the fab capacity modelers are brought in - "How many wafers are you going to run on Node XYZ in its lifetime?"

Because if the number is large enough, then the company will spend less on SOI wafers by spending more on developing a node that doesn't depend on them.

Now if the fab planning folks come back with too low of a wafers/node-lifetime number then the accountants are going to tell the process node development engineers that they are too costly and they should just go with SOI and save the company money in the long run.

In the end SOI is not about technological advantage - it is about net cost (R&D + manufacturing expense) to the company.

If AMD's wafer volumes were not so low then AMD would have never gone SOI. It is as simple as that. I personally was involved in assessing SOI versus bulk-Si for Texas Instruments and the decision literally came down to that. As it did for AMD (I worked with enough ex-AMD'ers hired to work at TI to know) and it didn't work out for Intel (or just about anyone else) for the same reasons.

The question for AMD, a fabless company, going forward is does it make sense to continue to pay the price premium in manufacturing costs per wafer as needed to convince GloFo to continue to develop SOI-specific nodes, or does it make more sense to take advantage of the cost reduction opportunities that using a foundry is meant to bring to the fabless customer (who benefits from the aggregation of many fabless customers orders so as to sustain the foundry model in the first place).

 

[pelov]

The question for AMD, a fabless company, going forward is does it make sense to continue to pay the price premium in manufacturing costs per wafer as needed to convince GloFo to continue to develop SOI-specific nodes, or does it make more sense to take advantage of the cost reduction opportunities that using a foundry is meant to bring to the fabless customer (who benefits from the aggregation of many fabless customers orders so as to sustain the foundry model in the first place).

So in a way what you're saying is, AMD's decision will hinge upon whether GloFo secures other big contracts?

 

[Idontcare]

So in a way what you're saying is, AMD's decision will hinge upon whether GloFo secures other big contracts?

Exactly.

Same reason TSMC cancelled 32nm. Not enough fabless customers were interested in buying 32nm wafers...so TSMC ran the numbers and decided it wasn't worth the R&D expense to develop the node in the first place.

The accoutants at Global Foundries are running the same numbers on continuing to develop SOI-based nodes. If AMD isn't willing to pay the premium and deliver on the volume orders then GloFo simply can't afford to pursue SOI going forward for all the same reasons AMD couldn't (which was the same reason AMD spun-off their fabs to form GloFo in the first place).

 

[NostaSeronx]

Same reason TSMC cancelled 32nm. Not enough fabless customers were interested in buying 32nm wafers...so TSMC ran the numbers and decided it wasn't worth the R&D expense to develop the node in the first place.

TSMC cancelled 32-nm because it was SOI. TSMC was going to be the second foundry for 32-nm for AMD.

TSMC -> 32-nm SOI, the only customers AMD, IBM, Sony, and Microsoft. The reason it was cancelled was because initial benchmarks showed that SOI showed no improvement over the previous bulk node 40-nm from TSMC. TSMC was like no one but AMD, IBM, Sony, and Microsoft are going to buy because they are dimwits for SOI. So, TSMC dropped it like a rock and is now sporting a HUGE profit from 28-nm Bulk where is GlobalFoundries at this time... oh yeah in the red.

http://www.xbitlabs.com/news/other/...es_Unlikely_to_Become_Profitable_Shortly.html
^- See what the owners of AMD & ATIC say about GloFo.

http://www.eetimes.com/electronics-news/4390689/TSMC-profit-soars
^-- TSMC profits