AMD: R9xx Speculation

It's hard to tell, but I suspect they're hinting that they will license a hard macro of the Cortex-A9 on the GF 28nm process, similar to the 40nm TSMC one they are selling today (going up to 2GHz). Given how much they are emphasing their partnership with GF, I can only assume that is an exclusive deal for 28nm.
 
Does ARM coming out with a 28nm chip have any relevance in my desire in seeing a 28nm ATI GPU from GF this year?
 
It's hard to tell, but I suspect they're hinting that they will license a hard macro of the Cortex-A9 on the GF 28nm process, similar to the 40nm TSMC one they are selling today (going up to 2GHz). Given how much they are emphasing their partnership with GF, I can only assume that is an exclusive deal for 28nm.

Why would ARM ever do an exclusive deal with GF? That makes no sense. TSMC is the 800lb gorilla. That's like someone doing an exclusive server deal with AMD. It only works if they are a low volume player.

ARM isn't low volume and I'm pretty sure they will offer hard macros on TSMC as well.

DK
 
Was reading the Techreport Phenom II X6 review. Sounds like GF's updated/tweaked 45-nm process sure improved power consumption.
 
ARM isn't low volume and I'm pretty sure they will offer hard macros on TSMC as well.
That seems logical on first sight, but you're forgetting one thing: hard macros have not been a core competency of ARM in recent times. Where's the Cortex-A8 hard macro? Where's the 90 or 65nm ARM11 hard macro? The 40nm Cortex-A9 hard macro is a new IP category for them, and it's not a massively high volume one.

Furthermore, the team assigned to it isn't huge either and the differences between the TSMC and IBM processes on 28nm are greater than they have been at least since 90nm, probably more. And finally, remember that ARM is working on the next-gen Eagle core and they'll likely want to shift hard macro resources to that as soon as the RTL is in a mature enough state (whether they'll invest in doing both a GF and TSMC Eagle hard macro is anyone's guess at this point and probably depends on how successful their prior macros have been).

Back on topic: in yesterday's CC, TSMC has indicated that they are engaged with 20 customers for 28nm and expect more than a half-dozen tape-outs this year. This is more or less in line with NVIDIA's indications that 28nm end-products probably won't be available before early 3Q11 iirc (remember RV740/GT216/218 also taped-out in Q4 with launches in Q2&Q3). That should tell you to expect 28nm AMD GPUs in 2Q11 at the earliest, which makes me think they might try to prioritize a notebook-centric GPU first to get a few Back-to-School design wins with it.
 
at least a year on 40nm with no possibility to really increase transistor on new product is really hurting :S
i realized only now how much :S
 
at least a year on 40nm with no possibility to really increase transistor on new product is really hurting :S
i realized only now how much :S

Well the density doubling time period is ~2years now a days. So that should be expected.
 
at least a year on 40nm with no possibility to really increase transistor on new product is really hurting :S
i realized only now how much :S

AMD would seem to have some headroom on the same process. They could add 50% more and still only tie Nvidia.
 
Well the density doubling time period is ~2years now a days. So that should be expected.

True but up until last year you had the option of a half node every alternate year as well, these usually brought about a 19% reduction in die size. If 32 nm had still been on track we probably would have seen products by the end of this year. As Arun said, dosent look like we'll see any 28nm products before Q2 2011.

But what next, 22nm is only scheduled for Q3 2012, and TSMC is rumoured to be cancelling it and going to 20nm directly again!
 
What is a hard macro?
A preplaced, prerouted template that you can just dump into the layout of your chip.

Which means you don't need to spend effort to close timing on it. It usually will have better performance than when you do it yourself.
 
A preplaced, prerouted template that you can just dump into the layout of your chip.

Which means you don't need to spend effort to close timing on it. It usually will have better performance than when you do it yourself.

So how's that different from 'a synthesizable core' like Bobcat? That is supposed to be "compiled" into silicon too. I assume tools should be able to close timings on such things without any noticeable human effort.
 
rpg.314 said:
I assume tools should be able to close timings on such things without any noticeable human effort.
Your assumptions are very, very wrong. ;)

Closing timing is always a struggle if you're shooting for the best possible performance (which is not necessarily always the case, but it often is for a CPU: look how review sites will always mention the CPU clock speed for the latest and greatest smartphone.)

The default settings of the tools will get you to some particular base level that anyone can reach. After that, it's hard work to squeeze out higher and higher clock speeds.

Note that Apple thought it was worth spending $125M for a company who's prime business was cranking out hard macros...
 
Your assumptions are very, very wrong. ;)

Closing timing is always a struggle if you're shooting for the best possible performance (which is not necessarily always the case, but it often is for a CPU: look how review sites will always mention the CPU clock speed for the latest and greatest smartphone.)

The default settings of the tools will get you to some particular base level that anyone can reach. After that, it's hard work to squeeze out higher and higher clock speeds.

Note that Apple thought it was worth spending $125M for a company who's prime business was cranking out hard macros...

So if I may borrow from the terminology of sw, a synthesizable core is like giving away sw which the customer can compile himself. Modifications are subject to licenses, ofc.

A hard macro is sort of a binary distribution, which has been "compiled" by the vendor using it's own optimizing compiler (aka humans). Right?

Then it naturally raises the question why would ARM make a hard macro and license it exclusively to GF. GF making a hard macro out of ARM provided core makes sense. But why would ARM shoot itself in the foot by agreeing to an exclusive hard macro deal. Why wouldn't they let TSMC develop their own hard macros if they wanted to?
 
It'd be pretty cool if this thread got back on topic, but...
Then it naturally raises the question why would ARM make a hard macro and license it exclusively to GF. GF making a hard macro out of ARM provided core makes sense. But why would ARM shoot itself in the foot by agreeing to an exclusive hard macro deal. Why wouldn't they let TSMC develop their own hard macros if they wanted to?
TSMC can obviously do anything they want, and they're extremely smart about using their position to their advantage. But what ARM is doing here isn't licensing the right to make a hard macro; it's literally designing the hard macro themselves and licensing it to GF's (potential/actual) customers. And I'm saying it's possible that for resource allocation reasons ARM could only choose one foundry for their A9 hard macro on 28nm, and for strategic reasons it'd also make some sense to have selected GF.

If TSMC wants to hire a bunch of engineers to compete directly with both ARM and GF at the same time, they can, but I suspect that would make even less sense than an exclusive deal (which apparently quite a few people think makes no sense at all anyway - hey, if my opinions weren't sometimes a bit controversial, they'd be called facts!)
 
So if I may borrow from the terminology of sw, a synthesizable core is like giving away sw which the customer can compile himself. Modifications are subject to licenses, ofc.

A hard macro is sort of a binary distribution, which has been "compiled" by the vendor using it's own optimizing compiler (aka humans). Right?
Yes.

Then it naturally raises the question why would ARM make a hard macro and license it exclusively to GF. GF making a hard macro out of ARM provided core makes sense. But why would ARM shoot itself in the foot by agreeing to an exclusive hard macro deal. Why wouldn't they let TSMC develop their own hard macros if they wanted to?
See the comment of Arun. They are not preventing anyone to make their own hard macro, it's just that they may not do it themselves. Also, if the hard macros from ARM are based on the synthesizable RTL without major custom datapath design, there's no reason why licensees of the same RTL couldn't get the same results, given enough resources and time.

ARM doesn't exactly make it a secret how get the maximum performance out of their design. It's in their best interested for all customers to get the best out of it, so they go into gory details about it during conferences. Buying the hard macro is just a way to short cut process.
 
Back
Top