Windows for ARM CPUs...

Well, I'd rather have AMD and Intel shrinking and optimizing their x86 APUs into small devices, guaranteeing compatibility between desktop and mobile OS/drivers/APIs, than having ARMs crawling their way up into desktops/notebooks.
Even if (apparently) people do consider ARM's architectures as "superior" from a power/performance perspective.
 
The co processor approach, while attractive on surface, cannot explain the need for an arch license imo.

What I've been told is that you can't add a coprocessor to modern ARM designs anymore, it isn't something that's brought off of the RTL. So you do need an arch license for this.

ToTTenTranz said:
Well, I'd rather have AMD and Intel shrinking and optimizing their x86 APUs into small devices, guaranteeing compatibility between desktop and mobile OS/drivers/APIs, than having ARMs crawling their way up into desktops/notebooks.
Even if (apparently) people do consider ARM's architectures as "superior" from a power/performance perspective.

Intel is clearly trying to get there, AMD not really yet. You say you want x86 to be on mobiles for OS/kernel level compatibility, but then suggest that Windows for ARM means that MS wants to move ARM onto notebooks and desktops. Isn't it more likely that MS wants to move Windows down onto platforms currently dominated by ARM, like tablets?

It's not just the ARM is better for perf/Watt at the market segments it's currently targeting vs the current competition, but it's that ARM is by far the established regime. x86 obviously still has the desktop market, and the desktop market has proven that it can move down quite a bit - to laptops, then to netbooks - but I think that for most people that's pretty much the limit of its appeal. There are UMPCs, but those never exactly caught on. MS (and probably Intel) must have thought that tablets would be a continuation of PCs moving down, but Apple has proven this wrong, with a tablet that's very much a mobile moved up a bit. And Apple had full control of this decision, since they could have made an OS X/x86 based tablet instead - they must have had some reasoning in their decision, and I think it paid off well, as the rest of the industry is largely following.

The way I see it, most of the mobile market just has too little pragmatic incentive to move to x86. Most are now using Linux kernels or OSes developed specifically with ARM support (iOS, Symbian, Windows Phone), none of which benefit from x86 (quite the contrary, many probably aren't ported to x86 right now). The only benefactor would be MS with Windows proper, but since that's not an established market it makes much more sense for them to want to accommodate ARM than for mobile hardware vendors to want to accommodate them with x86. Most users just don't care about running traditionally x86 locked software (which is actually mostly just PC games) on these platforms. The mobile software ecosystem has already supplanted this.

But it's a little moot since most drivers and APIs and kernel code is probably not very locked into instruction set.
 
What I've been told is that you can't add a coprocessor to modern ARM designs anymore, it isn't something that's brought off of the RTL. So you do need an arch license for this.
Correct, but ARM added an optional Accelerator Coherency Port to the Cortex-A9 which allows other subsystems to have direct coherent access to the L2 cache. I'm not convinced it's a solution here though.

As for the architectural license, I honestly don't know.

Intel is clearly trying to get there, AMD not really yet.
I know this is a controversial position but in my opinion... AMD is there today, Intel is not. Bobcat is a great architecture that with minor incremental refinements and a process shrink to 20nm will be able to compete very nicely in handhelds whereas Atom is a dead-end. It's just too slow and expensive for what it is. It will still be roughly viable in Medfield's timeframe given the process advantage but that's about it. Intel is working on an architecture refresh and they better deliver.

It's not just the ARM is better for perf/Watt at the market segments it's currently targeting vs the current competition, but it's that ARM is by far the established regime. [...] Most are now using Linux kernels or OSes developed specifically with ARM support (iOS, Symbian, Windows Phone), none of which benefit from x86 (quite the contrary, many probably aren't ported to x86 right now). [...] Most users just don't care about running traditionally x86 locked software (which is actually mostly just PC games) on these platforms. The mobile software ecosystem has already supplanted this.[/QUOTE]Mostly agreed.

FWIW: I will be publishing a fairly ambitious article on handheld processors (with an emphasis on ARM) and system architecture next month. (hopefully in real time and not Valve time - or gosh, Beyond3D time!) - so if there's anything you want me to talk about, now's not a bad time to ask.
 
...
I know this is a controversial position but in my opinion... AMD is there today, Intel is not. Bobcat is a great architecture that with minor incremental refinements and a process shrink to 20nm will be able to compete very nicely in handhelds whereas Atom is a dead-end.
...
Mostly agreed.

FWIW: I will be publishing a fairly ambitious article on handheld processors (with an emphasis on ARM) and system architecture next month. (hopefully in real time and not Valve time - or gosh, Beyond3D time!) - so if there's anything you want me to talk about, now's not a bad time to ask.

Nice!
Isn't bobcat orders of magnitude off ARM in power consumption? Maybe ok for tablets at 20nm, but smartphones? Will you please write 2 paragraphs about possible bobcat evolution?

Handhelds is too broad a category (for me). I assume it includes smartphones (including basic €50 androids with 400Mhz arm11s) up to 10" tablets with huge batteries, errr, right?
 
Nice!
Isn't bobcat orders of magnitude off ARM in power consumption? Maybe ok for tablets at 20nm, but smartphones? Will you please write 2 paragraphs about possible bobcat evolution?
The AMD C-30 has a 9W TDP for the full chip (including GPU & memory controller) with two Bobcat cores at 1.2GHz on TSMC's 40G process. Based on the architecture, I'd expect IPC between the Cortex-A9 and Cortex-A15 (probably closer to the former than the latter).

As for Bobcat's evolution, I'm honestly not sure. It's certainly worth a paragraph along with possible Atom evolutions. Right now I've got quite a bit of discussion ready to write about future architectural evolutions for ARM but not enough for x86. In Bobcat's case, my point is that the base architecture is solid enough that with incremental refinements (the kind that wouldn't even show up on an architecture diagram) and a more power-centric synthesis process, they could be fairly close to a Cortex-A15's power efficiency (keep in mind the A15's power efficiency is likely slightly lower than the A9's). Assuming I understand that part correctly (the details are very sparse), Bobcat feels slightly too powerful in the load/store pipeline (relative to the execution resources) - but I think it's probably not worth nerfing it either. If you went from 2xDecode to 3xDecode, you'd probably want to keep that part as it is though (and likely also keep the SSE part 2-issue but boost it from 64-bit to 128-bit - so really the only major change would be the integer units).

Hmm - that's not an article-quality paragraph, but it's a start! :D

Handhelds is too broad a category (for me). I assume it includes smartphones (including basic €50 androids with 400Mhz arm11s) up to 10" tablets with huge batteries, errr, right?
I've mostly written the ARM part so far, and basically it's an architectural overview of nearly every single ARM core ever. Hopefully it'll serve as a useful reference and save everyone from having to dig deep into ten different articles to figure out some of this stuff. The system architecture part is yet to be written...

At this point I'm a bit scared that the article will be a huge wall of text with few if any pictures - not sure how that's gonna work out. If I'm not happy with it, I might decide to delay it to add some ugly diagrams :p (I expect I won't care enough to bother though)
 
I know this is a controversial position but in my opinion... AMD is there today, Intel is not. Bobcat is a great architecture that with minor incremental refinements and a process shrink to 20nm will be able to compete very nicely in handhelds whereas Atom is a dead-end. It's just too slow and expensive for what it is. It will still be roughly viable in Medfield's timeframe given the process advantage but that's about it. Intel is working on an architecture refresh and they better deliver.
Not sure why you say so. AFAIK an atom core is only 3W. Are you suggesting that a bobcat core consumes less power than that?
 
Well, since this is Beyond3D, I'd like you to mention and compare the GPU's families and evolutions that have been present in ARM chipsets for the past 3 years.

Mainly, the 3D capabilities that could have been but never where seen in many handsets due to the lack of manufacturer/developer commitment.
Seeing how the lite version of Rage runs on older iPhones, we have to wonder how stupid it is that we've had that kind of power on certain handsets for the last 4 years and all that we saw was a couple of ugly-looking games and benchmarks.

I don't really know if that's a given from the start, though.
 
FWIW: I will be publishing a fairly ambitious article on handheld processors (with an emphasis on ARM) and system architecture next month. (hopefully in real time and not Valve time - or gosh, Beyond3D time!) - so if there's anything you want me to talk about, now's not a bad time to ask.

Can I ask you to throw in your analysis of embedded gpu's as well? ;)
 
So my original plan was CPU+GPU instead of CPU+System Architecture, but I realised that was simply way too ambitious if I wanted to have any chance of releasing it in January. And the reason why I want to release it in January is that I'm going to Mobile World Congress 2011, and I'd like to have some stuff published I can refer to rather than just go there as a complete tourist :p There's also another company-specific article I'd like to publish before MWC, and that one makes more sense if I give an overview of handheld system architecture first rather than GPUs.

So hopefully I might even be able to get some more info about current/upcoming handheld GPUs at MWC11 and use that as part of an article coming out in March/April - of course if that's Beyond3D time, think March/April 2015.
 
Not sure why you say so. AFAIK an atom core is only 3W. Are you suggesting that a bobcat core consumes less power than that?

I haven't seen hard numbers from an official source, but I recall estimations from somewhere that Lincroft will draw around 1.3W for ~1GHz. Bear in mind this is on a power optimized process, similarly to how the lower clocked 800MHz Z500 was (and had a TDP of only 0.65W). This number would include CPU, GPU, and memory controller, with another amount needed for the I/O hub Langwell. I've seen estimations of 0.8W there.

Bobcat needs to be on this power optimized process to be competitive for phones, like Arun suggested. I don't really know what kind of burden (if any at all) it is on AMD to design and maintain the core for multiple processes. The platform also needs a more minimal southbridge option that drops SATA and PCI-E. Ideally AMD would have a full SoC available, as I'm sure Intel eventually will for Atom (not counting the CE line which isn't useful for mobiles). That would have to include a GPU, perhaps a very stripped down version of what they have in Ontario.

I could see it reaching cell phone power levels with enough design effort and 20nm, but that's got to be at least 2 years away. By the time 20nm is out the landscape will be totally different for ARM; Bobcat will offer better IPC than Cortex-A9, but I imagine that A9s MHz/Watt will still have enough of a lead that it'll overall still offer better perf/Watt.

While I agree that Atom isn't a great platform and is a dead end over the long term it can still feasibly launch cell phones today. So I think it's fair to say that Intel is currently there and AMD isn't.
 
I haven't seen hard numbers from an official source, but I recall estimations from somewhere that Lincroft will draw around 1.3W for ~1GHz. Bear in mind this is on a power optimized process, similarly to how the lower clocked 800MHz Z500 was (and had a TDP of only 0.65W). This number would include CPU, GPU, and memory controller, with another amount needed for the I/O hub Langwell. I've seen estimations of 0.8W there.

Bobcat needs to be on this power optimized process to be competitive for phones, like Arun suggested. I don't really know what kind of burden (if any at all) it is on AMD to design and maintain the core for multiple processes. The platform also needs a more minimal southbridge option that drops SATA and PCI-E. Ideally AMD would have a full SoC available, as I'm sure Intel eventually will for Atom (not counting the CE line which isn't useful for mobiles). That would have to include a GPU, perhaps a very stripped down version of what they have in Ontario.

I could see it reaching cell phone power levels with enough design effort and 20nm, but that's got to be at least 2 years away. By the time 20nm is out the landscape will be totally different for ARM; Bobcat will offer better IPC than Cortex-A9, but I imagine that A9s MHz/Watt will still have enough of a lead that it'll overall still offer better perf/Watt.

While I agree that Atom isn't a great platform and is a dead end over the long term it can still feasibly launch cell phones today. So I think it's fair to say that Intel is currently there and AMD isn't.

Well, only Intel has access to Intel's process leadership. And I don't think AMD has the money to make an impact (either from a process or arch perspective) in a market as competitive as smartphones and tablets.
 
Well, only Intel has access to Intel's process leadership. And I don't think AMD has the money to make an impact (either from a process or arch perspective) in a market as competitive as smartphones and tablets.

A couple of years ago, AMD didn't have the money to do a poke, much less an impact.
And look where we are now, with everyone just crying in anticipation for those cheap, decent performing and long battery lasting netbooks with Zacates.

And a year from now, we'll have those dirt-cheap (~$550) mid-low end 15" laptops with quad-cores and integrated HD5650s.


I'd call that an impact.
 
Well, only Intel has access to Intel's process leadership. And I don't think AMD has the money to make an impact (either from a process or arch perspective) in a market as competitive as smartphones and tablets.

So far Intel hasn't been exercising such leadership in low-power processes nearly as much as they have with desktops. Atom isn't on 32nm yet and won't be for many more months, much less in shipping devices. In fact, I'd be surprised if they were ahead of ARM SoCs on 32nm by more than half a year, and wouldn't be surprised if it was substantially less.
 
Well, only Intel has access to Intel's process leadership. And I don't think AMD has the money to make an impact (either from a process or arch perspective) in a market as competitive as smartphones and tablets.

Looks like Intel has a lot more to worry about from Nvidia and Arm...

Just like Windows is losing share to fast growing mobile alternatives and looking lost there, so is Intel.
 
Correct, but ARM added an optional Accelerator Coherency Port to the Cortex-A9 which allows other subsystems to have direct coherent access to the L2 cache. I'm not convinced it's a solution here though.

As for the architectural license, I honestly don't know.

ARM has specific things in their ISA to support control and status of coprocessors (via MRC and MCR's). This is generally how an ARM "coprocessor" is accessed (e.g. the FPU).

A lot of things are marked in the documentation as implementation defined, so to really make a coprocessor that isn't a peripheral where the processor is concerned (and thus have to be accessed via the L2, bypassing L0 and L1 caching as well as TLB caching), you'd have to have an architectural license and implement the coprocessor as part of the RTL.
 
Looks like Intel has a lot more to worry about from Nvidia and Arm...

Just like Windows is losing share to fast growing mobile alternatives and looking lost there, so is Intel.

Not so much lost, IMO, but it's making a case that Microsoft might have been wrong in merging the consumer Windows codebase with the NT codebase.

Personally, I think it was the right idea, but it certainly hampers Microsoft in both of those area's when each is required to carry the baggage of the other which then further hampers their ability to cut things down significantly for low power devices.

From the CES keynote, it appears that going forward with Windows 8, while the kernel will stay the same, there are going to be a LOT of Windows 8 variations tailored to the device class they are meant for.

Windoes 8 Phone, Windows 8 tablet, Windows 8 slate, Windows 8 netbook, Windows 8 desktop, Windows 8 TV, Windows 8 Zune, etc... Each with varying levels of services and features.

So unlike say OSX and iOS. Windows 8 desktop and Windows 8 phone will have the same kernel and will differ only in the included services and features.

Regards,
SB
 
Back
Top