Cell Phone DSP Hardware

Den fredag den 12. juni 2015 kl. 04.03.19 UTC+2 skrev rickman:
> On 6/11/2015 4:52 PM, lasselangwadtchristensen@gmail.com wrote:
> > Den torsdag den 11. juni 2015 kl. 16.13.15 UTC+2 skrev Eric Jacobsen:
> >> On Thu, 11 Jun 2015 01:35:49 -0400, rickman <gnuarm@gmail.com> wrote:
> >>
> >>> On 6/10/2015 11:56 PM, Randy Yates wrote:
> >>>> Randy Yates <yates@digitalsignallabs.com> writes:
> >>>>
> >>>>> rickman <gnuarm@gmail.com> writes:
> >>>>>
> >>>>>> Anyone know what DSP hardware is used in cell phones these days?  Did
> >>>>>> the TI designs end up as IP on SoCs allowing software reuse or did one
> >>>>>> of the several DSP startups get their IP onto the SoC devices
> >>>>>> requiring a lot of porting?
> >>>>>
> >>>>> Rick,
> >>>>>
> >>>>> Not THESE days, but when I was at Ericsson (late 90s/early 2000s), they
> >>>>> had their own GSM chipset (all hardware) for many years that did pretty
> >>>>> all the DSP in the tx/rx chain except the voice codecs, which, along
> >>>>> with other audio processing, was done on a TI C54x DSP.
> >>>>
> >>>> PS: When Ericsson split off their handset development to Sony/Ericsson
> >>>> around 2001, they formed Ericsson Mobile Platforms to do chipset
> >>>> development. They were around for several years, but I'm not sure if
> >>>> they still are.
> >>>>
> >>>> Also, I don't know if either of these answer your inquiry - I may have
> >>>> not understood it correctly.
> >>>
> >>> Sure, an insight is helpful.  I was just curious how the DSP thing
> >>> worked out.  I remember when cell phones were starting out TI made a
> >>> decision to steer the whole semi part of the company (which may have
> >>> ended up being pretty much the *whole* company) to support the cell
> >>> phone business.  At one time I think every hand set had a TI 5xxx DSP in
> >>> it and every base station had a TI 6xxx DSP (or many I guess).  Likely
> >>> even the base stations have special chips in them now.
> >>
> >> Many of the BSs are FPGAs.   Since the BS volumes aren't nearly as
> >> high as the handsets, and the BSs are more expensive and need
> >> flexibility, they tend to not be dedicated silicon.
> >
> > The FPGAs also tend be in the latest and greatest process, that might offset the price of the extra silicon
> 
> That is a totally specious argument.  Yes, it is in the latest process, 
> second only to the Intel CPUs.  But the FPGA fabric adds a 10x 
> multiplier in silicon area (at least) and some factor of lost speed 2x, 
> 10x???  Then there is the power issue.  I don't know how FPGAs weigh in 
> on power consumption if you compare apples to apples in terms of product 
> goals.  What I do know is you have no way to trade off speed for power 
> as you do in ASSPs.
> 

but then you don't have to buy a couple $mill mask sets and handle testing 
at die level and fixing or changing something isn't  yet another multi month $mill process 

you can't do anything about static power, you can always clock it just fast enough to get minimum dynamic power


> 
> > And I've been told by distributors that since so much of the cost of an FPGA
> > is the development cost, they can offer big volume discounts
> 
> There is a bit of irony in that.  FPGAs beat ASICs because of the large 
> NRE costs for anything custom.  Then they hit you up in the purchase 
> price for the NRE of making the FPGAs. lol   Still, that NRE is spread 
> over a *much* larger customer base with a *much* larger sales volume.

that's the whole point, share the huge NRE on FPGAs and ICs in the hottest process over a large sales volume. 

with a bigger part of the price being NRE, the is more room for discounts 
on volumes

> 
> BTW, I was told by Xilinx people on several occasions that they spend 
> more on developing the software than they do the hardware.  I wonder how 
> many feel they get their money's worth with Xilinx?  I'm glad I don't 
> have first hand experience with their tools for a number of years.
> 

if you don't have first hand experience how would you know?

-Lasse

On 6/11/2015 10:59 PM, lasselangwadtchristensen@gmail.com wrote:
> Den fredag den 12. juni 2015 kl. 04.03.19 UTC+2 skrev rickman:
>> On 6/11/2015 4:52 PM, lasselangwadtchristensen@gmail.com wrote:
>>> Den torsdag den 11. juni 2015 kl. 16.13.15 UTC+2 skrev Eric Jacobsen:
>>>> On Thu, 11 Jun 2015 01:35:49 -0400, rickman <gnuarm@gmail.com> wrote:
>>>>
>>>>> On 6/10/2015 11:56 PM, Randy Yates wrote:
>>>>>> Randy Yates <yates@digitalsignallabs.com> writes:
>>>>>>
>>>>>>> rickman <gnuarm@gmail.com> writes:
>>>>>>>
>>>>>>>> Anyone know what DSP hardware is used in cell phones these days?  Did
>>>>>>>> the TI designs end up as IP on SoCs allowing software reuse or did one
>>>>>>>> of the several DSP startups get their IP onto the SoC devices
>>>>>>>> requiring a lot of porting?
>>>>>>>
>>>>>>> Rick,
>>>>>>>
>>>>>>> Not THESE days, but when I was at Ericsson (late 90s/early 2000s), they
>>>>>>> had their own GSM chipset (all hardware) for many years that did pretty
>>>>>>> all the DSP in the tx/rx chain except the voice codecs, which, along
>>>>>>> with other audio processing, was done on a TI C54x DSP.
>>>>>>
>>>>>> PS: When Ericsson split off their handset development to Sony/Ericsson
>>>>>> around 2001, they formed Ericsson Mobile Platforms to do chipset
>>>>>> development. They were around for several years, but I'm not sure if
>>>>>> they still are.
>>>>>>
>>>>>> Also, I don't know if either of these answer your inquiry - I may have
>>>>>> not understood it correctly.
>>>>>
>>>>> Sure, an insight is helpful.  I was just curious how the DSP thing
>>>>> worked out.  I remember when cell phones were starting out TI made a
>>>>> decision to steer the whole semi part of the company (which may have
>>>>> ended up being pretty much the *whole* company) to support the cell
>>>>> phone business.  At one time I think every hand set had a TI 5xxx DSP in
>>>>> it and every base station had a TI 6xxx DSP (or many I guess).  Likely
>>>>> even the base stations have special chips in them now.
>>>>
>>>> Many of the BSs are FPGAs.   Since the BS volumes aren't nearly as
>>>> high as the handsets, and the BSs are more expensive and need
>>>> flexibility, they tend to not be dedicated silicon.
>>>
>>> The FPGAs also tend be in the latest and greatest process, that might offset the price of the extra silicon
>>
>> That is a totally specious argument.  Yes, it is in the latest process,
>> second only to the Intel CPUs.  But the FPGA fabric adds a 10x
>> multiplier in silicon area (at least) and some factor of lost speed 2x,
>> 10x???  Then there is the power issue.  I don't know how FPGAs weigh in
>> on power consumption if you compare apples to apples in terms of product
>> goals.  What I do know is you have no way to trade off speed for power
>> as you do in ASSPs.
>>
>
> but then you don't have to buy a couple $mill mask sets and handle testing
> at die level and fixing or changing something isn't  yet another multi month $mill process

That has nothing to do with the FPGA being "the latest process".  In 
fact, that is another of the advantages of ASSPs.  You can work in a 
mature process that is several generations old with much lower NRE for 
the masks as well as recurring costs on the dies, without a loss of 
performance compared to FPGAs.  The performance issues of FPGAs are a 
high cost to pay for the flexibility.  If your volumes don't justify an 
ASSP then great.  Otherwise they are an expensive choice in high volumes.


> you can't do anything about static power, you can always clock it just fast enough to get minimum dynamic power
>
>
>>
>>> And I've been told by distributors that since so much of the cost of an FPGA
>>> is the development cost, they can offer big volume discounts
>>
>> There is a bit of irony in that.  FPGAs beat ASICs because of the large
>> NRE costs for anything custom.  Then they hit you up in the purchase
>> price for the NRE of making the FPGAs. lol   Still, that NRE is spread
>> over a *much* larger customer base with a *much* larger sales volume.
>
> that's the whole point, share the huge NRE on FPGAs and ICs in the hottest process over a large sales volume.

Or go with a mature process and save on both the NRE and the recurring 
expenses compared to using bleeding edge technology.


> with a bigger part of the price being NRE, the is more room for discounts
> on volumes

More room than what?  The fact that FPGAs are designed with some of the 
very highest NREs does not make the recurring costs any lower.  Drop 
back a few process generations and save on both NRE and recurring 
without a need for "discounts".


>> BTW, I was told by Xilinx people on several occasions that they spend
>> more on developing the software than they do the hardware.  I wonder how
>> many feel they get their money's worth with Xilinx?  I'm glad I don't
>> have first hand experience with their tools for a number of years.
>>
>
> if you don't have first hand experience how would you know?

I don't have to eat at McDonalds to know what the food is like.  I hear 
what others say about their meals.

-- 

Rick

rickman  <gnuarm@gmail.com> wrote:

>On 6/11/2015 10:35 PM, Steve Pope wrote:

>> And, assuming it's a soft core, analyzing
>> the chip cannot tell you very much.

>Huh?  What sort of soft core would be in a full custom chip?

I'm sure both soft cores and hard cores are used in full custom
chips.  Why might a DSP be more likely to be a soft core, might
be the better question ... my answer is that, a DSP is less
demanding than the GPU or CPU, so the advantages of designing
a hard core are not as great for the DSP, and they come at a
cost, since it must be (at least partly) redesigned for each
new process node.

Having said that, I don't have any insight into whether these
are typically hard, or typically soft.

Steve

On 6/12/2015 4:44 AM, Steve Pope wrote:
> rickman  <gnuarm@gmail.com> wrote:
>
>> On 6/11/2015 10:35 PM, Steve Pope wrote:
>
>>> And, assuming it's a soft core, analyzing
>>> the chip cannot tell you very much.
>
>> Huh?  What sort of soft core would be in a full custom chip?
>
> I'm sure both soft cores and hard cores are used in full custom
> chips.  Why might a DSP be more likely to be a soft core, might
> be the better question ... my answer is that, a DSP is less
> demanding than the GPU or CPU, so the advantages of designing
> a hard core are not as great for the DSP, and they come at a
> cost, since it must be (at least partly) redesigned for each
> new process node.
>
> Having said that, I don't have any insight into whether these
> are typically hard, or typically soft.

Perhaps you can explain what you perceive the difference to be?

-- 

Rick

rickman  <gnuarm@gmail.com> wrote:

>On 6/12/2015 4:44 AM, Steve Pope wrote:

>> rickman  <gnuarm@gmail.com> wrote:


>>> On 6/11/2015 10:35 PM, Steve Pope wrote:

>>>> And, assuming it's a soft core, analyzing
>>>> the chip cannot tell you very much.

>>> Huh?  What sort of soft core would be in a full custom chip?

>> [..]

>Perhaps you can explain what you perceive the difference to be?

Sure.

A soft core is implemented in RTL along with the rest of the logic
design of the SoC, a hard core is layout-based design that is
modeled during RTL design and then included as a black box during
place and route.

(Is there another definition?)


Steve

On Fri, 12 Jun 2015 16:35:25 +0000 (UTC), spope33@speedymail.org
(Steve Pope) wrote:

>rickman  <gnuarm@gmail.com> wrote:
>
>>On 6/12/2015 4:44 AM, Steve Pope wrote:
>
>>> rickman  <gnuarm@gmail.com> wrote:
>
>
>>>> On 6/11/2015 10:35 PM, Steve Pope wrote:
>
>>>>> And, assuming it's a soft core, analyzing
>>>>> the chip cannot tell you very much.
>
>>>> Huh?  What sort of soft core would be in a full custom chip?
>
>>> [..]
>
>>Perhaps you can explain what you perceive the difference to be?
>
>Sure.
>
>A soft core is implemented in RTL along with the rest of the logic
>design of the SoC, a hard core is layout-based design that is
>modeled during RTL design and then included as a black box during
>place and route.
>
>(Is there another definition?)
>
>
>Steve

To expand a tiny bit, some of the "soft" features, other than being
delivered as RTL/HDL or whatever, is configurability.  Changing a
couple user-controllable parameters at synthesis time, or potentially
even place-and-route, can drastically alter what gets instantiated on
the silicon.


Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com

Eric Jacobsen <eric.jacobsen@ieee.org> wrote:

>On Fri, 12 Jun 2015 16:35:25 +0000 (UTC), spope33@speedymail.org

>>A soft core is implemented in RTL along with the rest of the logic
>>design of the SoC, a hard core is layout-based design that is
>>modeled during RTL design and then included as a black box during
>>place and route.

>>(Is there another definition?)

>To expand a tiny bit, some of the "soft" features, other than being
>delivered as RTL/HDL or whatever, is configurability.  Changing a
>couple user-controllable parameters at synthesis time, or potentially
>even place-and-route, can drastically alter what gets instantiated on
>the silicon.

Right.  Actually either a soft- or hard-core (by my definition
above) could be configurable, but more so with a soft core.

I don't think the degree of configurability makes it "soft", but
maybe that is an alternate definition/usage of "soft".  

In any case, that was not the distinction I had in mind in my original
comment, which was along the lines that a hard core, being a 
pre-routed block of transistors, would be detectable microscopically.
Therefore, if a TI (or whoever's) hard-core DSP were in a
baseband chip that shipped, the entire world would soon know about it
once the device is stripped down.

Steve

On 6/12/2015 12:35 PM, Steve Pope wrote:
> rickman  <gnuarm@gmail.com> wrote:
>
>> On 6/12/2015 4:44 AM, Steve Pope wrote:
>
>>> rickman  <gnuarm@gmail.com> wrote:
>
>
>>>> On 6/11/2015 10:35 PM, Steve Pope wrote:
>
>>>>> And, assuming it's a soft core, analyzing
>>>>> the chip cannot tell you very much.
>
>>>> Huh?  What sort of soft core would be in a full custom chip?
>
>>> [..]
>
>> Perhaps you can explain what you perceive the difference to be?
>
> Sure.
>
> A soft core is implemented in RTL along with the rest of the logic
> design of the SoC, a hard core is layout-based design that is
> modeled during RTL design and then included as a black box during
> place and route.
>
> (Is there another definition?)

Ok, in the context I see what you meant.  A processor laid out from HDL 
would have less of a recognizable fingerprint and be harder to analyze 
looking at a die.

-- 

Rick

On Wednesday, June 10, 2015 at 7:49:14 PM UTC-4, rickman wrote:
> Anyone know what DSP hardware is used in cell phones these days?  Did 
> the TI designs end up as IP on SoCs allowing software reuse or did one 
> of the several DSP startups get their IP onto the SoC devices requiring 
> a lot of porting?
> 
> -- 
> 
> Rick

TI got out of the handset baseband processor business in 2012.

http://marketrealist.com/2014/11/broadcom-texas-instruments-exit-chipset-business/

However, TI still has product to serve the base station market.  See for example their Keystone and Keystone II lines and in particular the TMS320C66670 which contains an almost complete lineup of hardware peripherals to perform baseband uplink receive and downlink transmit processing for 3G and 4G cellular protocols.

TI's not the only one to throw in the towel.  Broadcomm and ST-Ericsson also made their exit, unable to compete with the likes of Qualcomm and Intel.
This pattern is very repetitive as technology becomes commoditized. For celllular, back in the late 80s phones were mostly open architecture with separate DSP chip and Microcontroller chip on the board.  TI DSPs were immensely successful in this era.  Motorola DSPs and controllers were, to a much lesser extent, also successful.

This model held up through the early to mid 90s when closed architectures like OMAP which integrated DSP and Controller cores on a single die came into prominence.  TI continued its success in this era but Qualcomm emerged strongly due to their ownership of IS-95 IP.  As I understand, Qualcomm designed their own proprietary baseband processor including their own DSP core.

As 2G transitioned to 3G the closed architectures evolved towards a SoC model by the addition of integrated hardware acceleration coprocessors to perform certain high computational complexity jobs like code phase search in UMTS WCDMA.  These accelerators complemented the DSP and controller cores which continued to do the bulk of processing.

As 3G transitioned to 4G the evolution continued with more of the baseband processing, indeed almost all of the PHY layer running on dedicated hardware integrated in the SoC.  For LTE or WiMAX the FFT based OFDMA demod, MIMO-OFDM equalizer, and Turbo decoders are likely candidates for hardware acceleration. The need for this level of hardware assist is due to the high data rates and low latencies designed into the standard.

The dominant player today is Qualcomm, with Intel, Samsung, and Mediatek also competing.  This article is a bit dated but reports that Qualcomm owned 66% of the baseband cellular market by revenue and a whopping 95% of the LTE segment in early 2014.

http://www.fiercewireless.com/story/intel-mediatek-broadcom-and-nvidia-try-catch-qualcomm-lte/2014-01-10