c67x development concerns

Vic,

Vic Manzella said:

I am currently using a fixed point DSP (TMS320VC5501) with a TI audio codec (TLV320AIC3204) and I need to move to floating point processing.  I am considering members of the ADSP-213xx family because my previous experience with the c6x architecture (over 10 years ago) was not a pleasant one.  I am wondering about a few issues that have me steering clear of c67x family processors (eg. c6748) - which I should at least resolve in the name of due diligence:

Interesting that you are asking TI to explain why our DSP is better than some Brand X part. I am glad you are considering our parts.

Why do you have to move to floating point? The C6748 is definitely the way to go if floating point is a big part of your new code, or something like the C6421 might be a good fit if you can stay with fixed point.

The best due diligence would be to install CCSv5 and test your code on the simulator. It is free and realistic. You can go to the TI Wiki Pages and search on CCSv5 to find information. Be sure to compare the performance between the Debug build configuration and the Release build configuration; big difference.

Vic Manzella said:

1. I do not have time (at least initially) to re-write my C and C++ code to be more suitable for the c67x compiler.  Instead, I prefer to make as much use as possible of C-callable assembly routines, most of which I found in the c55x DSP library.  Besides, this approach should easily beat compiler performance.  Can anyone comment on whether the c67x DSP library is as complete as that for the c55x, and how concerned I should be about bugs?

The main suitability thing I can think of is to make sure any generic variable, like loop counters, are native integers, meaning 32-bits.

"The C67x DSP library" does not tell me what you are looking for. If you mean the Run-Time Support library, it should be the same.

If you find a bug, please tell us. I am not sure what more to say.

Vic Manzella said:

2. I have great concern about the potential headaches of handing over memory management to a caching algorithm.  Currently my code runs entirely from internal DARAM on the c5501.  If I were to try using external SDRAM with the c5501, then it appears that I could finesse a way to freeze externally stored code in the cache after ensuring that all the needed code was cache-resident, but I have not bothered trying this since DARAM was sufficient.  My question regards my concern for the multilevel caching found in the c67x architecture.  If my code and data requirements are minimal, can I build my application such that code and data can remain resident in L2 cache?

Yes, you can put all of your application code and data in L2 and not even put DDR on the board.

Vic Manzella said:

3. Since I have no interest in or need for an RTOS, should I have any concerns about using a simple looping kernel in my "main" C routine, where each loop iteration is kicked off when a full buffer of ADC data (collected by an audio rx ISR) is available?

You can definitely write your code that way, and expect it to work just as well as it did on the C5501.

Vic Manzella said:

4. Is there a good document detailing the code security options that are available?

You will want to start with the datasheet to find out what features are available. Then from the Product Folder, such as TMS320C6748, you can find User Guides and Application Notes to help explain more detail about those features. "secure boot" is the phrase to start searching on.

Vic Manzella said:

5. Would my interfacing with the 3204 be more complicated using the c67x? This does not appear to be the case with what I have seen so far.  Currently, with the c5501 we have McBSP0 talking to a SPI flash for bootstrap, McBSP1 interfaced for Tx and Rx with the 3204, and I2C for controlling the 3204.  This all looks feasible with the c6748.  Is DMA recommended versus Tx and Rx ISRs as we currently use on the c5501 (at 192kHz)?

There are a bunch of peripherals on the C6748.

A big part of the power of these C674x devices is the EDMA3 module. Depending on your algorithm requirements, you can save a lot of ISR MIPS by letting the DMA take care of the I/O, and let the DSP do its processing. But if you are just sitting in a polling loop waiting for a new sample, then you will go process that one sample, then start polling again, EDMA3 will not help you much. In fact, in that architecture, you should skip the ISR and just poll for the McBSP to have some data ready.

But if you are capturing a certain amount of data, then processing on a buffer of data, EDMA3 will be a very big help.

Regards,
RandyP

Randy,

Thanks for the input.  The DSP "library" I refer to is the collection of usual suspects (C-callable assembly functions): FIR filters, IIR filters, FFT, basic adaptive filters, and standard math functions (sin, atan, expn, logn, etc.).  These are easy enough to write/modify for c54x and c55x architectures (and competing floating point parts such as ADSP-213xx).  However, my first c6x experience found some of these functions to be nearly suited to my needs but exceedingly labor intensive to modify (this is the "previous experience" to which I alluded earlier).  I think I see a more extensive library available now, but I have not used it and need to know how mature this software is for the c67x family.  Also, in reviewing the documentation I noted the following paragraph:

"Most DSPLIB functions are interrupt-tolerant but not interruptible. The cycle count formula provided for each function can be used to estimate the number of cycles during which interrupts cannot be taken."

This seems to indicate that using these functions would force me to use DMA to handle audio Tx and Rx interrupts if I use these optimized assembly functions to process frames of audio data.  Is this a reasonable conclusion?

Thanks again,

Vic

RandyP said:

Vic,

I am currently using a fixed point DSP (TMS320VC5501) with a TI audio codec (TLV320AIC3204) and I need to move to floating point processing.  I am considering members of the ADSP-213xx family because my previous experience with the c6x architecture (over 10 years ago) was not a pleasant one.  I am wondering about a few issues that have me steering clear of c67x family processors (eg. c6748) - which I should at least resolve in the name of due diligence:

Interesting that you are asking TI to explain why our DSP is better than some Brand X part. I am glad you are considering our parts.

Why do you have to move to floating point? The C6748 is definitely the way to go if floating point is a big part of your new code, or something like the C6421 might be a good fit if you can stay with fixed point.

The best due diligence would be to install CCSv5 and test your code on the simulator. It is free and realistic. You can go to the TI Wiki Pages and search on CCSv5 to find information. Be sure to compare the performance between the Debug build configuration and the Release build configuration; big difference.

Vic Manzella said:

1. I do not have time (at least initially) to re-write my C and C++ code to be more suitable for the c67x compiler.  Instead, I prefer to make as much use as possible of C-callable assembly routines, most of which I found in the c55x DSP library.  Besides, this approach should easily beat compiler performance.  Can anyone comment on whether the c67x DSP library is as complete as that for the c55x, and how concerned I should be about bugs?

The main suitability thing I can think of is to make sure any generic variable, like loop counters, are native integers, meaning 32-bits.

"The C67x DSP library" does not tell me what you are looking for. If you mean the Run-Time Support library, it should be the same.

If you find a bug, please tell us. I am not sure what more to say.

Vic Manzella said:

2. I have great concern about the potential headaches of handing over memory management to a caching algorithm.  Currently my code runs entirely from internal DARAM on the c5501.  If I were to try using external SDRAM with the c5501, then it appears that I could finesse a way to freeze externally stored code in the cache after ensuring that all the needed code was cache-resident, but I have not bothered trying this since DARAM was sufficient.  My question regards my concern for the multilevel caching found in the c67x architecture.  If my code and data requirements are minimal, can I build my application such that code and data can remain resident in L2 cache?

Yes, you can put all of your application code and data in L2 and not even put DDR on the board.

Vic Manzella said:

3. Since I have no interest in or need for an RTOS, should I have any concerns about using a simple looping kernel in my "main" C routine, where each loop iteration is kicked off when a full buffer of ADC data (collected by an audio rx ISR) is available?

You can definitely write your code that way, and expect it to work just as well as it did on the C5501.

Vic Manzella said:

4. Is there a good document detailing the code security options that are available?

You will want to start with the datasheet to find out what features are available. Then from the Product Folder, such as TMS320C6748, you can find User Guides and Application Notes to help explain more detail about those features. "secure boot" is the phrase to start searching on.

Vic Manzella said:

5. Would my interfacing with the 3204 be more complicated using the c67x? This does not appear to be the case with what I have seen so far.  Currently, with the c5501 we have McBSP0 talking to a SPI flash for bootstrap, McBSP1 interfaced for Tx and Rx with the 3204, and I2C for controlling the 3204.  This all looks feasible with the c6748.  Is DMA recommended versus Tx and Rx ISRs as we currently use on the c5501 (at 192kHz)?

There are a bunch of peripherals on the C6748.

A big part of the power of these C674x devices is the EDMA3 module. Depending on your algorithm requirements, you can save a lot of ISR MIPS by letting the DMA take care of the I/O, and let the DSP do its processing. But if you are just sitting in a polling loop waiting for a new sample, then you will go process that one sample, then start polling again, EDMA3 will not help you much. In fact, in that architecture, you should skip the ISR and just poll for the McBSP to have some data ready.

But if you are capturing a certain amount of data, then processing on a buffer of data, EDMA3 will be a very big help.

Regards,
RandyP

[/quote]

Vic,

You are referring to the DSPLIB and its functions. These are mature functions.

Vic Manzella said:

"Most DSPLIB functions are interrupt-tolerant but not interruptible. The cycle count formula provided for each function can be used to estimate the number of cycles during which interrupts cannot be taken."

This seems to indicate that using these functions would force me to use DMA to handle audio Tx and Rx interrupts if I use these optimized assembly functions to process frames of audio data.  Is this a reasonable conclusion?

You should use DMA to handle audio Tx and Rx data transfers with the peripherals. This avoids having to spend DSP MIPS on the simple I/O operations.

Your conclusion assumes a relative timing issue between the number of cycles when the interrupts are disabled in some DSPLIB function compared to the time between I/O events. It is an issue to be considered, of course. DMA helps.

Regards,
RandyP