Prev: Matlab multipath simulator
Next: TMS320F2812 Running application from Flash
From: UglanceIcatch on 11 Nov 2006 14:47
Greetings,

I am seeking general ideas/opinions/guidance on software development
for TI DSP devices, in particular, the newer fixed point devices such
as 6455.

I do both algorithm development and implementation work. Most of my
implementation work has been on simpler devices such as 5600, 96002,
Sharc and 5510. I have been developing code for 6455 for about a month
or so. Most of what I have done so far on 6455 has been porting of key
processing modules that I had previously developed for another device.
Thanks to a better compiler, use of intrinsics and linear assembly,
this work has not been as painful as I had anticipated. Engaging all
functional units (.L, .M, .S, .D x 2) in critical loops is not a
trivial task but it is not impossible.

I am contemplating using DSP BIOS to setup the operating framework. I
am not too worried about the additional processing burden imposed by
the use of BIOS objects.

It looks like the groups within TI (spectron and go dsp ???)
responsible for BIOS and CSS/CSL have stopped communicating with each
other. Previously, there was very little overlap between CSL and BIOS.
Use of BIOS didn't prevent the user from the using CSL and vice versa.
However, may changes have taken place in the recent version of CSL
(3.00.10.02), and BIOS (5.31). CSL seems to have become a bit more
primitive and BIOS doesn't seem to require CSL at all. So, my main
question is can these two coexist in the new world?

I have not been able to get satisfactory answer from my friends (AEs
and FAEs) at TI. You get a different spin from people belonging to BIOS
and CSL groups.

Any thoughts/ideas/guidance on this will be greatly appreciated.

Cheers,

Eknath

From: Brad Griffis on 11 Nov 2006 16:57
UglanceIcatch wrote:
> Greetings,
>
> I am seeking general ideas/opinions/guidance on software development
> for TI DSP devices, in particular, the newer fixed point devices such
> as 6455.
>
> I do both algorithm development and implementation work. Most of my
> implementation work has been on simpler devices such as 5600, 96002,
> Sharc and 5510. I have been developing code for 6455 for about a month
> or so. Most of what I have done so far on 6455 has been porting of key
> processing modules that I had previously developed for another device.
> Thanks to a better compiler, use of intrinsics and linear assembly,
> this work has not been as painful as I had anticipated. Engaging all
> functional units (.L, .M, .S, .D x 2) in critical loops is not a
> trivial task but it is not impossible.
>
> I am contemplating using DSP BIOS to setup the operating framework. I
> am not too worried about the additional processing burden imposed by
> the use of BIOS objects.
>
> It looks like the groups within TI (spectron and go dsp ???)
> responsible for BIOS and CSS/CSL have stopped communicating with each
> other. Previously, there was very little overlap between CSL and BIOS.
> Use of BIOS didn't prevent the user from the using CSL and vice versa.
> However, may changes have taken place in the recent version of CSL
> (3.00.10.02), and BIOS (5.31). CSL seems to have become a bit more
> primitive and BIOS doesn't seem to require CSL at all. So, my main
> question is can these two coexist in the new world?
>
> I have not been able to get satisfactory answer from my friends (AEs
> and FAEs) at TI. You get a different spin from people belonging to BIOS
> and CSL groups.
>
> Any thoughts/ideas/guidance on this will be greatly appreciated.
>
> Cheers,
>
> Eknath
>

CSL 3.x has separated the interrupt code (i.e. what they are now calling
the INTC module) from the rest of the CSL. If you are using BIOS then
you should not using the INTC module as BIOS has its own APIs for
dealing with interrupts (i.e. the HWI module).

I don't see any reason you cannot use both BIOS and CSL. In fact, they
are complimentary. BIOS serves as your RTOS/kernel and CSL is used for
peripheral configuration/control.

Cheers,
Brad
From: UglanceIcatch on 12 Nov 2006 00:06
Brad,

Thanks for the clarification. I have another related question. It has
to do with what TI calls as either DSP algorithm standard or XDAIS. Is
this applicable only to third party software developers? How are IDMA2,
ACPY etc. related to CSL? Is this a layer on top of CSL?

Thanks,

Eknath.


Brad Griffis wrote:
> UglanceIcatch wrote:
> > Greetings,
> >
> > I am seeking general ideas/opinions/guidance on software development
> > for TI DSP devices, in particular, the newer fixed point devices such
> > as 6455.
> >
> > I do both algorithm development and implementation work. Most of my
> > implementation work has been on simpler devices such as 5600, 96002,
> > Sharc and 5510. I have been developing code for 6455 for about a month
> > or so. Most of what I have done so far on 6455 has been porting of key
> > processing modules that I had previously developed for another device.
> > Thanks to a better compiler, use of intrinsics and linear assembly,
> > this work has not been as painful as I had anticipated. Engaging all
> > functional units (.L, .M, .S, .D x 2) in critical loops is not a
> > trivial task but it is not impossible.
> >
> > I am contemplating using DSP BIOS to setup the operating framework. I
> > am not too worried about the additional processing burden imposed by
> > the use of BIOS objects.
> >
> > It looks like the groups within TI (spectron and go dsp ???)
> > responsible for BIOS and CSS/CSL have stopped communicating with each
> > other. Previously, there was very little overlap between CSL and BIOS.
> > Use of BIOS didn't prevent the user from the using CSL and vice versa.
> > However, may changes have taken place in the recent version of CSL
> > (3.00.10.02), and BIOS (5.31). CSL seems to have become a bit more
> > primitive and BIOS doesn't seem to require CSL at all. So, my main
> > question is can these two coexist in the new world?
> >
> > I have not been able to get satisfactory answer from my friends (AEs
> > and FAEs) at TI. You get a different spin from people belonging to BIOS
> > and CSL groups.
> >
> > Any thoughts/ideas/guidance on this will be greatly appreciated.
> >
> > Cheers,
> >
> > Eknath
> >
>
> CSL 3.x has separated the interrupt code (i.e. what they are now calling
> the INTC module) from the rest of the CSL. If you are using BIOS then
> you should not using the INTC module as BIOS has its own APIs for
> dealing with interrupts (i.e. the HWI module).
>
> I don't see any reason you cannot use both BIOS and CSL. In fact, they
> are complimentary. BIOS serves as your RTOS/kernel and CSL is used for
> peripheral configuration/control.
>
> Cheers,
> Brad

From: Brad Griffis on 15 Nov 2006 09:22
Eknath,

I'm afraid I can't answer your question though I will tell you what I know.

TI created xDAIS several years ago as a standard to have a more
structured interface to algorithms. Basically it made good coding
practices into rules. For example, you'd have to tell how much
persistent memory your algorithm needs, how much scratch memory, etc.

Recently TI came up with a specific implementation of xDAIS called xDM
(xDAIS Digital Media). This follows all the xDAIS rules but with
specific APIs and structures intended specifically for voice, audio,
video, and imaging algorithms. This is being used on TI's "DaVinci"
platform. That would include the DM6446/DM6443 and I believe that also
includes the parts they announced yesterday, the DM6431, DM6435, etc.

Now there are also DMAN3, IDMA3, and ACPY. These are part of what TI
calls its "Framework Components". I believe these are intended for use
by xDM/xDAIS algorithms to use for controlling DMA channels. Note that
CSL 3.x does not take care of resource allocation so that needs to be
done by the application. I believe these framework components are in
place for that very reason. I'm not sure if they were built on top of
CSL or not though. You may want to either create a separate post here
or you may have better luck subscribing to one of the DaVinci forums and
asking there. Check out http://linux.davincidsp.com and you can
subscribe to the mailing list.

Brad

UglanceIcatch wrote:
> Brad,
>
> Thanks for the clarification. I have another related question. It has
> to do with what TI calls as either DSP algorithm standard or XDAIS. Is
> this applicable only to third party software developers? How are IDMA2,
> ACPY etc. related to CSL? Is this a layer on top of CSL?
>
> Thanks,
>
> Eknath.
>
>
> Brad Griffis wrote:
>> UglanceIcatch wrote:
>>> Greetings,
>>>
>>> I am seeking general ideas/opinions/guidance on software development
>>> for TI DSP devices, in particular, the newer fixed point devices such
>>> as 6455.
>>>
>>> I do both algorithm development and implementation work. Most of my
>>> implementation work has been on simpler devices such as 5600, 96002,
>>> Sharc and 5510. I have been developing code for 6455 for about a month
>>> or so. Most of what I have done so far on 6455 has been porting of key
>>> processing modules that I had previously developed for another device.
>>> Thanks to a better compiler, use of intrinsics and linear assembly,
>>> this work has not been as painful as I had anticipated. Engaging all
>>> functional units (.L, .M, .S, .D x 2) in critical loops is not a
>>> trivial task but it is not impossible.
>>>
>>> I am contemplating using DSP BIOS to setup the operating framework. I
>>> am not too worried about the additional processing burden imposed by
>>> the use of BIOS objects.
>>>
>>> It looks like the groups within TI (spectron and go dsp ???)
>>> responsible for BIOS and CSS/CSL have stopped communicating with each
>>> other. Previously, there was very little overlap between CSL and BIOS.
>>> Use of BIOS didn't prevent the user from the using CSL and vice versa.
>>> However, may changes have taken place in the recent version of CSL
>>> (3.00.10.02), and BIOS (5.31). CSL seems to have become a bit more
>>> primitive and BIOS doesn't seem to require CSL at all. So, my main
>>> question is can these two coexist in the new world?
>>>
>>> I have not been able to get satisfactory answer from my friends (AEs
>>> and FAEs) at TI. You get a different spin from people belonging to BIOS
>>> and CSL groups.
>>>
>>> Any thoughts/ideas/guidance on this will be greatly appreciated.
>>>
>>> Cheers,
>>>
>>> Eknath
>>>
>> CSL 3.x has separated the interrupt code (i.e. what they are now calling
>> the INTC module) from the rest of the CSL. If you are using BIOS then
>> you should not using the INTC module as BIOS has its own APIs for
>> dealing with interrupts (i.e. the HWI module).
>>
>> I don't see any reason you cannot use both BIOS and CSL. In fact, they
>> are complimentary. BIOS serves as your RTOS/kernel and CSL is used for
>> peripheral configuration/control.
>>
>> Cheers,
>> Brad
>
From: Mark Robinson on 15 Nov 2006 11:58
UglanceIcatch wrote:

> Thanks for the clarification. I have another related question. It has
> to do with what TI calls as either DSP algorithm standard or XDAIS. Is
> this applicable only to third party software developers? How are IDMA2,
> ACPY etc. related to CSL? Is this a layer on top of CSL?

XDAIS essentially comes in two parts. The first is simply a list of
coding standards and rules which, if followed, simplify combining
multiple algorithms into a complete system. The second is a set of
APIs to enable the programmer to comply with the rules.

For example, one rule is that an algorithm must not allocate any memory.
Instead, the algorithm implements an interface that the application
uses to query its memory requirements. The app then allocates the memory
and grants use of it to the algorithm. TI provides an API within the
Reference Frameworks to manage this process (ALGRF/SSCR) which provides
some nice features like allowing different algorithms to share scratch
memory.

Another of the rules is that algorithms must not touch chip resources,
including, for example, DMA. However, TI realised that many algorithms
need to make DMA transfers, so they defined the IDMA (and subsequently
IDMA2) interface to allow algorithms to request and use DMA channels.
ACPY/DMAN are TIs reference implementation of this interface.

Cheers

mark-r

--
Currently sigless.

 |  Next  |  Last
Pages: 1 2
Prev: Matlab multipath simulator
Next: TMS320F2812 Running application from Flash