Qualcomm Krait & MSM8960 @ AnandTech

[anexanhume]

For starters, it's probably a lot cheaper to license an instruction set from ARM than an entire IP core.

Furthermore, the 1st-Gen Snapdragons were clear CPU performance winners compared to Cortex A8, and Krait has the advantage of being available sooner than Cortex A15 about half a year, making it clearly better than Cortex A9 solutions. These launch dates asynchronous with the other SoC manufacturers are usually good (look at Tegra 2).

So do they save money in volume justifying their R&D costs?

I disagree about launching sooner. Exynos 52xx will be ready in Q2. Are there any announced krait design wins?

Also, was snapdragon clear performance winner over cortex A8? I don't remember it walking all over OMAP 3430 or the 600 MHz Samsung SoC.

 

[metafor]

So do they save money in volume justifying their R&D costs?

I disagree about launching sooner. Exynos 52xx will be ready in Q2. Are there any announced krait design wins?

Exynos was announced relatively early compared to the rest of the a15 crowd. Most are by end of the year. I though Samsung's roadmap in the Samsung thread indicated they won't have an a15 part before 2013 though.

I believe the padfone and htc Ville are two designs that have gone public. As for whether it's worth it compared to just licensing an ARM core. It probably wasn't worth it to choose Scorpion over A9 -- but I'd say Krait has some definite advantages against A15.

Also, was snapdragon clear performance winner over cortex A8? I don't remember it walking all over OMAP 3430 or the 600 MHz Samsung SoC.

From cpu performance, sure. It scaled to 1ghz on 65nm and had far better FP performance. That didn't impact benchmarks very much, but actual applications such as ii rendering on Sense, for instance, benefited significantly. Not insanely ahead, but enough to gain an advantage.

 

[Laurent06]

For starters, it's probably a lot cheaper to license an instruction set from ARM than an entire IP core.

No it isn't, an architecture license is more expensive than a core license.

 

[Lazy8s]

I think an architecture license can be like 20x the cost of licensing a core, but do they save on the royalty after that?

Either way, it allowed Qualcomm to get their next gen to market earlier, which is a big deal where positioning into a handset maker's product line is so important.

 

[ltcommander.data]

I think an architecture license can be like 20x the cost of licensing a core, but do they save on the royalty after that?

Either way, it allowed Qualcomm to get their next gen to market earlier, which is a big deal where positioning into a handset maker's product line is so important.

Are reference designs included as part of licensing a core? I'm just wondering where a custom core implementation/layout like Hummingbird/Apple A4 compare to just using a stock reference core design like nVidia or a completely unique design like Qualcomm.

 

[metafor]

Are reference designs included as part of licensing a core? I'm just wondering where a custom core implementation/layout like Hummingbird/Apple A4 compare to just using a stock reference core design like nVidia or a completely unique design like Qualcomm.

NVidia also does custom layouts and implementation. Most people do. Hummingbird was unique in that the insertion of domino circuits was automated via a cad tool invented by intrinsity.

ARM simply doesn't and can't target all performance and perfect/W ranges. So if you want something in a region they don't provide, you'll have to build your own.

 

[dagamer]

Do we have an ETA on when this SoC will be popping up into phones? Are we waiting for a CES full reveal?

 

[Helmore]

Do we have an ETA on when this SoC will be popping up into phones? Are we waiting for a CES full reveal?

I expect MWC 2012 at the earliest, although think that April 2012 is a bit more realistic. Just my (uneducated) guess.

 

[dagamer]

I expect MWC 2012 at the earliest, although think that April 2012 is a bit more realistic. Just my (uneducated) guess.

As far as I know, the 8960 will be the first SoC to have a 28nm LTE chipset inside. Does this mean we're going to finally get a 4G phone that doesn't have horrendous battery life? >_<

 

[anexanhume]

As far as I know, the 8960 will be the first SoC to have a 28nm LTE chipset inside. Does this mean we're going to finally get a 4G phone that doesn't have horrendous battery life? >_<

It would be better by virtue of being on a smaller process and being an integrated solution, but probably still worse than 3G. Takes power to move data faster.

 

[french toast]

ARUN; I saw an article a few weeks back on Toms hardware titled 'Intel will overtake Qualcomm in 3 years'' now im not discussing the theme of the article, but rather some interesting points i picked out about the Krait architecture, and things that you have not mentioned which may be of interest/give Krait an advantage over A-15.

Statement from that article;

with the upcoming Cortex-A15, the company will be relying on dedicated reservation stations (the instruction queue) for each of the execution units. While Intel and AMD used dedicated reservation stations in the past, both now employ unified reservation stations to improve performance and utilization. Unlike ARM, Qualcomm is attempting to jump directly to a unified reservation station design.

http://www.tomshardware.com/reviews/medfield-krait-smartphone-mobile-soc,3117-3.html

I also read somewhere that Krait utilises a special low latency L2 thats on its own power plane and if i remember something like its OoO or something, i cant for the life of me find the links to that, or whether i have remembered it correctly..perhaps you have some info and could enlighten us?

What advantages (if any) do you think the above optimisations will have on performance/power consumption compared to Cortex A-15?

 

[Arun]

Statement from that article;

Like quite a few other things in that article, it's not a very technically accurate statement. I'm not aware of Intel ever using dedicated reservation stations (the P6 family certainly never had them) and while AMD did somewhat unify the RS in Bulldozer, they're still separate between INT and FP (see: http://realworldtech.com/page.cfm?ArticleID=RWT082610181333&p=7)

The A15's OoOE engine is actually significantly higher performance than Krait's and one reason for the (semi-)dedicated reservation stations is to allow a greater number of total entries without increasing pipeline length or power consumption (but overall power of the A15 OoOE engine should still be much higher unfortunately). Anyway while the A15's approach is most similar to AMD's K10, it is so for very different reasons, and there are pretty deep and fundamental differences in the non-public parts of the A15 and Krait.

I think it's fair to say the A15 won't be able to touch Krait for power efficiency in smartphones, and Krait won't be able to touch A15 for performance in tablets. The really interesting part starts with ARM big.LITTLE and the A15+A7 chips but those will lag behind initial Krait devices by maybe more than a year and by then Qualcomm might already have moved to High-K and/or slightly beefed up their architecture.

I also read somewhere that Krait utilises a special low latency L2

Krait has both a L0 cache and (like the currently shipping MSM8x60) it has a separate voltage domain for the L2. I don't think there's any public information on whether A15 does anything fancy on that front but it's fair to say Qualcomm has been very innovative in terms of power and voltage planes in recent years. It does slightly increase the cost of their solutions but overall it's probably well worth it (especially as they design their own PMICs etc...)

 

[french toast]

Yea i think you have summed it up well, Krait optimised for smartphones. A15 for tablets, with both able to operate in each others domains very well.

I had just read a number of specialist articles on Krait right after the Medfield release and them banging on about their advantage with L2 compared to ARM designs, i was pleased to have read that Qualcomm at least, has worked to address those areas, and in doing so prepared its self well to counter silvermont.

The whole big_LITTLE approach does look to be a genuine threat to Qualcomm 12 months down the road, although Kraits can be shipping in 2ghz quad core form into smatphones within a year if they wish..it doen't sound like we will see 4x cortex A15s in smartphones for many years..if at all, so for power consumption and multithreading scenarios is where Qualcomm carries the advantage.

I suspect for IPC we are going to get to the stage of where we are with desktops, more than enough, i mean once we get to a duel core Cortex A15 @2.0ghz, another 500mhz increase is not going to matter a jot to your average consumer, and we reach that stage in a few months!:smile:

 

[metafor]

After Cortex-A8, ARM decoupled the L2. Some implement it on a separate power plane and others not. Tegra 3, for instance, does separate the L2 power domain.

It's really not that big a deal. I have a hard time believing -- post A8 -- that anyone doesn't keep their L2 on a separate power plane.

As for big.Little, despite the hype, I don't anticipate it solving the major problem of sustained usage. For instance, during a heavy game or a very heavy interactive UI.

That being said, as processors -- even the "low profile" ones -- become more and more powerful, I suspect we'll get to a point where the heavy hitter CPU's will be used only a small fraction of the time.

Hell, I am surprised no one has mentioned 4xA7 + 1-2x A15. That, for a handheld application, seems far more balanced towards the typical workload.

 

[liem107]

From what I read about A7, you must have the same numbers of A7 than the numbers of A15.

 

[Laurent06]

From what I read about A7, you must have the same numbers of A7 than the numbers of A15.

What makes you think so? It's not because the big.LITTLE paper presents 2xA7 paired with 2xA15 that it's a requirement.

 

[Arun]

What makes you think so? It's not because the big.LITTLE paper presents 2xA7 paired with 2xA15 that it's a requirement.

It's absolutely not a requirement, however for the initial Android implementation, you cannot use the A15s and A7s simultaneously and they must act as if there was only a single kind of core. That means that you cannot benefit from having more A7 cores than A15 cores but that's only a software limitation and it will go away over time (sadly I have no idea about the timeframe - I think first it needs to be implemented and proven stable for Linux then Google has to integrate that version of the kernel - and all of these steps definitely take time before even taking the technical challenge into account).

I also have a hard deadline for my article on big.LITTLE and CPU process technology so I should have finished it this week-end. Hopefully that won't force me to compromise quality too much, especially as it's a somewhat controversial subject for some people I think

 

[wishiknew]

Hey Arun. Is Beyond3D still doing that Mali article?

 

[dagamer]

What makes you think so? It's not because the big.LITTLE paper presents 2xA7 paired with 2xA15 that it's a requirement.

Having the same number of A7 and A15 cores means that the operating system can be 100% oblivious to any core switching between the two CPU architectures and is truly OS-agnostic Introducing more complexity at such a low level is sure create problems if not done exactly right. At the very least, they should get 2xA7+2xA15 designs under their belt before doing anything fancier.

 

[Laurent06]

Having the same number of A7 and A15 cores means that the operating system can be 100% oblivious to any core switching between the two CPU architectures and is truly OS-agnostic Introducing more complexity at such a low level is sure create problems if not done exactly right. At the very least, they should get 2xA7+2xA15 designs under their belt before doing anything fancier.

The big.LITTLE thing can't be completely OS-agnostic: the CPU are not the same (though they should still be compatible), but more importantly your L2 caches don't have the same size and so their software maintenance will be different.