Qualcomm's dual core up to 1,2GHz

[fehu]

http://gizmodo.com/5552176/qualcomms-dual+core-snapdragon-12ghz-chips++seen-in-a-smartphone-near-you-soon

:shock:
Smartphone or somethingpad only?

[Squilliam]

So now theres Snapdragon and Snaphydra? :-)

[fehu]

they can make more money filming them fight than selling them :P

[Helmore]

http://gizmodo.com/5552176/qualcomms-dual+core-snapdragon-12ghz-chips++seen-in-a-smartphone-near-you-soon

:shock:
Smartphone or somethingpad only?
This is meant for smartphones AFAICT. They also have their QSD8672 chipset, which has a dual core running at 1.5 GHz which they're targeting at both smartphones and at smartbooks and tablets.

Any word on the exact specification of this SoC? Like what the GPU specs are and what about power consumption?

[metafor]

The GPU is supposed to be an updated one for 45nm, the Adreno 205. The same as the one inside the MSM7x30. It brings it up to par with the SGX 535 offerings, but nothing earthshattering.

[fehu]

thermal and power are what make me hardly believe that this monster can fit in a phone form factor
even if i see it 0_0

[Ailuros]

thermal and power are what make me hardly believe that this monster can fit in a phone form factor
even if i see it 0_0

The thread title states up to 1.2GHz; if they scale down frequency and considering that SoCs like OMAP4 will also carry dual core CPUs I don't see what's there so impossible for smart-phones.

[metafor]

thermal and power are what make me hardly believe that this monster can fit in a phone form factor
even if i see it 0_0

There will really be very few situations where both cores will run at its maximum frequency and full load. In all likelihood, only one will ever be saturated while the other serves as a secondary processor to handle background routines.

In either case, this chip is made on 45 TPG, which cuts leakage by about 10x compared to 45G (typically what's used in mobile chips).

[Arun]

There will really be very few situations where both cores will run at its maximum frequency and full load. In all likelihood, only one will ever be saturated while the other serves as a secondary processor to handle background routines.Yup, of course there's a catch: unless Qualcomm decided to invest in an extra buck converter (dc/dc power regulator) on the power management chip, which is far from free, both cores need to run at the same voltage so there's a bit of waste there.

In either case, this chip is made on 45 TPG, which cuts leakage by about 10x compared to 45G (typically what's used in mobile chips).Uhm, surely you must be confusing processes here? Mobile chips are usually on 45LP/40LP, and I've never heard of anything called 45 TPG. Probably you mean 40LPG, which is a triple gate oxide process? Compared to 40G, it would indeed lower leakage by a lot, but compared to 40LP the advantage is noticeably higher performance for a slightly higher leakage (actually it's slightly more complicated than that, you need to compare highest-Vt 40G transistors to lowest-Vt 40LP transistors to get a better idea of the trade-off).

40LPG would certainly explain how they increased clock frequency by about 20% from the MSM7x30! That would be very interesting. AFAIK, Tegra2 is still on 40LP, but both NVIDIA and Qualcomm are standardizing on 28LPT (SiON triple gate oxide) and later 28HPM (High-K triple gate oxide), not sure about TI.

I'd mention how if NV meets their schedule for Tegra3 (to sample in Q4) then this chip looks quite unimpressive, but given NVIDIA's amazing execution lately for Tegra *cough* (their execution for taping out stuff has been good, but sadly there's more to life than sending money TSMC's way) I think I should just shut up ;)

[darkblu]

..but sadly there's more to life than sending money TSMC's way) I think I should just shut up ;)
I hear that in some cultures shipping GL ES drivers with your devkits is also highly regarded.

[Arun]

I hear that in some cultures shipping GL ES drivers with your devkits is also highly regarded.Haha, are you refering to the Linux boot image? AFAICT, WinCE/Android GL ES is supported properly at least. It's infinitely better than the early OMAP3 stuff anyway. Also presumably their non-Android Linux focus is on Chromium and WebOS, both of which nearly certainly work very differently from vanilla Linux in terms of exposing display acceleration. So I'm not exactly surprised they de-emphasised it.

I still believe the problem they had is they're focused on the premium market in markets where the rest of the ecosystem isn't mature enough to release anything premium. So all that happens is a bunch of design wins that get canned or delayed as people realize people are going to complain about XYZ limitations/problems (currently that's Flash becoming Froyo/2.2-only and Google only enabling the Android Market for tablets in Gingerbread/3.0 afaik). The same is true of Snapdragon outside of phones of course, which is why I'm mentioning that in this thread. They should have focused more on low-end 'impulse buy' products, but part of the problem I think is that 3G is too expensive for that and PC OEMs didn't want to encourage ASP erosion, so there were no viable distribution partners no matter how attractive the market.

[metafor]

Yup, of course there's a catch: unless Qualcomm decided to invest in an extra buck converter (dc/dc power regulator) on the power management chip, which is far from free, both cores need to run at the same voltage so there's a bit of waste there.

Yes, but at least one core can scale back its frequency, which, leakage being very small in TGO, actually is the main factor in power consumption.

Uhm, surely you must be confusing processes here? Mobile chips are usually on 45LP/40LP, and I've never heard of anything called 45 TPG. Probably you mean 40LPG, which is a triple gate oxide process?

Triple Gate Oxide, yes, but the library is referred to as "TPG" last I looked.

Compared to 40G, it would indeed lower leakage by a lot, but compared to 40LP the advantage is noticeably higher performance for a slightly higher leakage (actually it's slightly more complicated than that, you need to compare highest-Vt 40G transistors to lowest-Vt 40LP transistors to get a better idea of the trade-off).

Scorpion 1.5 will be on LP but the ones targetting ~1.2-1.3GHz are made on TGO 45.

40LPG would certainly explain how they increased clock frequency by about 20% from the MSM7x30! That would be very interesting. AFAIK, Tegra2 is still on 40LP, but both NVIDIA and Qualcomm are standardizing on 28LPT (SiON triple gate oxide) and later 28HPM (High-K triple gate oxide), not sure about TI.

I thought Tegra 2 was 40G?

[Arun]

Yes, but at least one core can scale back its frequency, which, leakage being very small in TGO, actually is the main factor in power consumption.Yep absolutely, of course there's still the catch that if you need 1.0v to run at 1GHz (aka Tegra2 according to devboard docs iirc) and need one core to run at full speed and another at just 200MHz which could work at, say, 0.7v then you're wasting a bit of power on that second core through that extra 0.3v... Of course, that's a small detail and I should really stop thinking about useless things like that ;)
Triple Gate Oxide, yes, but the library is referred to as "TPG" last I looked.Ahhh, library. I'm sure you're right - I was using the public process name rather than the library name.
Scorpion 1.5 will be on LP but the ones targetting ~1.2-1.3GHz are made on TGO 45.Intriguing thanks, makes a lot of sense :)
I thought Tegra 2 was 40G?I never checked specifically fro Tegra 2, but I know for certain Tegra 1 was on 65LP - and that exact same Tegra2 chip targets flagship smartphones so 40G would be rather surprising I think. Also iirc they need 1.0v to hit 1.0GHz as I said above, whereas ARM's "Osprey" Cortex-A9 synthesis on 40G (probably better than NV's but not unbelievably so, it's not full custom or anything fancy) has two versions: one power-optimized that does 800MHz at 0.81v and one speed-optimized that does 2GHz at 0.9v - so NV only managing 1GHz at 1.0v on 40G would be disappointing. It's much more likely they're using 40LP Multi-Vt with more lower Vt (higher leakage/higher performance) transistors in the CPU core IMO.

[metafor]

Yep absolutely, of course there's still the catch that if you need 1.0v to run at 1GHz (aka Tegra2 according to devboard docs iirc) and need one core to run at full speed and another at just 200MHz which could work at, say, 0.7v then you're wasting a bit of power on that second core through that extra 0.3v... Of course, that's a small detail and I should really stop thinking about useless things like that ;)

It will of course, but it isn't nearly as bad as scaling frequency.

I never checked specifically fro Tegra 2, but I know for certain Tegra 1 was on 65LP - and that exact same Tegra2 chip targets flagship smartphones so 40G would be rather surprising I think. Also iirc they need 1.0v to hit 1.0GHz as I said above, whereas ARM's "Osprey" Cortex-A9 synthesis on 40G (probably better than NV's but not unbelievably so, it's not full custom or anything fancy) has two versions: one power-optimized that does 800MHz at 0.81v and one speed-optimized that does 2GHz at 0.9v - so NV only managing 1GHz at 1.0v on 40G would be disappointing. It's much more likely they're using 40LP Multi-Vt with more lower Vt (higher leakage/higher performance) transistors in the CPU core IMO.

From ARM's website, it looks like both the power optimized and performance optimized hard macros are on 40G. The power-optimized hard-macro targets 800MHz with a estimate power consumption of 0.5W which sounds about on par with Tegra 2.

nVidia hasn't been traditionally good at designing for frequency, I wouldn't see it being too far off to have 1GHz at 1.0V at 40G. Keep in mind this is for the MP core.

This is just all speculation of course, I mostly thought it was 40G from some off-the-cuff comment.

[Wishmaster]

Arun it seems that they invested in additional dc/dc power regulator :)
Link (http://www.computerworld.com/s/article/9180475/Qualcomm_to_ship_fastest_chip_for_phones_tablets_i n_Q4) they added support for DDR2 and DDR3 and with 1080p support it should easily match tegra2 and OMAP4 offering :) The same should apply to msm8x60(probably not DDR3 support) which AFAIK is first dual core chip sampled(should appear in devices in 4Q this year).

What do you think?

[Arun]

The truly amazing thing with Qualcomm is that despite their overwhelming size, they're mind-blowingly agile. This is good news, as were all the other roadmap changes compared to what they announced in 2008 (the MSM7x30 changes seem to have been accomplished on particularly short notice). And their roadmap decisions since then are very smart and definitely impressive. I still think some of their technological subsystems aren't best-in-class, but with that kind of execution who cares?

It'd be even more impressed if something QSD8672-based did ship this year, but we shall see.

[Ailuros]

The truly amazing thing with Qualcomm is that despite their overwhelming size, they're mind-blowingly agile. This is good news, as were all the other roadmap changes compared to what they announced in 2008 (the MSM7x30 changes seem to have been accomplished on particularly short notice). And their roadmap decisions since then are very smart and definitely impressive. I still think some of their technological subsystems aren't best-in-class, but with that kind of execution who cares?

It'd be even more impressed if something QSD8672-based did ship this year, but we shall see.

There are many spots concerning the current Qualcolmm SoCs that can make me think that more than a few sw based optimizations could change quite a few things even today.

When I first read about the Dell Streak the first impression was definitely "wow". But after reading a couple of reviews like that one: http://www.anandtech.com/show/3853/the-dell-streak-review
the first excitement quickly got washed away.

IMHO whoever deals with SoCs has to realize how important software actually is. It won't do the consumer much good if he gets a great looking device but ends up with lacklustering performance and responsiveness. And no I don't think it's a pure hw problem in such cases.

[Wishmaster]

There are many spots concerning the current Qualcolmm SoCs that can make me think that more than a few sw based optimizations could change quite a few things even today.

When I first read about the Dell Streak the first impression was definitely "wow". But after reading a couple of reviews like that one: http://www.anandtech.com/show/3853/the-dell-streak-review
the first excitement quickly got washed away.

IMHO whoever deals with SoCs has to realize how important software actually is. It won't do the consumer much good if he gets a great looking device but ends up with lacklustering performance and responsiveness. And no I don't think it's a pure hw problem in such cases.

This problem should seize to exist with WP7 and after seeing their recent xbox live phone announcement I can't wait to see what kind of graphics can we expect from dual core msm8260(which seems to be based on z460), hopefully it will be used in all high end WP7 phones starting early next year.
But one thing is certain - 4Q'10 will be an interesting time of year :)

One question. Is it only me or does msm8255 is just qsd8250 with adreno 205 instead of 200 at 45nm and maybe some slight adjustments and performance improvements?

[Wishmaster]

It seeems that qualcomm has finally updated their webpage with specifications of msm7x30, msm8x55, msm8x60 and qsd8672.

QSD8672
Scorpion asynchronous dual-CPU cores, up to 1.5 GHz for faster response and processing
Integrated 3G mobile broadband connectivity
QSD8672 is a multi-mode chipset that support for HSPA+ networks – 14.4 Mbps downloads and 5.76 Mbps uploads as well as CDMA2000 1X, 1xEV-DORel A/B networks
Low-power 45nm process technology for higher integration and performance
High-definition (1080p) video recording and playback up to 30 frames per second
Multiple video codecs: (MPEG-4, MPEG-2, H.264 , H.263, VC-1, DivX, WMV-9, Sorenson Spark, VP6)
High-performance GPU - up to 88M triangles/sec and 532M 3D pixels/sec and dedicated 3D/2D acceleration engines for Open GLES 2.0 and Open VG 1.1 acceleration
High-resolution WSXGA (1440x900) display support
16-megapixel camera support
Built-in eighth-generation gps engine with Standalone-GPS and Assisted-GPS modes
Support for Wi-Fi ® and Bluetooth® connectivity
Multiple audio codecs: (AAC+, eAAC+, AMR, FR, EFR, HR, WB-AMR, G.729a, G.711, AAC stereo encode)
Support for mobile broadcast TV (MediaFLO™, DVB-H and ISDB-T)
Support for Android™, Brew® Mobile Platform and Windows® Phone

MSM8x60
MSM8x60 chipset platform consists of the MSM8260™ and MSM8660™.


Scorpion asynchronous dual-CPU cores, up to 1.2GHz for faster response and processing
Integrated 3G mobile broadband connectivity
MSM8260 support for HSPA+ networks – up to 14 Mbps downloads and 5.6 Mbps uploads – as well as GSM , GPRS and EDGE
MSM8660 support for HSPA+ networks – up to 14.4 Mbps downloads and 5.76 Mbps – as well as CDMA2000 1X , 1xEV-DO Rel A/B, GSM, GPRS and EDGE
Low-power 45nm process technology for higher integration and performance
High-definition (1080p) video recording and playback up to 30 frames per second
Multiple video codecs: (MPEG-4, MPEG-2, H.264, H.263, VC-1, DivX, WMV-9, Sorenson Spark, VP6)
High-performance GPU – up to 88M triangles/sec and 532M 3D pixels/sec and dedicated 3D/2D acceleration engines for Open GLES 2.0 and Open VG 1.1 acceleration
High-resolution WXGA (1280x800) display support
16-megapixel camera support
Built-in eighth-generation gps engine with Standalone-GPS and Assisted-GPS modes
Support for Wi-Fi® and Bluetooth® connectivity
Multiple audio codecs: (AAC+, eAAC+, AMR, FR, EFR, HR, WB-AMR, G.729a, G.711, AAC stereo encode)
Support for mobile broadcast TV (MediaFLO™, DVB-H and ISDB-T)
Support for Android™, Brew® Mobile Platform and Windows® Phone

MSM8x55
The MSM8x55 chipset platform consists of the MSM8255™ and MSM8655™ and features a newly designed and optimized multimedia sub-system over previous Snapdragon generations.

Scorpion 1 GHz CPU
Integrated 3G mobile broadband connectivity
MSM8255 support for HSPA+ networks – up to14 Mbps downloads and 5.76 Mbps uploads
MSM8655 support for HSPA+ networks – up to 14.4 Mbps downloads and 5.76 Mbps uploads – as well as CDMA2000 1X, 1xEV-DO Rel 0/A/B
Low-power 45nm process technology for higher integration and performance
High-definition (720p) video recording and playback up to 30 frames per second
Multiple video codecs: (MPEG-4, MPEG-2, H.264, H.263, VC-1, DivX, DivX 3.11, Sorenson Spark, On2 VP6)
High-performance GPU - up to 41M triangles/sec and 245M 3D pixels/se with dedicated 2D Open VG graphics hardware
High-resolution up to XGA (1024x768) display support
12-megapixel camera support
Built-in eighth-generation gps engine with Standalone-GPS and Assisted-GPS modes
Support for Wi-Fi® and Bluetooth® connectivity
Multiple audio codecs: (AAC+, eAAC+, AMR, FR, EFR, HR, WB-AMR, G.729a, G.711, AAC stereo encode)
Support for mobile broadcast TV (MediaFLO™, DVB-H and ISDB-T)
Support for Android™, Brew® Mobile Platform and Windows® Phone

MSM7x30
The MSM7x30 chipset platform consists of the MSM7230™ and MSM7630™.


Scorpion 800 MHz CPU
Integrated 3G mobile broadband connectivity
MSM7230 support for HSPA+ networks - up to 14 Mbps downloads and 5.76 Mbps uploads
MSM7630 support for HSPA+ networks - up to 14.4 Mbps downloads and 15.761 Mbps uploads – as well as CDMA2000 1X, 1xEV-DO Rel A/B, GSM, GPRS and EDGE
Low-power 45nm process technology for higher integration and performance
High-definition (720p) video recording and playback up to 30 frames per second
Multiple video codecs: (MPEG-4, H.264, H.263, VC-1, DivX, DivX 3.11, Sorenson Spark, VP6)
High-performance GPU - up to 41M triangles/sec and 245M 3D pixels/sec and dedicated 3D/2D acceleration engines for Open GLES 2.0 and Open VG 1.1 acceleration
High-resolution XGA (1024x768) display support
12-megapixel camera support
Built-in eighth-generation gps engine with Standalone-GPS and Assisted-GPS modes
Support for Wi-Fi® and Bluetooth® connectivity
Multiple audio codecs: (AAC+, eAAC+, AMR, FR, EFR, HR, WB-AMR, G.729a, G.711, AAC stereo encode)
Support for mobile broadcast TV (MediaFLO™, DVB-H and ISDB-T)
Support for Android™, Brew® Mobile Platform and Windows® Phone

And it seems that there are already preliminary benchmark results from HTC desire HD on glbenchmark. According to them adreno 205 on msm8255 yields only to sgx540 on galaxy S.
Hopefully msm8x55 will replace qsd8x50 on all future devices. Higher graphics performance, probably better multimedia performance(hopefully as good as on samsung hummingbird) and improved power performance(hopefully not only due to 45nm).

[Ailuros]

It seeems that qualcomm has finally updated their webpage with specifications of msm7x30, msm8x55, msm8x60 and qsd8672.

And it seems that there are already preliminary benchmark results from HTC desire HD on glbenchmark. According to them adreno 205 on msm8255 yields only to sgx540 on galaxy S.
Hopefully msm8x55 will replace qsd8x50 on all future devices. Higher graphics performance, probably better multimedia performance(hopefully as good as on samsung hummingbird) and improved power performance(hopefully not only due to 45nm).

The HTC Vision (also Adreno205) scores slightly better than the desire. Considering it's the same 800*480 resolution as the Galaxy S smart-phones, it's at 1424 frames vs. highest Galaxy S being now at 1918 frames. Albeit I'd expect for both sides performance to slightly scale due to sw optimisations, I wouldn't suggest that that gap might close. So judging from one public synthetic benchmark it's in reality somewhere in between a SGX535 and a 540, under the presupposition that the 535 isn't clocked higher than 250MHz.

[Wishmaster]

The HTC Vision (also Adreno205) scores slightly better than the desire. Considering it's the same 800*480 resolution as the Galaxy S smart-phones, it's at 1424 frames vs. highest Galaxy S being now at 1918 frames. Albeit I'd expect for both sides performance to slightly scale due to sw optimisations, I wouldn't suggest that that gap might close. So judging from one public synthetic benchmark it's in reality somewhere in between a SGX535 and a 540, under the presupposition that the 535 isn't clocked higher than 250MHz.

This could be either due to running sense UI or simple software difference, irrelevant.
What is for sure that adreno 205 may not be the best GPU available for smartphones, but this benchmark proves that msm8255 gets twice as high scores as qsd8250 running the same OS, and is slightly faster than iphone 4, ipad and iphone 3GS.
Not bad I would say. Hopefully adreno 220 will be as good as the specs say.

[Ailuros]

This could be either due to running sense UI or simple software difference, irrelevant.
What is for sure that adreno 205 may not be the best GPU available for smartphones, but this benchmark proves that msm8255 gets twice as high scores as qsd8250 running the same OS, and is slightly faster than iphone 4, ipad and iphone 3GS.
Not bad I would say. Hopefully adreno 220 will be as good as the specs say.

It doesn't prove that much either since it's still one singled out synthetic benchmark. Since there are quite a few real time videos on the internet illustrating gaming performance in real time and considering how the original Adreno did in those, I'm looking forward to see if 205 or future iterations respectively can get those out of the endless stutter-fest they're currently in. And we're not even talking about demanding applications but something as antique and boring as Quake2.

A wee bit more advanced would be Kwaak3: http://www.anandtech.com/show/3891/samsung-epic-4g-review-the-fastest-android-phone/5

A single TMU 530 is twice as fast as Adreno Prime.

[Arun]

So even the MSM8x60 uses the 14.4Mbps baseband? Quite interesting - so that's how they boosted their specs while maintaining a reasonable die size. I guess 2011 really will be the year of 14.4 for phones - even the ST-Ericsson U8500 (baseband designed by Nokia) is 14.4! I also wonder whether that 3D core is 2 TMU at 266MHz or 4 TMU at 133MHz. I'd rather bet on the former but who knows.

[Laurent06]

What do they call "Scorpion asynchronous dual-CPU cores"?

[Arun]

What do they call "Scorpion asynchronous dual-CPU cores"?Probably that the two cores can be clocked independently (and in the QDD8672's case at least but maybe also the other, have independent voltages, which is very cool although a bit expensive).

[Wishmaster]

Probably that the two cores can be clocked independently (and in the QDD8672's case at least but maybe also the other, have independent voltages, which is very cool although a bit expensive).

Wasn't that about independent and dynamic core scaling?
When needed both are running at full speed, when on standby clocked very low and when needed only for low priority task one is turned of and second is running at adequate speed?

[Ailuros]

Why do I have the feeling that you're both saying the same thing? :razz:

[Wishmaster]

Why do I have the feeling that you're both saying the same thing? :razz:

If so, it means I have to educate more and stop making fool of myself :razz:

[Ailuros]

If so, it means I have to educate more and stop making fool of myself :razz:

I'm hardly fit to educate anyone when it comes to technical matters. I just couldn't help it. If you re-read both yours and Arun's post it's not to hard to see that you both mean the same thing.

[Wishmaster]

I'm hardly fit to educate anyone when it comes to technical matters. I just couldn't help it. If you re-read both yours and Arun's post it's not to hard to see that you both mean the same thing.

You're right. I responded too fast without thinking it through :???:
But getting back to the topic.
I hope they improved the drivers for adreno 205, compared to not perfect amd z430 drivers. They finally changed amd branding to adreno so hopefully it means that they really improved it not only by doubling the clock or TMU but by software optimizations.

[Arun]

Wasn't that about independent and dynamic core scaling?
When needed both are running at full speed, when on standby clocked very low and when needed only for low priority task one is turned of and second is running at adequate speed?It's practically the same thing, but to be honest I was nitpicking and assumed nobody would notice... :)

The way this stuff works (afaik) is that the individual chips are tested/qualified at various sets of frequencies and voltages. There's no way to know *exactly* what voltage is required at an arbitrary frequency.

So you know (to pick random numbers) that you can run the CPU at 800MHz at 1.0v and 550MHz at 0.9v. But you have no way to reliably know whether you could run at 700MHZ at 0.97v for example - you're forced to run it at 1.0v anyway. So it is conceivable *in theory* in a dual-core system that both cores share the same 1.0v voltage (whether they have independent regulators or not) but are clocked at slightly different frequencies.

In practice, I don't know if they bother doing that kind of thing. Power gating has become so aggressive on these chips it might be better to always run at the maximum frequency for the rated voltage and power gate a bit more frequently. In fact it would probably be preferable in terms of power consumption unless you're limited by the voltage floor of the process (i.e. minimum voltage the chip can run at without problems). You might be able to clock at 150MHz at that voltage but only need the CPU for basic bookkeeping at 25MHz for a small number of cycles - there's still a latency for power gating so you might actually save power by doing that.

However there's absolutely no point in running two cores below their rated frequency at the voltage floor - that's downright absurd. So it's very possible (and in fact rather likely) that my nitpicking only made theoretical sense - in the real world, there's probably very little and possibly no difference.

Aren't you happy having read all this text just to know that? ;)

[Laurent06]

This raises the question of whether there's any L1D coherency between the cores (which was more what I was wondering).

[Wishmaster]

Aren't you happy having read all this text just to know that? ;)

You just made my day :D

[metafor]

However there's absolutely no point in running two cores below their rated frequency at the voltage floor - that's downright absurd.

Sure there is. The voltage floor may be 0.75V but if you can still run at, say 400MHz, you'd save a significant amount of power running at 100MHz. Power gating isn't trivial. States have to be saved off or the sub-block has to be treated like it's a cold boot. And even then you have to wait for the pipeline to finish its last instruction before powering off.

If the occasional instruction will come along but not require much speed, or a thread is running that does not require much performance at all, running at 100MHz is very advantageous vs 400MHz even at the same voltage.

[Arun]

Sure there is. The voltage floor may be 0.75V but if you can still run at, say 400MHz, you'd save a significant amount of power running at 100MHz. Power gating isn't trivial. States have to be saved off or the sub-block has to be treated like it's a cold boot. And even then you have to wait for the pipeline to finish its last instruction before powering off.

If the occasional instruction will come along but not require much speed, or a thread is running that does not require much performance at all, running at 100MHz is very advantageous vs 400MHz even at the same voltage.Gah, I knew I should have phrased that part better. Needless to say, I agree completely (although I'd be expect the voltage floor frequency to be slightly lower than 400MHz even on a 1.5GHz chip, but I don't really know so let's assume so - I'd be very curious about more reliable ballpark numbers).

What I meant is that if your speed at the voltage floor is 400MHz and you've got a dual-threaded workload that only requires two cores running at 100MHz, it makes no sense to use both cores: it's more efficient to use a single core at ~200MHz to reduce leakage. However it does make very good sense to run one core at exactly 400MHz and the other at <400MHz to save some power, so that's a common case where separate clocking is beneficial even with the same voltage regulator. But on the other hand I wouldn't be very impressed by a handheld SMP implementation that ever activates the second core before the first core is maxed out at its voltage floor.

[metafor]

Gah, I knew I should have phrased that part better. Needless to say, I agree completely (although I'd be expect the voltage floor frequency to be slightly lower than 400MHz even on a 1.5GHz chip, but I don't really know so let's assume so - I'd be very curious about more reliable ballpark numbers).

For a 1.5GHz chip, it's about realistic at 45LP. Assuming 1.5 was your peak at say ~1.0V. It varies wildly of course when moving from 65LP or to 28LP. I was just throwing out a number :)

What I meant is that if your speed at the voltage floor is 400MHz and you've got a dual-threaded workload that only requires two cores running at 100MHz, it makes no sense to use both cores: it's more efficient to use a single core at ~200MHz to reduce leakage. However it does make very good sense to run one core at exactly 400MHz and the other at <400MHz to save some power, so that's a common case where separate clocking is beneficial even with the same voltage regulator. But on the other hand I wouldn't be very impressed by a handheld SMP implementation that ever activates the second core before the first core is maxed out at its voltage floor.

I agree. I'm not sure how current handheld OS's handle this. I would suspect that if there are 2 threads, they'd blindly schedule it for 2 cores. But I don't think the typical smartphone or even tablet workload involves a lot of light, sustained processes. It's usually burst work like rendering a webpage as fast as possible or responding to a GUI action.

I don't think any dual-core implementation out there requires the two cores to always run at the same speed (modern dual-core implementation anyway).