joggingsong@gmail.com wrote:
> On Dec 10, 5:47 pm, Steve Underwood <ste...@dis.org> wrote:
>> joggings...@gmail.com wrote:
>>> Hi,all
>>>     We know there are one ARM core and C64x core in DaVinci from TI.
>>> The ARM core is for OS and C64x is for DSP. Is it possible to merge
>>> two cores into one? This idea is crazy? It makes me think of XScale
>>> core which is a ARM core with wireMMX coprocessor. Blackfin from ADI
>>> can run ucLinux and do DSP at the same time.
>>> Thanks in advance.
>>> Jogging
>> People have been trying for many years to achieve a core which does both
>> DSP and more general purpose MCU work well. The Blackfin is probably the
>> most successful attempt to do this. The XScale is a disaster. Even the
>> Blackfin has problems, though. Anything big will be running mostly from
>> the outside, and this is rather slow. This would typically be the MCU
>> type code. It can quickly chew up lots of processing time, restricting
>    MCU type code? Can you give a clear definition?
> If the size of application code is larger than the size of cache and
> SRAM, it is necessary
> to put some of the code on SDRAM whatever it is a MCU or DSP.
> 
> Jogging

I think anyone who has done even a litle DSP work should have no trouble 
identifying what is traditional MCU work and what requires a DSP 
oriented core for efficient execution.

Most MCU code is not required to run at breakneck speed. Most of the 
world's MCUs are not even running at the maker's rated maximum speed. 
Few DSPs run at anything other than the maker's rated speed. This has a 
huge impact when the working set exceeds the internal memory. If there 
are two cores, the DSP one can continue at full speed. If there is one 
generalised core, it can stall so much while executing only a modest 
amount of bulky MCU type code from the outside world that little time is 
left for DSP work.

 > [...]

Steve

Vladimir Vassilevsky wrote:
> 
> 
> Steve Underwood wrote:
> 
> 
>> People have been trying for many years to achieve a core which does 
>> both DSP and more general purpose MCU work well. The Blackfin is 
>> probably the most successful attempt to do this.
> 
> P4 is probably the most successfull attempt to do this; BlackFin is 
> probably the most successfull attempt to do this for cheap.

P4? That's a lousy DSP. The K8 and Core 2 are far better. Its really 
hard to get good DSP performance from a P4.

That said, I think the DSP integration in all the x86 family parts is 
rather poor. MMX was a joke, but the various SSEs don't do a 
particularly sparkling job.

You only mentioned price. The Blackfin bets the P4 hands down on energy 
consumption, too.

Steve

On Tue, 11 Dec 2007 00:58:44 -0800 (PST), Chris Bore
<chris.bore@gmail.com> wrote:

>On Dec 10, 9:25 am, joggings...@gmail.com wrote:
>> Hi,all
>>     We know there are one ARM core and C64x core in DaVinci from TI.
>> The ARM core is for OS and C64x is for DSP. Is it possible to merge
>> two cores into one? This idea is crazy? It makes me think of XScale
>> core which is a ARM core with wireMMX coprocessor. Blackfin from ADI
>> can run ucLinux and do DSP at the same time.
>>
>> Thanks in advance.
>> Jogging
>
>There are several reasons that two different cores may be an
>advantage:
>
>1) there is a clear separation of OS and infrastructure from DSP. That
>is, a Linux programmer can work on the ARM (or other general purpose
>CPU) without knowing anything about the special SP core. And the DSP
>programmer can work on the DSP without knowing anything about the
>general purpose CPU. This sort of separation can be valuable when you
>are developing with large software teams, or allocating aspects of
>design work to different groups or vendors.
>
>2) For a 'DSP' manufacturer it can be hard to continue to support a
>general purpose OS on their core long term. Whereas ARM, for instance,
>are totally focussed on this OS/infrastructure side of things and so
>can develop their core optimised for that purpose.
>
>3) It takes a lot of work to design a core, and it has proven very
>hard to in fact design cores that suit both OS/infrastrcuture and DSP.
>One solution is to combine two cores, each optimised for their own
>domain of application. For instance TI can benefot from allof ARM's
>expertise and experience in the general purpose domain, and add to
>that their own unique experience and expertise in DSP. Focus like this
>can prove more valuable in practice than diversifying - 'jack of all
>trades, master of none' is the saying.
>
>4) the inter-processor boundary can possibly also be a legal one. A
>DSP vendor puts an enormous amount of investment into highly optimised
>codecs and so on. There is a fear (justified or not, but real) that
>these may become polluted by open licences if combined with Linux.
>Having these specialised applications run on a second core can be
>argued to separate them clearly from the open source software and so
>protect them from becoming open source.
>
>5) Having two cores can separate the customer (Linux programmer,
>customer) from the vendor in terms of expertise. If you have one core
>then the customer must learn how to use it, which means their
>expertise now overlaps that of the third party DSP software vendor.
>The argument can be made: 'since I know how to program the DSP, why do
>I not write my own DSP codecs?'.If the two wocres are different then
>the customer's skills do not overlap those of the DSP third party - so
>the customer does not compete so easily with third party products.
>This can help encourage a market in thrid party software, which is
>undermined when customers have the option of in-house development.
>
>6) A DSP core typically runs loaded at very high levels - 80% or 90%
>of peak on avarega is not unusual. General purpose CPUs tend to run
>with much lower loadings, to allow them more overhead for peak
>performance. The issues in sharing resources in a lump-demand OS with
>a continuously-high demand DSP are not that easy to solve, so it can
>be easier to separate them.
>
>7) Experience suggests that, with several generations of 'do-
>everything' DSP-and-OS cores from various vendors, in practice they
>are not optimal at either task, and the OS software gets out of date.
>
>8) Increasing number of transistors in single core devices becomes
>increasoingly difficult. So multi-core designs may become more popular
>in future, and if you have multi-core then why not tune each core to
>its specific domain of application?
>
>Chris
>=================================
>Chris Bore
>BORES Signal Processing
>www.bores.com

My understand from when this was done at Intel (Manitoba, which I
mentioned previously), was that the code for the phone has to be
carefully qualified to be allowed on the networks.   The last thing an
operator wants is for a buggy phone to start babbling on the network
and tie up resources.  So running applications on the same core as the
network/phone code made a lot of folks nervous, and partitioning the
DSP/phone/network code and application code on two separate processors
made a lot of sense.

I've since seen phones that I'm pretty sure didn't have multiple cores
that would run applications, so I don't know how necessary that whole
exercise turned out to be in the end.   Nevertheless, I think that was
one of the big motivators for separating the cores, at least at that
time.

Eric Jacobsen
Minister of Algorithms
Abineau Communications
http://www.ericjacobsen.org

On Mon, 10 Dec 2007 18:26:04 -0800 (PST), joggingsong@gmail.com wrote:

>On Dec 11, 1:57 am, Eric Jacobsen <eric.jacob...@ieee.org> wrote:
>> On Mon, 10 Dec 2007 17:47:43 +0800, Steve Underwood <ste...@dis.org>
>> wrote:
>>
>> >joggings...@gmail.com wrote:
>> >> Hi,all
>> >>     We know there are one ARM core and C64x core in DaVinci from TI.
>> >> The ARM core is for OS and C64x is for DSP. Is it possible to merge
>> >> two cores into one? This idea is crazy? It makes me think of XScale
>> >> core which is a ARM core with wireMMX coprocessor. Blackfin from ADI
>> >> can run ucLinux and do DSP at the same time.
>>
>> >> Thanks in advance.
>> >> Jogging
>>
>> >People have been trying for many years to achieve a core which does both
>> >DSP and more general purpose MCU work well. The Blackfin is probably the
>> >most successful attempt to do this. The XScale is a disaster.
>>
>> It's funny that you say that.   Intel's approach was to put a Blackfin
>> and an XScale on the same die, so that the Blackfin did the DSP for
>> the phone (that had to be qualified), and the XScale could run
>> applications.
>>
>> It wasn't a successful product.
>>
>> Eric Jacobsen
>> Minister of Algorithms
>> Abineau Communicationshttp://www.ericjacobsen.org
>
>   Someone says that blackfin is a successful product, and other says
>it is not.
>I think people draw different conclusions based on their experiences.
>For different applications, blackfin is not the best choice.
>I think we shoud give some reason why blaickfin is successful or not.
>
>jogging

If you're referring to my post, what I said was that Intel's
combination of a Blackfin AND an XScale on the same die (which was
called Manitoba), wasn't successful.   That's not a statement at all
about the Blackfin by itself.

Eric Jacobsen
Minister of Algorithms
Abineau Communications
http://www.ericjacobsen.org

On Dec 10, 9:25 am, joggings...@gmail.com wrote:
> Hi,all
>     We know there are one ARM core and C64x core in DaVinci from TI.
> The ARM core is for OS and C64x is for DSP. Is it possible to merge
> two cores into one? This idea is crazy? It makes me think of XScale
> core which is a ARM core with wireMMX coprocessor. Blackfin from ADI
> can run ucLinux and do DSP at the same time.
>
> Thanks in advance.
> Jogging

There are several reasons that two different cores may be an
advantage:

1) there is a clear separation of OS and infrastructure from DSP. That
is, a Linux programmer can work on the ARM (or other general purpose
CPU) without knowing anything about the special SP core. And the DSP
programmer can work on the DSP without knowing anything about the
general purpose CPU. This sort of separation can be valuable when you
are developing with large software teams, or allocating aspects of
design work to different groups or vendors.

2) For a 'DSP' manufacturer it can be hard to continue to support a
general purpose OS on their core long term. Whereas ARM, for instance,
are totally focussed on this OS/infrastructure side of things and so
can develop their core optimised for that purpose.

3) It takes a lot of work to design a core, and it has proven very
hard to in fact design cores that suit both OS/infrastrcuture and DSP.
One solution is to combine two cores, each optimised for their own
domain of application. For instance TI can benefot from allof ARM's
expertise and experience in the general purpose domain, and add to
that their own unique experience and expertise in DSP. Focus like this
can prove more valuable in practice than diversifying - 'jack of all
trades, master of none' is the saying.

4) the inter-processor boundary can possibly also be a legal one. A
DSP vendor puts an enormous amount of investment into highly optimised
codecs and so on. There is a fear (justified or not, but real) that
these may become polluted by open licences if combined with Linux.
Having these specialised applications run on a second core can be
argued to separate them clearly from the open source software and so
protect them from becoming open source.

5) Having two cores can separate the customer (Linux programmer,
customer) from the vendor in terms of expertise. If you have one core
then the customer must learn how to use it, which means their
expertise now overlaps that of the third party DSP software vendor.
The argument can be made: 'since I know how to program the DSP, why do
I not write my own DSP codecs?'.If the two wocres are different then
the customer's skills do not overlap those of the DSP third party - so
the customer does not compete so easily with third party products.
This can help encourage a market in thrid party software, which is
undermined when customers have the option of in-house development.

6) A DSP core typically runs loaded at very high levels - 80% or 90%
of peak on avarega is not unusual. General purpose CPUs tend to run
with much lower loadings, to allow them more overhead for peak
performance. The issues in sharing resources in a lump-demand OS with
a continuously-high demand DSP are not that easy to solve, so it can
be easier to separate them.

7) Experience suggests that, with several generations of 'do-
everything' DSP-and-OS cores from various vendors, in practice they
are not optimal at either task, and the OS software gets out of date.

8) Increasing number of transistors in single core devices becomes
increasoingly difficult. So multi-core designs may become more popular
in future, and if you have multi-core then why not tune each core to
its specific domain of application?

Chris
=================================
Chris Bore
BORES Signal Processing
www.bores.com

On Dec 10, 1:25 am, joggings...@gmail.com wrote:
> Hi,all
>     We know there are one ARM core and C64x core in DaVinci from TI.
> The ARM core is for OS and C64x is for DSP. Is it possible to merge
> two cores into one?

Why?  From video games to supercomputers, the trend looks more
like going to more cores, not less.  And the more specialized
a core's function, the less compromises that likely have to be
made in its implementation.

joggingsong@gmail.com wrote:

   ...

> I think we shoud give some reason why blaickfin is successful or not.

Why?

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

On Dec 11, 1:57 am, Eric Jacobsen <eric.jacob...@ieee.org> wrote:
> On Mon, 10 Dec 2007 17:47:43 +0800, Steve Underwood <ste...@dis.org>
> wrote:
>
> >joggings...@gmail.com wrote:
> >> Hi,all
> >>     We know there are one ARM core and C64x core in DaVinci from TI.
> >> The ARM core is for OS and C64x is for DSP. Is it possible to merge
> >> two cores into one? This idea is crazy? It makes me think of XScale
> >> core which is a ARM core with wireMMX coprocessor. Blackfin from ADI
> >> can run ucLinux and do DSP at the same time.
>
> >> Thanks in advance.
> >> Jogging
>
> >People have been trying for many years to achieve a core which does both
> >DSP and more general purpose MCU work well. The Blackfin is probably the
> >most successful attempt to do this. The XScale is a disaster.
>
> It's funny that you say that.   Intel's approach was to put a Blackfin
> and an XScale on the same die, so that the Blackfin did the DSP for
> the phone (that had to be qualified), and the XScale could run
> applications.
>
> It wasn't a successful product.
>
> Eric Jacobsen
> Minister of Algorithms
> Abineau Communicationshttp://www.ericjacobsen.org

   Someone says that blackfin is a successful product, and other says
it is not.
I think people draw different conclusions based on their experiences.
For different applications, blackfin is not the best choice.
I think we shoud give some reason why blaickfin is successful or not.

jogging

On Dec 10, 5:47 pm, Steve Underwood <ste...@dis.org> wrote:
> joggings...@gmail.com wrote:
> > Hi,all
> >     We know there are one ARM core and C64x core in DaVinci from TI.
> > The ARM core is for OS and C64x is for DSP. Is it possible to merge
> > two cores into one? This idea is crazy? It makes me think of XScale
> > core which is a ARM core with wireMMX coprocessor. Blackfin from ADI
> > can run ucLinux and do DSP at the same time.
>
> > Thanks in advance.
> > Jogging
>
> People have been trying for many years to achieve a core which does both
> DSP and more general purpose MCU work well. The Blackfin is probably the
> most successful attempt to do this. The XScale is a disaster. Even the
> Blackfin has problems, though. Anything big will be running mostly from
> the outside, and this is rather slow. This would typically be the MCU
> type code. It can quickly chew up lots of processing time, restricting
   MCU type code? Can you give a clear definition?
If the size of application code is larger than the size of cache and
SRAM, it is necessary
to put some of the code on SDRAM whatever it is a MCU or DSP.

Jogging
> the DSP that is possible. The DaVinci approach is much messier from the
> developers pint of view, but it does keep the work in the places where
> it can be done well. The ARM may look pretty slow compared to the DSP
> core, but its usually fast enough for the MCU type code, and avoids
> cache thrashing and other performance drains on the DSP core.
>
> The Blackfin is nice, but it is no magic cure.
>
> Steve

On Mon, 10 Dec 2007 17:47:43 +0800, Steve Underwood <steveu@dis.org>
wrote:

>joggingsong@gmail.com wrote:
>> Hi,all
>>     We know there are one ARM core and C64x core in DaVinci from TI.
>> The ARM core is for OS and C64x is for DSP. Is it possible to merge
>> two cores into one? This idea is crazy? It makes me think of XScale
>> core which is a ARM core with wireMMX coprocessor. Blackfin from ADI
>> can run ucLinux and do DSP at the same time.
>> 
>> Thanks in advance.
>> Jogging
>
>People have been trying for many years to achieve a core which does both 
>DSP and more general purpose MCU work well. The Blackfin is probably the 
>most successful attempt to do this. The XScale is a disaster.

It's funny that you say that.   Intel's approach was to put a Blackfin
and an XScale on the same die, so that the Blackfin did the DSP for
the phone (that had to be qualified), and the XScale could run
applications.

It wasn't a successful product.

Eric Jacobsen
Minister of Algorithms
Abineau Communications
http://www.ericjacobsen.org