Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

MacSince1990

macrumors 65816
Oct 6, 2009
1,347
0
Coprocessors are a time honored way to off-load work, and they were an obvious addition to smartphones.

Yea, but we've been moving away from separate ICs for a very long time (L2 cache used to be its own thing, separate from the entire CPU card--- hell, FPUs were totally separate!), and now we're even moving away from discrete GPUs.

Coprocessors these days just strike me as a bit odd.
 

kdarling

macrumors P6
Coprocessors these days just strike me as a bit odd.

That's a good point.

I suspect it's a lot easier for many designers right now to simply use off the shelf, very low power, relatively slow (~100MHz) microcontrollers as standalone sensor hubs.

Eventually, as you suggest, these low power logic sections will be integrated into the main application processor case, to save space and gain other capabilities.

For example, Qualcomm already does this in their Snapdragon processors used by HTC, Nokia, and others. They have an integrated internal DSP that's used to process motion events while the main CPUs sleep. This allows their motion processor to use shared RAM / storage as well.
 

chrmjenkins

macrumors 603
Oct 29, 2007
5,325
158
MD
That's a good point.

I suspect it's a lot easier for many designers right now to simply use off the shelf, very low power, relatively slow (~100MHz) microcontrollers as standalone sensor hubs.

Eventually, as you suggest, these low power logic sections will be integrated into the main application processor case, to save space and gain other capabilities.

For example, Qualcomm already does this in their Snapdragon processors used by HTC, Nokia, and others. They have an integrated internal DSP that's used to process motion events while the main CPUs sleep. This allows their motion processor to use shared RAM / storage as well.

I suspect this is actually happening with the A8. The overall pinout has been decreased, so I expect some functions/IP have been integrated on the die/package that weren't there before.
 
Last edited:

cmaier

Suspended
Jul 25, 2007
25,405
33,471
California
I suspect this is actually happening with the A8. The overall pinout has been decreased, so I expect some functions/IP have been integrated on the die/package that weren't there before.

One reason it gets tricky to integrate some of this stuff is that you need different clock domains for different portions of the chip. It's easier to do with separate chips, so typically you first integrate things that benefit most from direct high speed bus access (which the M7 does not). Of course, integration will continue, since the problems aren't insurmountable, but it's probably the main design challenge (whereas yield is the main implementation challenge).
 

chrmjenkins

macrumors 603
Oct 29, 2007
5,325
158
MD
One reason it gets tricky to integrate some of this stuff is that you need different clock domains for different portions of the chip. It's easier to do with separate chips, so typically you first integrate things that benefit most from direct high speed bus access (which the M7 does not). Of course, integration will continue, since the problems aren't insurmountable, but it's probably the main design challenge (whereas yield is the main implementation challenge).

Yes, good points. One reason behind my assumption is that the transistor growth of their CPU cores seems likely to slow down after quite the explosion of design iteration over the past 4 years. I imagine they'll want to start spending them elsewhere. I also believe they're adding a second NAND chip to that bus, so I am guessing that there are perhaps some alterations going on with that bus, too.
 

MacSince1990

macrumors 65816
Oct 6, 2009
1,347
0
That's a good point.

I suspect it's a lot easier for many designers right now to simply use off the shelf, very low power, relatively slow (~100MHz) microcontrollers as standalone sensor hubs.

Well, if what you said about it working even when the iPhone is OFF (I mean, I believe you), then it makes sense. Obviously CPUs support low-power states, but AFAIK (which means little, I guess, as I'm not an engineer much less a chip engineer) they don't support modular sleep... in the sense that a one part of the die can't be turned on while the rest is off (e.g. the M7, were it integrated into the CPU die/package).

Sheesh. Remember when all a CPU was, was an ALU, MMU, FPU, cache and a few registers? What the hell happened :confused: Lol can you imagine? We could cut the # of transistors in (desktop/laptops) by like 75%. And I imagine achieve higher clockspeeds while maintaining the same TDP? Again though what do I know. Not an engineer.


Eventually, as you suggest, these low power logic sections will be integrated into the main application processor case, to save space and gain other capabilities.

I still say it's utterly bizarre that we have integrated graphics chips as part of the CPU.
 

cmaier

Suspended
Jul 25, 2007
25,405
33,471
California
No, portions of CPU's can be selectively powered.

Also, higher clock speeds is a bad way to achieve performance, per watt. Increasing clock speed linearly increases power consumption. Moreover, achieving higher clock speed requires (in most cases) higher voltage, and power increases as the square of the voltage.

Well, if what you said about it working even when the iPhone is OFF (I mean, I believe you), then it makes sense. Obviously CPUs support low-power states, but AFAIK (which means little, I guess, as I'm not an engineer much less a chip engineer) they don't support modular sleep... in
the sense that a one part of the die can't be turned on while the rest is off (e.g. the M7, were it integrated into the CPU die/package).

Sheesh. Remember when all a CPU was, was an ALU, MMU, FPU, cache and a few registers? What the hell happened :confused: Lol can you imagine? We could cut the # of transistors in (desktop/laptops) by like 75%. And I imagine achieve higher clockspeeds while maintaining the same TDP? Again though what do I know. Not an engineer.




I still say it's utterly bizarre that we have integrated graphics chips as part of the CPU.
 
Last edited:

MacSince1990

macrumors 65816
Oct 6, 2009
1,347
0
Also, higher clock speeds is a bad way to achieve performance, per watt.

Not really, given the fact that it costs nothing to clock a part higher, whereas it costs something to add more silicon.

Increasing clock speed linearly increases power consumption.

Actually, increasing clock speed tends to exponentially increase power consumption, as higher clocks require higher voltages.


Moreover, achieving higher clock speed requires (in most cases) higher voltage, and power increases as the square of the voltage.

Erm.............. well yeah <_<

What's your point? There's still no cost increase in OC'ing.
 
Last edited:

cmaier

Suspended
Jul 25, 2007
25,405
33,471
California
Not really, given the fact that it costs nothing to clock a part higher, whereas it costs something to add more silicon.

Increasing clock speed linearly increases power consumption.
Actually, increasing clock speed tends to exponentially increase power consumption, as higher clocks require higher voltages.




Erm.............. well yeah <_<

What's your point? There's still no cost increase in OC'ing.

I don't think exponentially means what you think it means. Formula is P=(V^2)f. And one doesn't need to exponentially increase voltage to increase frequency.

Anyway...

My point was exactly what I said. Increasing clock speed is a bad way of increasing performance per watt. You seem to have ignored the part where i said "PER WATT." I didn't say "per dollar." (though I'll address that in a moment).

Moreover, you use the term "OC" (which I assume means overclocking) but overclocking has nothing to do with this. The term overclocking is used to refer to running a CPU at a higher frequency than intended by the manufacturer. What I was talking about (and what the conversation was about) was DESIGNING a chip and making a tradeoff - does one get better results by using more transistors to increase instructions-per-cycle, or by stripping out all those transistors to achieve a higher clock frequency and achieving higher cycles-per-wall clock.

The tradeoff is based on the idea that performance = instructions-per-clock x clocks-per-second. Each factor can be traded off against the other.

Now, as for your "cheaper" argument, not necessarily. True that cost depends on die area, and more transistors means larger die area. But it is also true that cost depends on number of masks, and more frequency typically means more mask steps (to decrease point-to-point metal routes, provide power and ground distribution, provide anti-coupling planes, reduce inductance loops, increase bypass capacitance, etc.) Also, higher frequency means discarding more chips at the bottom of the schmoo plot (i.e. there is a distribution of frequencies across each wafer and across different wafers. Slower chips wouldn't have the required frequency and would be discarded.) It could very well be better to make bigger chips and keep more of them than to make smaller chips and have to throw them away for poor frequencies (depends on yield curves as well). Alternatively, faster frequencies may require a better process node to make up for loss of IPC-increasing transistors (depending on what extremes one goes to).
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.