ARM7, DSP and mobile phone, how and why?

Hi,

I've heard from a course that many real world communication system
adopt an architecture with ARM7+DSP.  What's the advantage of this
arrangement?  How are they acutally connected?  And why select ARM
rather than other 16/32 bit microcontrollers?

I know the computation for the digital communication stuff is handled
by the DSP.    Why merge together is what I don't understand.  I feel
that the basic UI for the phone can possibly be handled by a less
capability micro, and leave only the computationally intensive stuff
for DSP.

ozonehole2k@yahoo.com (Ozone Hole near South Pole) writes:

> Hi,
> 
> I've heard from a course that many real world communication system
> adopt an architecture with ARM7+DSP.  What's the advantage of this
> arrangement?  How are they acutally connected?  And why select ARM
> rather than other 16/32 bit microcontrollers?
> 
> I know the computation for the digital communication stuff is handled
> by the DSP.    Why merge together is what I don't understand.  I feel
> that the basic UI for the phone can possibly be handled by a less
> capability micro, and leave only the computationally intensive stuff
> for DSP.

Hi,

There can be a surprising amount of work to be done by the "host"
processor in a GSM mobile terminal. For example, there can be a lot of
data shuffling on every 4.6 millisecond tick (each TDMA frame) and
even more on the speech frames (every 20 milliseconds on average).

There are also multimedia tasks like manipulation of camera images 
that the host in the newer platforms must handle. 

These types of things, in connection with handling user input and
a graphical display output, and the use of a high-level language
like C++, can require a significant amount of horsepower for 
reasonable performance. 
-- 
Randy Yates
Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA
randy.yates@sonyericsson.com, 919-472-1124

"Ozone Hole near South Pole" <ozonehole2k@yahoo.com> wrote in message
news:cd22f127.0406070047.6200d748@posting.google.com...
> Hi,
>
> I've heard from a course that many real world communication system
> adopt an architecture with ARM7+DSP. What's the advantage of this
> arrangement?

Technically dunno.  Commercially, if everyone else is doing it,
then it makes the task of technology sharing easier.

>  How are they acutally connected?

Nowadays they are on the same chip connected via an internal
bus and some shared RAM (I have some confidential docs
on my desk that could tell you more, but unfortunately I can't)

> And why select ARM
> rather than other 16/32 bit microcontrollers?

Because ARM's IP strategy is the best fit.  The developers of
mobile solutions leave ARM to do the processor development
and they concentrate on the other stuff.  There are alternative
IP companies to ARM, but ARM won the market before the
others could get in and now there is little chance of anything
changing..

> I know the computation for the digital communication stuff is handled
> by the DSP.    Why merge together is what I don't understand.

For the same reason as any other integration.  A smaller
single chip costs less and uses less power than many chips.
Space is also at a premium with Mobile phones. there is a
trend for them to be as small as possible so you want the
components to take up as little space as possible (because
the batteries don't seem to be getting any smaller).

> I feel
> that the basic UI for the phone can possibly be handled by a less
> capability micro, and leave only the computationally intensive stuff
> for DSP.

There is a lot of stuff in the middle that has to be handled by
the other micro, far too much for you small micro.  The trend
in the next generation of phones with video capability will be to
have two micros.

And my network's just gone down so god know how long it
will be before I post this.

tim

Randy Yates wrote:

> ozonehole2k@yahoo.com (Ozone Hole near South Pole) writes:
> 
> 
>>Hi,
>>
>>I've heard from a course that many real world communication system
>>adopt an architecture with ARM7+DSP.  What's the advantage of this
>>arrangement?  How are they acutally connected?  And why select ARM
>>rather than other 16/32 bit microcontrollers?
>>
>>I know the computation for the digital communication stuff is handled
>>by the DSP.    Why merge together is what I don't understand.  I feel
>>that the basic UI for the phone can possibly be handled by a less
>>capability micro, and leave only the computationally intensive stuff
>>for DSP.
> 
> 
> Hi,
> 
> There can be a surprising amount of work to be done by the "host"
> processor in a GSM mobile terminal. For example, there can be a lot of
> data shuffling on every 4.6 millisecond tick (each TDMA frame) and
> even more on the speech frames (every 20 milliseconds on average).
> 
> There are also multimedia tasks like manipulation of camera images 
> that the host in the newer platforms must handle. 
> 
> These types of things, in connection with handling user input and
> a graphical display output, and the use of a high-level language
> like C++, can require a significant amount of horsepower for 
> reasonable performance. 

Also, the ARM core is (or was) available from ARM with a built-in DSP.

High-level languages don't have to use more resources than assembly, but 
if you have one you can sure cut engineering time by throwing them 
around -- and with processor resources getting cheaper every day it's 
usually a good trade.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Tim Wescott <tim@wescottnospamdesign.com> writes:
> [...]
> High-level languages don't have to use more resources than assembly,

I strongly disagree. Every comparison I've ever seen and done between
C and assembly required significantly more MIPS. An average I would have
said a few years back is 5:1. I would say it's a minimum of 2:1. Keep 
in mind this is for a GOOD assembly programmer. 

However, it is impractical to convert hundreds of thousands of HLL lines
into assembly, and, as you subsequently stated, the cost of processor
power is getting cheaper all the time.
-- 
Randy Yates
Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA
randy.yates@sonyericsson.com, 919-472-1124

Randy Yates wrote:

> Tim Wescott <tim@wescottnospamdesign.com> writes:
> 
>>[...]
>>High-level languages don't have to use more resources than assembly,
> 
> 
> I strongly disagree. Every comparison I've ever seen and done between
> C and assembly required significantly more MIPS. An average I would have
> said a few years back is 5:1. I would say it's a minimum of 2:1. Keep 
> in mind this is for a GOOD assembly programmer. 
> 
> However, it is impractical to convert hundreds of thousands of HLL lines
> into assembly, and, as you subsequently stated, the cost of processor
> power is getting cheaper all the time.

You said "resources" so I assumed you meant "all resources" not just 
MIPS (in fact I was thinking more about memory than speed, bad me).  If 
you are _very_ careful with your high-level code you can use almost no 
more memory than assembly.  But such care means taking time and hiring 
skilled people, which adds to your expense and time to market, so...

As for speed, with a RISC processor you can often do better than 1/2 the 
speed of hand-coded assembly (depending heavily on your app and your 
compiler).  With DSPs and a "real" DSP app the upper limit is more like 
10:1 or 100:1, because I have yet to find a compiler that will optimize 
a loop into a hardware loop and a MAC instruction, so you have to do 
that yourself.  This is a pity, because I'd be willing to accept an 
optimizing compiler that needed to have things hinted at pretty heavily 
as long as I could write something that I could simulate on my PC and 
that non-dsp types could understand (maybe a variable called 
ThisIsTheAccumulator_Stupid?).

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

In comp.sys.arm Randy Yates <randy.yates@sonyericsson.com> wrote:
> I strongly disagree. Every comparison I've ever seen and done between
> C and assembly required significantly more MIPS. An average I would have
> said a few years back is 5:1. I would say it's a minimum of 2:1. Keep 
> in mind this is for a GOOD assembly programmer. 

It is becoming increasingly difficult to beat the best compilers on more
modern ARMs. The compiler is not sapient so there will always be cases
where the programmer can extract extra performance by noticing a
transformation or a modification of the algorithm.

However the gains that can be made are going down and the cost in
programmer time of percentage point increase in speed going up.

-p
-- 
Paul Gotch
CoreSight Tools
Development Systems ARM Limited.

This message is intended for the addressee(s) only and may contain
information that is the property of, and/or subject to a confidentiality
agreement between the intended recipient(s), their organisation and/or the
ARM Group of Companies. If you are not an intended recipient of this
message, you should not read, copy, forward or otherwise distribute or
further disclose the information in it; misuse of the contents of this
message may violate various laws in your state, jurisdiction or
country. If you have received this message in error, please contact
the originator of this message via email and delete all copies of
this message from your computer or network, thank you.
---------------------------------------------------------------------

>>>>> "Tim" == Tim Wescott <tim@wescottnospamdesign.com> writes:

    Tim> As for speed, with a RISC processor you can often do better than 1/2
    Tim> the speed of hand-coded assembly (depending heavily on your app and
    Tim> your compiler).  With DSPs and a "real" DSP app the upper limit is
    Tim> more like 10:1 or 100:1, because I have yet to find a compiler that
    Tim> will optimize a loop into a hardware loop and a MAC instruction, so
    Tim> you have to do that yourself.  This is a pity, because I'd be willing
    Tim> to accept an optimizing compiler that needed to have things hinted at
    Tim> pretty heavily as long as I could write something that I could

TI's 5510 compiler will use a hardware loop when possible.  So will an
Oak DSP compiler and a DSP16K compiler, when I last tried them.  

All of these can also use a MAC or dual-MAC instruction for
sufficiently simple FIR filter loops.  More complicated things,
however, probably won't.

I've also seen the compilers do amazingly stupid things too.

The the mythical SSC (Sufficiently Smart Compiler) is still a myth.

Ray

paul.gotch@at-arm-dot.com writes:

> In comp.sys.arm Randy Yates <randy.yates@sonyericsson.com> wrote:
> > I strongly disagree. Every comparison I've ever seen and done between
> > C and assembly required significantly more MIPS. An average I would have
> > said a few years back is 5:1. I would say it's a minimum of 2:1. Keep 
> > in mind this is for a GOOD assembly programmer. 
> 
> It is becoming increasingly difficult to beat the best compilers on more
> modern ARMs. The compiler is not sapient so there will always be cases
> where the programmer can extract extra performance by noticing a
> transformation or a modification of the algorithm.

Care to place a wager? I'll wager that I can beat any significant algorithm
written in C by a factor of 2 or better. Post some code.
-- 
Randy Yates
Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA
randy.yates@sonyericsson.com, 919-472-1124

Raymond Toy wrote:

>>>>>>"Tim" == Tim Wescott <tim@wescottnospamdesign.com> writes:
> 
> 
>     Tim> As for speed, with a RISC processor you can often do better than 1/2
>     Tim> the speed of hand-coded assembly (depending heavily on your app and
>     Tim> your compiler).  With DSPs and a "real" DSP app the upper limit is
>     Tim> more like 10:1 or 100:1, because I have yet to find a compiler that
>     Tim> will optimize a loop into a hardware loop and a MAC instruction, so
>     Tim> you have to do that yourself.  This is a pity, because I'd be willing
>     Tim> to accept an optimizing compiler that needed to have things hinted at
>     Tim> pretty heavily as long as I could write something that I could
> 
> TI's 5510 compiler will use a hardware loop when possible.  So will an
> Oak DSP compiler and a DSP16K compiler, when I last tried them.  
> 
> All of these can also use a MAC or dual-MAC instruction for
> sufficiently simple FIR filter loops.  More complicated things,
> however, probably won't.
> 
> I've also seen the compilers do amazingly stupid things too.
> 
> The the mythical SSC (Sufficiently Smart Compiler) is still a myth.
> 
> Ray

I'll keep that in mind.  TI's 28xx compiler won't, and the ADI 28xx 
compiler also wouldn't.  Fortunately I like a good excuse to code small 
things in assembly.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com