Adaptive Filter | ADPCM | ADSP | ADSP-2181 | Aliasing | AMR | Anti-Aliasing | ARMA | Autocorrelation | AutoCovariance | Beamforming | Bessel | Blackfin | Butterworth | C6713 | CCS | Chebyshev | CIC Filter | Circular Convolution | Code Composer Studio | Comb Filter | Compression | Convolution | Cross Correlation | DCT | Decimation | Deconvolution | Demodulation | DM642 | DSP Boards | DSP/BIOS | DTMF | Echo Cancellation | Equalization | Equalizer | ETSI | EZLITE (Ez-kit Lite) | FFT | FFTW | FIR Filter | Fixed Point | FSK | G.711 | G.723 | G.729 | Gaussian Noise | Goertzel | GPIO | Hilbert Transform | IFFT | IIR Filter | Interpolation | Invariance | JTAG | Kalman | Laplace Transform | Levinson | LPC | McBSP | MIPS | Modulation | MPEG | Multirate | Notch Filter | Nyquist | OFDM | Oversampling | Pink Noise | Pitch | PLL | Polyphase | QAM | QDMA | Quantization | Quantizer | Radar | Random Noise | Reed Solomon | Remez | Resampling | RTDX | Sampling | Sharc | TI C6711 | Undersampling | Viterbi | Wavelets | White Noise | Wiener Filter | Windowing | XDS510PP | Z Transform

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

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

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

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

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

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

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
> 

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

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.

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Brad,

Thanks for the explanation. I want to understand the relationship
between the framework components and CSL. I  will start a separate
thread on that topic.

Regards,

Eknath

> ... 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.

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Thank you.


Mark Robinson wrote:

>
> 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.

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.