How Will The Dsp Interface With The Arm Portion?


jpardey

Still Fresh
Joined
Jul 16, 2008
Messages
7
I'm not very experienced with assembly (one ARM course), but I'm wondering what the DSP will be running at any moment. In my attempt to figure out what the OMAP3 was all about, I read something about mailbox interrupts. Also, the two architectures are obviously very different. Will there be a process/thread scheduler for each process? What will the mailbox be able to do, aside from possibly trigger DMA or something? Will there be libraries for both processors so the developer can choose which processor to run certain routines on?

I'm not sure what words to use in this, architecture, processor, core, etc, but I tried to be clear. I'm quite confused as to how this thing will be used efficiently. Any idea when the SDK will be out, so I can confuse myself on that? And are there any similar systems with Linux ports that developers here can learn from (closest I can think of is the Cell)?
 
jpardey said:
I'm not very experienced with assembly (one ARM course), but I'm wondering what the DSP will be running at any moment. In my attempt to figure out what the OMAP3 was all about, I read something about mailbox interrupts. Also, the two architectures are obviously very different. Will there be a process/thread scheduler for each process? What will the mailbox be able to do, aside from possibly trigger DMA or something? Will there be libraries for both processors so the developer can choose which processor to run certain routines on?

I'm not sure what words to use in this, architecture, processor, core, etc, but I tried to be clear. I'm quite confused as to how this thing will be used efficiently. Any idea when the SDK will be out, so I can confuse myself on that? And are there any similar systems with Linux ports that developers here can learn from (closest I can think of is the Cell)?
Check out DSP gateway (dspgateway.sf.net).
Also check out : http://maemo.org/community/wiki/dspprogramming/
The N800 runs on OMAP24xx and has a DSP and runs linux.
 
Last edited by a moderator:
rahulgarg said:
Check out DSP gateway (dspgateway.sf.net).
Also check out : http://maemo.org/community/wiki/dspprogramming/
The N800 runs on OMAP24xx and has a DSP and runs linux.



Thanks a lot! I sort of expected some sort of ad hoc unsynchronized spaghetti between the two, but this sounds great. I take it there is a version of DSP Gateway for the OMAP3 line, or at least is in progress?
 
Last edited by a moderator:
jpardey said:
I take it there is a version of DSP Gateway for the OMAP3 line, or at least is in progress?
TI is pushing its own dspbridge but so far it was not accepted to linux-omap due to size of the patch and some unneeded generic layers in the code. They were told to feed it in small patches so we'll see.
 
Last edited by a moderator:
fusion_power said:
Uh, what exactly is a "DSP" and what can we do with it? ^_^
Digital Signal Processor

A DSP is basically a specialized processor, often used for audio/video encoding and decoding. Because they are usually designed around one or two specific functions, they are much simpler and more efficient at those tasks than a general purpose processor.

In the Pandora's case, the TMS320C64x+ DSP will probably be used for real time h.264 playback and other video processing tasks. It could also be used to play back MP3s using much less power than the OMAP CPU - which is where the 100-hour battery rating comes from. There is even the potential to use it for things like sound processing in some emulators, offloading that task from the CPU and improving overall speed and efficiency.
 
Last edited by a moderator:
Chip said:
fusion_power said:
Uh, what exactly is a "DSP" and what can we do with it? ^_^
Digital Signal Processor

A DSP is basically a specialized processor, often used for audio/video encoding and decoding. Because they are usually designed around one or two specific functions, they are much simpler and more efficient at those tasks than a general purpose processor.

In the Pandora's case, the TMS320C64x+ DSP will probably be used for real time h.264 playback and other video processing tasks. It could also be used to play back MP3s using much less power than the OMAP CPU - which is where the 100-hour battery rating comes from. There is even the potential to use it for things like sound processing in some emulators, offloading that task from the CPU and improving overall speed and efficiency.


Also I think it'd be really good for emulating video on some platforms, especially 2D. There are some high end 2D systems like PC-FX, Sega Saturn, or Nintendo DS that could probably use the boost. The only difficulty comes in synchronizing the CPU and video emulation like this.
 
Last edited by a moderator:
Exophase said:
Also I think it'd be really good for emulating video on some platforms, especially 2D. There are some high end 2D systems like PC-FX, Sega Saturn, or Nintendo DS that could probably use the boost. The only difficulty comes in synchronizing the CPU and video emulation like this.
How could a DSP whose (alost) only instruction is MultiplyACcumulate (MAC) help in rendering 2D gfx?
MAC could be used for 3d gfx (matrix multiplication).
However, I only know the 56001 (from motorola, which is inside the ATARI Falcon030).

Talking 'bout the Falcon, in this little bird the DSP could be fed with data via DMA and it CAN be connect to the Audio-Subsystem, so you don't have to send the processed audio data back to the CPU and pass it to the audio system via the CPU. Does anyone know how the DSP in the OMAP3 is tied to the system?
 
Last edited by a moderator:
Creature XL said:
How could a DSP whose (alost) only instruction is MultiplyACcumulate (MAC) help in rendering 2D gfx?
MAC could be used for 3d gfx (matrix multiplication).
However, I only know the 56001 (from motorola, which is inside the ATARI Falcon030).

Talking 'bout the Falcon, in this little bird the DSP could be fed with data via DMA and it CAN be connect to the Audio-Subsystem, so you don't have to send the processed audio data back to the CPU and pass it to the audio system via the CPU. Does anyone know how the DSP in the OMAP3 is tied to the system?
You have a lot to learn about the C64x+ DSP. Start with reading my thread here:

http://www.gp32x.de/board/index.php?showtopic=40888&hl=
 
Last edited by a moderator:
Exophase said:
You have a lot to learn about the C64x+ DSP. Start with reading my thread here:

http://www.gp32x.de/board/index.php?showtopic=40888&hl=



Thanks for the link.
I must have missed that topic (I am not for too long in the dev part of the pandora forum). I just scrolled the thread down (slowly) and I am impressed :) I will have a closer look to that thread at the WE.
 
Last edited by a moderator:
Chip said:
Digital Signal Processor

A DSP is basically a specialized processor, often used for audio/video encoding and decoding. Because they are usually designed around one or two specific functions, they are much simpler and more efficient at those tasks than a general purpose processor.

In the Pandora's case, the TMS320C64x+ DSP will probably be used for real time h.264 playback and other video processing tasks. It could also be used to play back MP3s using much less power than the OMAP CPU - which is where the 100-hour battery rating comes from. There is even the potential to use it for things like sound processing in some emulators, offloading that task from the CPU and improving overall speed and efficiency.



Ah, so the DSP is the Co-Processor and in our GP2X this is the 2. CPU, makes Sense. :) I hope the access onto the Pandora will be more easy than using the 2. GP2X Processor. ^_^
 
Last edited by a moderator:
fusion_power said:
Ah, so the DSP is the Co-Processor and in our GP2X this is the 2. CPU, makes Sense. :) I hope the access onto the Pandora will be more easy than using the 2. GP2X Processor. ^_^
Sort of. In the GP2X the 2nd processor was still a general purpose CPU. A DSP is highly specialized and can only be used for certain things. However, the things is does do, it does really well.
 
Last edited by a moderator:
so you might say we have made a trade off (compared to teh GP2X) ... we can't use the DSP for general purpose code.... but we gain a highly optimised media processor that we probably wouldn't be able to duplicate (or do as efficiently) with 2 Cortex-A8 's

if devs actually use it seems like a pretty good trade off to me
 
So I imagine you'll be using the dspbridge code from Ti then?

Audio output is performed directly from the DSP on the Nokia N8x0/770 (the audio codec is attached directly to the DSP), presumably the same will be true of the Pandora.

Video output from the DSP is more troublesome (read slow) on the N8x0, as the framebuffer is held in slow SDRAM (and it must then be copied to the LCD controller). I imagine things may be different with the Pandora. On the 770 the DSP is used to do video decoding, but on the N8x0 the ARM is used (my understanding is that this is because it has greater throughput).

Regarding speeding up 2/3D graphics, is this not what the PowerVR should be doing? Or do these platforms have funny quirks that would need DSP-like processing before being rendered?
 
Back
Top