Are there DSP in Pandaboard?

[Hakkı Hakan Akansel]

Hi all, 

  I am wondering, Pandaboard has DSP arch, or not? I' m absolutely confuse?

  If there are DSP, what is the difference btw beagleboard?

Thanks in advance:.

--

[Kiran Chandramohan]

Yes the pandaboard has a DSP. It is a lighter version of the one in the beagleboard.

[Hakkı Hakan Akansel]

Thanks for reply, How many mhz has DSP in Pandaboard? And what is the differences btw DSP of Beagleboard? Why don' t have DSP name all references like that http://pandaboard.org/content/resources/references?

--

Hakki Hakan Akansel

Eskisehir Osmangazi Üniversitesi

Bilgisayar Mühendisliği 

Elektrik - Elektronik Mühendisliği ( CAP)

[Martin Ertsås]

The DSP is part of the omap4460 chip, so it's not on that reference char for the same reason that the PowerVR and Cortex-A9 processors is not. It's part of the chip. If you look for the specifications for the omap4460, you should however see that there is a DSP there as well.

The DSP is a C64x core. Not sure about the clock of it, but the biggest changes is the support for both DDR and SDRAM memory, as well as it being a fixed point device.

- Martin

On 07/31/12 08:12, Hakk� Hakan Akansel wrote:

Thanks for reply, How many mhz has DSP in Pandaboard? And what is the differences btw DSP of Beagleboard? Why don' t have DSP name all references like that�http://pandaboard.org/content/resources/references?

On Mon, Jul 30, 2012 at 10:38 PM, Kiran Chandramohan <kirancha...@gmail.com> wrote:

Yes the pandaboard has a DSP. It is a lighter version of the one in the beagleboard.

On Monday, July 30, 2012 9:34:00 AM UTC+1, hakansel05 wrote:

Hi all,�

� I am wondering, Pandaboard has DSP arch, or not? I' m absolutely confuse?

� If there are DSP, what is the difference btw beagleboard?

Thanks in advance:.

--

--

Hakki Hakan Akansel

Eskisehir Osmangazi �niversitesi

Bilgisayar M�hendisli�i�

Elektrik - Elektronik M�hendisli�i�( CAP)

[Måns Rullgård]

Martin Ertsås <mart...@gmail.com> writes:

> The DSP is part of the omap4460 chip, so it's not on that reference char
> for the same reason that the PowerVR and Cortex-A9 processors is not.
> It's part of the chip. If you look for the specifications for the
> omap4460, you should however see that there is a DSP there as well.
>
> The DSP is a C64x core. Not sure about the clock of it, but the biggest
> changes is the support for both DDR and SDRAM memory, as well as it
> being a fixed point device.

You seem to be confused.

- The DSP is a "C64x lite", roughly half a regular C64x.
- Supported memory types is a property of the DRAM controller, not the DSP.
- The OMAP3 DSP is also fixed-point.

--
Måns Rullgård
ma...@mansr.com

[Kiran Chandramohan]

I think the DSP is clocked at 466 MHz. 

On Tuesday, July 31, 2012 11:22:32 AM UTC+1, Måns wrote:

mans

[Dan MacDonald]

466Mhz? Thats pretty impressive and could do a hell of a lot to improve the performance of some LADSPA and LV2 audio plugins if they got tweaked to utilise this DSP of course.

Is the DSP clocked higher on the ES? Will the OMAP5 have a DSP too and do we have any idea how fast that will be?

Most importantly, Is anyone aware of any functional, open source apps that utilise the Pandas DSP for any purpose whatsoever?

[Andrew Voelkel]

Don't forget about the DSP functionality on the A8/A9 itself. That isn't bad either, and would have more portability to other platforms. It also supports floating point. It is a little more difficult to program, because it's SIMD. But there are support libraries.

- Andy

[Nipuna Gunasekera]

>>Most importantly, Is anyone aware of any functional, open source apps that utilise the Pandas DSP for any purpose whatsoever?

DSP on OMAP4/PandaBoard is also referred to as "Tesla" and can be connected to by using CCS using the JTAG interface directly for it to be programmed.  Some information on this is available here:  http://omapedia.org/wiki/PandaBoard_JTAG_Debugging

Compiler needed for writing some code and loading via JTAG to the DSP also should be available in CCS. 

Also, there is some information available in the syslink project:  http://omappedia.org/wiki/Syslink_Project

Syslink has recently been replaced with Rpmsg in the recent releases:

http://omappedia.org/wiki/Category:RPMsg

Others can probably comment on if there are some examples of loading something simple on the DSP using any of the two above mentioned mechanisms as well.

-Nipuna

[Dan MacDonald]

Would it be possible to use both DSPs simultaneously? I know you say that if you code for the inbuilt one its more portable but I would presume the C64..  would be the one to go for if we have to pick one or the other?

[Måns Rullgård]

Andrew Voelkel <an...@voelkel.us> writes:

> Don't forget about the DSP functionality on the A8/A9 itself. That isn't
> bad either, and would have more portability to other platforms. It also
> supports floating point. It is a little more difficult to program, because
> it's SIMD. But there are support libraries.

Do not confuse the NEON instruction set with an independent DSP core.

--
Måns Rullgård
ma...@mansr.com

[Andrew Voelkel]

I wasn't. What's your point? Mine is getting DSP tasks done, in my case the interest is audio processing.

[Andrew Voelkel]

I haven't programmed either, but the c64 is a fixed point 16 architecture, which is a bit of a pain for high quality audio. I'm not sure what its throughput would be. The Neon is a SIMD architecture and is therefore a pain to program, but does have floating point, and I've heard that the throughput can actually be pretty decent. I guess for me, I'd look at the task at hand. If the Neon would work, I'd use it because more platforms will support it, and I'm not interested in only OMAP processors. 

[Måns Rullgård]

Andrew Voelkel <an...@voelkel.us> writes:

> On Thu, Aug 2, 2012 at 5:36 AM, Måns Rullgård <ma...@mansr.com> wrote:
>
>> Andrew Voelkel <an...@voelkel.us> writes:
>>
>> > Don't forget about the DSP functionality on the A8/A9 itself. That isn't
>> > bad either, and would have more portability to other platforms. It also
>> > supports floating point. It is a little more difficult to program, because
>> > it's SIMD. But there are support libraries.
>>
>> Do not confuse the NEON instruction set with an independent DSP core.
>
> I wasn't. What's your point? Mine is getting DSP tasks done, in my case the
> interest is audio processing.

You sure made it sound that way.

--
Måns Rullgård
ma...@mansr.com

[Andrew Voelkel]

Sorry if I was abrupt in my last email, but I'm not sure why you thought I was confusing the Neon coprocessor with the separate DSP core.   

I'd be interested in some benchmarks of DSP done using the Neon instructions vs. the c64 DSP. I wouldn't be surprised if the Neon compares favorably, especially when you consider clock rate and that there are two cores. There are good reasons to think that SIMD is a better way to do DSP these days, because data locality is so important in modern chip design. It's an area I'd like to investigate.

- Andy

[Måns Rullgård]

Andrew Voelkel <an...@voelkel.us> writes:

> I'd be interested in some benchmarks of DSP done using the Neon
> instructions vs. the c64 DSP. I wouldn't be surprised if the Neon compares
> favorably, especially when you consider clock rate and that there are two
> cores. There are good reasons to think that SIMD is a better way to do DSP
> these days, because data locality is so important in modern chip design.
> It's an area I'd like to investigate.

The DSP on the omap4 is a cut-down design with low performance. The ARM
cores will certainly beat it at just about anything. The reason it is
there is not that it can do things faster, but that it can do things
independently of the ARM cores.

Your statement about SIMD is a little odd, seeing as many modern DSPs,
the C64x included, have SIMD instructions. I also fail to see what data
locality has to do with the instruction set.

--
Måns Rullgård
ma...@mansr.com

[Rob Clark]

well, assuming the data to decode is coming from the arm (ie. demuxing
from container file on arm), there is some overheads to doing the
decode on the dsp because it is not cache coherent (or rather sharing
the same cache). Plus there are some IPC overheads. In general,
using a well optimized neon audio decoder on arm works out better than
trying to offload that to the DSP.

(and you are right.. that has nothing to do with instruction set, but
everything to do with where the instruction set lives)

BR,
-R

> --
> Måns Rullgård
> ma...@mansr.com

[Måns Rullgård]

Rob Clark <robd...@gmail.com> writes:

> On Fri, Aug 3, 2012 at 3:32 AM, Måns Rullgård <ma...@mansr.com> wrote:
>> Andrew Voelkel <an...@voelkel.us> writes:
>>
>>> I'd be interested in some benchmarks of DSP done using the Neon
>>> instructions vs. the c64 DSP. I wouldn't be surprised if the Neon compares
>>> favorably, especially when you consider clock rate and that there are two
>>> cores. There are good reasons to think that SIMD is a better way to do DSP
>>> these days, because data locality is so important in modern chip design.
>>> It's an area I'd like to investigate.
>>
>> The DSP on the omap4 is a cut-down design with low performance. The ARM
>> cores will certainly beat it at just about anything. The reason it is
>> there is not that it can do things faster, but that it can do things
>> independently of the ARM cores.
>>
>> Your statement about SIMD is a little odd, seeing as many modern DSPs,
>> the C64x included, have SIMD instructions. I also fail to see what data
>> locality has to do with the instruction set.
>
> well, assuming the data to decode is coming from the arm (ie. demuxing
> from container file on arm), there is some overheads to doing the
> decode on the dsp because it is not cache coherent (or rather sharing
> the same cache).

That depends on how you do it. There doesn't need to be any overhead.

> Plus there are some IPC overheads. In general, using a well optimized
> neon audio decoder on arm works out better than trying to offload that
> to the DSP.

If your only concern is decoding audio, yes. If you want every cycle
you can get on the ARM to, say, run a game engine, offloading some
things to a DSP can certainly be beneficial.

--
Måns Rullgård
ma...@mansr.com