Integration - when does it *stop* making sense?

[Arun]

Everyone keeps talking about when integration starts making sense in different markets and when discrete components will die. I thought that as an opening post to this forum, I'd try to be slightly controversial and ask the exact opposite: when (and where) does integration stop making sense? And how do you figure out what's the best overall system architecture?

The disparity in costs between cutting-edge processes and their ancestors as well as analogue/RF-only processes is growing every day, and it is getting more and more challenging to get good analogue/RF performance from them. This and simplicity in general has prompted a few companies to favor System in Package approaches, and I ponder whether that might not start making a lot more sense than SoC at 40nm and beyond.

With pure-logic integration, the economics are obviously a bit more favorable. There still are catches though obviously:
- R&D design times synchronisation & extra delay/respin risks
- Slightly lower yields for highly heterogenous SoCs: if one part is broken, everything goes to the trash.
- Current industry cycles for different components are different for a variety of sometimes pretty good reasons (baseband certification, computer models being tied to their motherboard -> partial notebook refreshes, etc.)
- Process variants may make integration of different kind of logic components less attractive. CPUs are a classic example, but it's not just that - you could conceive that some integration strategies may hurt idle power, for example.

So given all this - is SoC integration overhyped in some areas, or is it not? And is SiP even a viable alternative in some instances? Am I overestimating some of these problems, or are these legitimate concerns?

 

[Geo]

It seems to me that the integrated parts better have roughly the same life cycle. This is part of why I've always been leery of integrating graphics into cpu. I don't think graphics have matured enough to support the longer life-cycle times of cpus. Particularly if you aspire, as apparently Intel and AMD do, to moving integration further up the food chain than has traditionally been the case.

 

[ShaidarHaran]

If you look at GPU integration onto CPU packages/dies as more of a co-processor than the only source of graphics processing, I think it makes a whole lot more sense from a long-term perspective.

 

[_xxx_]

The ultimate goal of all the development long-term is a single-chip computer. Whenever we should reach it. Short-term, it will be whatever's feasible of course but that doesn't change the ultimate goal.

 

[Arun]

Single-chip computers, as per the traditional definition, are really only single-chip in terms of digital logic. You've still got an external audio analogue chip, an ethernet PHY, a WiFi MAC/PHY if you need that, etc... You could be more aggressive though and integrate the audio (it's definitely doable, but doing it right so the quality remains good enough might be 'fun') and ethernet PHY (also doable, see Broadcom chipsets, but does it make economic sense?). But that's definitely not what most companies seem to be thinking of when you say 'single-chip'.

As for the GPU being a coprocessor to the CPU, I guess that depends on whether you think CPUs are 'worth' making many-core. If they aren't and it's a better idea to have a few highly serial-optimized cores, plus many throughput-optimized MIMD cores, plus many latency-optimized SIMD cores, then what happens? The bandwidth requirements between the serial and the other cores becomes much less significant and integrating the two outside the very-low-end is a very bad idea due to the characteristics of the different processes.

I'm not saying the above is perfectly true, just pointing out that's part of what I meant and perhaps my initial post wasn't clear enough...

 

[ShaidarHaran]

As for the GPU being a coprocessor to the CPU, I guess that depends on whether you think CPUs are 'worth' making many-core. If they aren't and it's a better idea to have a few highly serial-optimized cores, plus many throughput-optimized MIMD cores, plus many latency-optimized SIMD cores, then what happens? The bandwidth requirements between the serial and the other cores becomes much less significant and integrating the two outside the very-low-end is a very bad idea due to the characteristics of the different processes.

AMD's vision of many-core includes GPU co-processors, and other fixed-function cores. At least according to slides from their roadmaps.

 

[Silent_Buddha]

Well at first glance it would appear both AMD and Intel are moving towards more modular CPU designs with multiple cores of not only CPU's but GPU's. Or possibly multiple course of hybrid CPU/GPU's?

The aim, at least so far isn't to target performance or enthusiants directly with such offerings, however it does appear to signal...

1. Both parties are intent on moving integrated graphics from the MB to the CPU "package."

2. The greatest penetration and the market where it makes the most sense is in OEM systems. Especially systems sold in bulk to large corporations where graphics requirements are low and most importantly graphics are rarely if ever upgraded seperately from the CPU and MB. Often the only thing upgraded over time is the amount of memory.

3. Indirectly targetting the enthusiast (the latest chipsets from AMD/ATI point in this direction). With the integrated GPU taking over graphics rendering when at the desktop and turning off higher power draw add in boards.

So, I guess the answer to the original question is that integration breaks apart/doesn't make sense when you get to the performance/enthusiast markets.

However, this combined with the move to integrated cores on the CPU packages lead us to an interesting thought.

...If both AMD and Intel move fully in this direction where all CPUs included a GPU core...

We would see the return of dedicated 3D only enthusiast class rendering boards.

If all computers already come with a capable 2D/3D (for Aero) graphics rendering unit then there's no reason to waste transistors on an add in board for basic 2D/legacy 3D. Even if it's a tiny percentage of the chip as a whole.

Which leads to more power efficient enthusiast class boards as the entire add in board can be powered down when not running a demanding 3D application (game for example).

It already appears AMD is moving in this direction. Although currently only with their low end add-in cards combined with the latest integrated chipset. I wouldn't be surprised to see them move to something similar with their high end cards, where the card can be disabled entirely when paired up with an AMD chipset with integrated video.

To be really effective I would imagine this would require OS support also in the long term.

Regards,
SB

 

[Davros]

"As for the GPU being a coprocessor to the CPU,"

i think thats a great idea a bit like the 286 + the 287 co-processor

 

[Acert93]

Integration ceases to make sense when a single chip cannot reach the performance metrics the consumer demands while multiple chips do (within budget boundaries of course).

There comes a point when specialized hardware, while faster, makes less sense because the integrated solution is "good enough". In relation to GPUs and realtime 3D rendering, in the gaming arena there is a large gap between what CPUs currently offer and what GPUs do that is a couple orders of magnitude above diminishing returns. As diminishing returns in visuals becomes more of an issue and CPUs begin to close the gap this may change, but right now integration doesn't make sense for a number of markets because the products won't meet consumer demands.

 

[Frank]

Simply put: integration stops making sense when you try to cram as much specialized stuff on a die as it will hold, and it makes more sense when you instead add more general purpose ALUs and cores to replace the specialized stuff.

I remember a discussion I had with SirEric about three years ago on this forum: I said, that the future of GPUs wasn't in adding more specialized pipelines like vector units, but instead would be to reduce those to simple scalar ALUs. While he said, that extracting more parallelism from the specialized units was the goal.


Look at any kind of simple electronics around you: ten years ago they would all be custom build, nowadays they all use only a microcontroller.

Which makes sense: programs are much more flexible than fixed function hardware, and that general hardware can be produced in vast amounts.

 

[Silent_Buddha]

Simply put: integration stops making sense when you try to cram as much specialized stuff on a die as it will hold, and it makes more sense when you instead add more general purpose ALUs and cores to replace the specialized stuff.

Isn't that just integration by another method? It's still integrating all those functions into one chip. Although rather than being a chip with many dedicated circuits it's a general purpose programmable chip that can handle all those duties.

So in your example, Integration never stops making sense and makes more and more sense as process technology increases.

I'd still argue that in any sectore where performance is still a concern, then integration doesn't make sense.

For example it makes lots of sense to integrate say a 10/100 ethernet controller into a MB chipset and possibly even onto a general purpose CPU. However if you need the performance of a 10 gbit controller, suddently that doesn't make a whole lot of sense.

Likewise with graphics. As long as you only need basic functionality then integration makes a whole lot of sense. But when you get to areas where performance can sometimes struggle to meet the needs of evolving software, then integration doesn't make any sense.

Just a couple examples of areas that I don't see any sort of integration making sense at least for a few more years. It'll certainly be interesting to revisit the subject 5 years from now.

Regards,
SB

 

[Frank]

I mean, it makes sense to integrate more general purpose units, that can be programmed to do the work of the fixed function hardware it replaces.

In your example, if you run out of bandwidth: just increase the amount of ALUs.

 

[RussSchultz]

Coming from a company that 'excells' in integration, its almost always a question of cost, particularly in the "low end" (i.e. parts that cost in the few dollar range).

First off, when you integrate functions into the main chip, you can avoid having interconnects. This boosts performance and power. It also reduces cost because you only have 1 package, and no pins dedicated to the interconnect (meaning a smaller, cheaper package).

You can get nearly the same benefit from doing multi chip packaging (SIP or MCM), but the cost is considerably higher. Also, there's a problem with yield loss unless you can get full test coverage on the bare die (and then there's still some packaging fallout)

Separate packages are more expensive, take more PCB space (sometimes not an issue), use more power, etc.

On the other hand, many times discrete components are generally faster to market. Usually the first end product of its class from a consumer electronics company will be completely discrete, and then each iteration drives more cost out of the equation by integrating functions into it.

For the manufacturer of the integrated product, there's also the benefit of capturing more of the silicon revenue for the end product, and giving less of it to partners/competitors/suppliers.

Oh, and who says you can't get analog and digital on the same chip? All of our SoCs have top notch DACs, ADCs, PHYs and power converters on them. Of course, at some point, it'll supposedly stop making sense to have mixed signal parts. The analog doesn't shrink with the geometry like digital does, but the cost per area goes up so the analog cost gets progressively larger as a percentage of the entire die. Of course, we haven't seen the point when it makes sense for us to change, since we've got a very optimized analog subsection.

edit: oh yeah, and everybody and their dog is integrating a 3d processor into their SoCs, including the SGX series and/or the new NVIDIA ADX2500 (which is the equivalent of an GF6200). It makes sense because gates are getting cheaper and cheaper, and you need something to fill up the white space made by the huge pad rings.

 

[Arun]

Coming from a company that 'excells' in integration, its almost always a question of cost, particularly in the "low end" (i.e. parts that cost in the few dollar range).

Absolutely, when your ASP is only a few dollars you can't try to save time or reduce risk by delivering a lower level of integration: the cost of a package is proportionally even higher there, and if all your competitors are integration-heavy and you aren't, it could completely kill your margins to be price-competitive.

First off, when you integrate functions into the main chip, you can avoid having interconnects. This boosts performance and power. It also reduces cost because you only have 1 package, and no pins dedicated to the interconnect (meaning a smaller, cheaper package).

That makes sense, and obviously that trend is very visible in the world of digital logic. I'm curious though, is that advantage not absolutely insignificant in terms of application processor/baseband integration? The bandwidth between the two at standby should be ~zero and even at peak, it should be fairly negligible.

Oh, BTW - since I suppose you're probably well positioned to know this... Does putting the audio analogue stuff on-chip save a non-negligible amount of power compared to an off-package chip? And any idea how that would compare to an on-package turnkey approach?

You can get nearly the same benefit from doing multi chip packaging (SIP or MCM), but the cost is considerably higher. Also, there's a problem with yield loss unless you can get full test coverage on the bare die (and then there's still some packaging fallout)
[...]
The analog doesn't shrink with the geometry like digital does, but the cost per area goes up so the analog cost gets progressively larger as a percentage of the entire die. Of course, we haven't seen the point when it makes sense for us to change, since we've got a very optimized analog subsection.

Okay so that's really my point: when does this equation become true, where Risk Delta is the amortized per-die cost of the extra risk and R&D investment of porting analogue to a new process compared to using a SiP/turnkey approach?
[Analogue mm² * x-nm Wafer Cost] - [Analogue mm² * 180-nm Wafer Cost] > SiP Cost - Risk Delta

Also, it's worth pointing out that I'm just saying 'x-nm wafer cost', but things get even more interesting if your foundry proposes both a plain process and one with high-k/metal gates (or SOI). The latter would give you a small power/performance advantage, so for digital logic it might be worth the cost. But it'll also increase the cost of your on-chip analogue with no real benefit to it, making a SiP slightly more attractive. It seems to me that such a situation will happen at TSMC on 32nm, fwiw.

Another thing to take into consideration in the Risk Delta would be the 'time to process' disadvantage of on-chip analogue/RF. While it might be realistic to port an existing design to a new process node and get the new chip to tape-out within just a few short weeks of the process going 'live', you can't do that if you want to integrate plenty of non-digital stuff. In the mobile phone market where die sizes are small and design-in cycles long, being on a process ASAP tends to be an advantage.

For the manufacturer of the integrated product, there's also the benefit of capturing more of the silicon revenue for the end product, and giving less of it to partners/competitors/suppliers.

Definitely. You get the same advantage by selling a SiP or off-package turnkey like TI does, though - but I get your point. It doesn't help marketshare or margins, but it does help revenue and gross profit.

Oh, and who says you can't get analog and digital on the same chip? All of our SoCs have top notch DACs, ADCs, PHYs and power converters on them. Of course, at some point, it'll supposedly stop making sense to have mixed signal parts.

Yeah, what I've seen from Sigmatel (well, Freescale, but you get the point) is nice on that front. It's worth pointing out you guys are hardly at the front of the process race, though! And I'd challenge anyone to tell me that they could be at the front of it even with on-chip power management... Whether that matters is a factor of your strategy and target market, but it certainly should be taken into consideration.

oh yeah, and everybody and their dog is integrating a 3d processor into their SoCs, including the SGX series and/or the new NVIDIA ADX2500 (which is the equivalent of an GF6200).

Are you implying NVIDIA is trying to license the 2500's GPU? If so, I guess I'm suddenly happy I didn't have the time to talk about the 3D core and the business aspects of the 2500 with Mike Rayfield yesterday!

It makes sense because gates are getting cheaper and cheaper, and you need something to fill up the white space made by the huge pad rings.

Indeed. Basic OpenGL ES 2.0 3D is going to become pretty much a necessity in the market anyway, as 3D GUIs start to take off. I'm much more skeptical about the potential for 3D GPUs to keep scaling in performance as in the PC world though, because I'm not sure 3D mobile phone gaming is ever going to take off at this rate. Unless someone like Apple decided to get serious about it, I guess...

 

[RussSchultz]

That makes sense, and obviously that trend is very visible in the world of digital logic. I'm curious though, is that advantage not absolutely insignificant in terms of application processor/baseband integration? The bandwidth between the two at standby should be ~zero and even at peak, it should be fairly negligible.

My personal opinion is that because of the natural partiitoning of the cellphone handset problem, you'll see:

• Fully integrated baseband (baseband + RF)
• Mixed signal applications processor (USB PHY, at least)
• Mixed signal power, dac/codec chip

Oh, BTW - since I suppose you're probably well positioned to know this... Does putting the audio analogue stuff on-chip save a non-negligible amount of power compared to an off-package chip? And any idea how that would compare to an on-package turnkey approach?

Our power savings come from being able to separate the analog power rail from the digital power rail, which is made easier by having the DAC/ADC in the same mixed signal chip. It really helps the cost and formfactor, also.

Okay so that's really my point: when does this equation become true, where Risk Delta is the amortized per-die cost of the extra risk and R&D investment of porting analogue to a new process compared to using a SiP/turnkey approach?
[Analogue mm² * x-nm Wafer Cost] - [Analogue mm² * 180-nm Wafer Cost] > SiP Cost - Risk Delta

For what its worth, the analog has never been the 'risk' part of our proposition. I think its going to be time to market that will make mixed signal always be the follow on, cost reducing product. People have been saying "oh, its too expensive/hard/poor performing to port the analog to the smaller process" since about .25u. It hasn't stopped us from showing them wrong.

Also, it's worth pointing out that I'm just saying 'x-nm wafer cost', but things get even more interesting if your foundry proposes both a plain process and one with high-k/metal gates (or SOI). The latter would give you a small power/performance advantage, so for digital logic it might be worth the cost. But it'll also increase the cost of your on-chip analogue with no real benefit to it, making a SiP slightly more attractive. It seems to me that such a situation will happen at TSMC on 32nm, fwiw.

FWIW, power is much less of an issue in anything with a display (like a GPS or video player, or even a phone). The backlight power pretty much dwarfs the normal power draw of the processor (unless you're trying to do video playback with the CPU)

Another thing to take into consideration in the Risk Delta would be the 'time to process' disadvantage of on-chip analogue/RF. While it might be realistic to port an existing design to a new process node and get the new chip to tape-out within just a few short weeks of the process going 'live', you can't do that if you want to integrate plenty of non-digital stuff. In the mobile phone market where die sizes are small and design-in cycles long, being on a process ASAP tends to be an advantage.

I think you overestimate companies' ability to get into a new process and underestimate the time scales involved.

I also don't agree with the 'small die sizes mean get into the advanced process ASAP'. I think its just the opposite. You should use the right process for the product. There's no reason to port an 8051 micro to 65nm, because you're going to end up pad limited (probably), and have a high wafer cost. You'd be better off going with a less advanced process so that pad/die area was balanced and you got 100% utilization.

Definitely. You get the same advantage by selling a SiP or off-package turnkey like TI does, though - but I get your point. It doesn't help marketshare or margins, but it does help revenue and gross profit.

Only helps revenue. If you can sell the solution for $4, and doing it in a SiP costs 50c more than integrating it, you lose that 50c in profit. If you integrated it, you could keep your margins 'the same', reduce your cost by $1, and likely increase your marketshare.

Yeah, what I've seen from Sigmatel (well, Freescale, but you get the point) is nice on that front. It's worth pointing out you guys are hardly at the front of the process race, though!

You're right. We're not too far off though, when you talk about TSMCs mainstream processes.

Are you implying NVIDIA is trying to license the 2500's GPU?

No, I meant that the 2500 is an applications processor with an integrated 3d block.

Indeed. Basic OpenGL ES 2.0 3D is going to become pretty much a necessity in the market anyway, as 3D GUIs start to take off. I'm much more skeptical about the potential for 3D GPUs to keep scaling in performance as in the PC world though, because I'm not sure 3D mobile phone gaming is ever going to take off at this rate. Unless someone like Apple decided to get serious about it, I guess...

I think android is going to make a big difference, along with either JAVA or some virtual machine for gaming like Flash.

 

[Arun]

My personal opinion is that because of the natural partiitoning of the cellphone handset problem, you'll see:

• Fully integrated baseband (baseband + RF)
• Mixed signal applications processor (USB PHY, at least)
• Mixed signal power, dac/codec chip

I agree that's a good architecture and probably makes the most sense for much of the market. Sadly, I think the couple of companies that have the IP and expertise necessary for a fully integrated baseband figure they might as well as also integrate the application processor to capture more of the system's revenue.

Case in point: NVIDIA's development platform and reference design includes an Infineon baseband - and shock, horror, that baseband includes an application processor and fixed-function multimedia blocks (and RF is discrete). The only serious companies which seem willing to have a long-term baseband roadmap that doesn't integrate an application processor are Icera and Qualcomm, as far as I can tell. The first doesn't have the IP to integrate RF, and the latter doesn't have the will to do so in these products I suspect.

For what its worth, the analog has never been the 'risk' part of our proposition. I think its going to be time to market that will make mixed signal always be the follow on, cost reducing product. People have been saying "oh, its too expensive/hard/poor performing to port the analog to the smaller process" since about .25u. It hasn't stopped us from showing them wrong.

Fair enough. My 'risk delta' was mostly related to respins (which are more likely with analogue) and, even though that's not risk, extra R&D expenses though. I also agree that analogue performance is probably not too much of a problem for at least a few more years; I'm honestly more interested in the cost aspects here.

FWIW, power is much less of an issue in anything with a display (like a GPS or video player, or even a phone). The backlight power pretty much dwarfs the normal power draw of the processor (unless you're trying to do video playback with the CPU)

Yeah, that's reasonable. That problem *might* become less severe in the future though, with advances going from LED backlighting to stuff like this. And at higher resolutions (especially >=720p), the semiconductors start taking a bigger share of the power pie.

I think you overestimate companies' ability to get into a new process and underestimate the time scales involved.

I'm not, I was just being a bit too vague by what I meant with the process going 'live'. What I meant by that is, for example, September 2007 for TSMC's 45nm low-power process. That's what they call risk production. There already are plenty of tests by large customers before that date and final chips can sometimes tape-out before the process enters risk production.

I also don't agree with the 'small die sizes mean get into the advanced process ASAP'. I think its just the opposite. You should use the right process for the product. There's no reason to port an 8051 micro to 65nm, because you're going to end up pad limited (probably), and have a high wafer cost. You'd be better off going with a less advanced process so that pad/die area was balanced and you got 100% utilization.

Sure, it depends on the kind of handheld chip. In your above example of an application processor that doesn't integrate more than just an USB PHY and uses a SiP or external chip for the rest of the analogue stuff, I don't think you'll be pad-limited unless it's really low-end and doesn't integrate anything interesting...

Only helps revenue. If you can sell the solution for $4, and doing it in a SiP costs 50c more than integrating it, you lose that 50c in profit. If you integrated it, you could keep your margins 'the same', reduce your cost by $1, and likely increase your marketshare.

Okay, we're not looking at it the same way. Here are the different cases:
- Digital chip & 3rd party analogue.
- Digital chip & same-company analogue (SiP or not): Higher revenue & gross profit.
- Digital +Analogue SoC: Higher gross margins and even higher revenue and gross profit.

I think android is going to make a big difference, along with either JAVA or some virtual machine for gaming like Flash.

Platform openness in general should help, yeah. I'm not a big fan of JAVA or virtual machines for this, but I can see the advantages. We'll see what happens - I remain highly skeptical though, sadly.

 

[RussSchultz]

Platform openness in general should help, yeah. I'm not a big fan of JAVA or virtual machines for this, but I can see the advantages. We'll see what happens - I remain highly skeptical though, sadly.

Content will drive the need for 3d. Without a cross platform development environment, content just won't come. nGage has shown us that.