Post Go back to editing

TDM data and FFT accelerator on ADSP21469

I want to perform FFTs using the 21469 accelerator on block data that I receive from SPORT in the multi-channel configuration.  This means that the data block is channel interleaved. I understand from https://ez.analog.com/message/24289#24289 that the FFT input DMA TCB can be configured as a circular buffer with the modify value set to the number of channels.  In this manner, the DMA will de-interleave the data as it is written into the FFT accelerator's dedicated memory.  This all makes perfect sense at a high level, but the details are tricky and the documentation is sparse.  I have not been able to get this working.  I'm only trying to do 256 sample FFTs, but I thought that the expert code generator's 512 FFT example might help by providing an example on how to use FFT circular DMA to perform FFTs across the vertical columns in a butterfly FFT scheme. But it doesn't make sense to me.  Here are the circular buffer TCBs from the 512 example:

/*TCB for loading 2*N-1 Input data points  cofficients (modifier = 2*H) */

   FFT_VIP_TCB[0]= 0;

   FFT_VIP_TCB[1]= (int)FFT_IP_buff;          //Circular Buffer Base

   FFT_VIP_TCB[2]= 1023;                          //Circular Buffer Length

   FFT_VIP_TCB[3]= 1023;                          //Count

   FFT_VIP_TCB[4]= 64;                              //Modify

   FFT_VIP_TCB[5]= (int)FFT_IP_buff;           //Index

/*TCB for loading 2*N-1 Input data points  cofficients (modifier = 2*H) */

   FFT_VLASTIP_TCB[0]= 0;

   FFT_VLASTIP_TCB[1]= (int)FFT_IP_buff;

   FFT_VLASTIP_TCB[2]= 1024;

   FFT_VLASTIP_TCB[3]= 1;

   FFT_VLASTIP_TCB[4]= 1;

   FFT_VLASTIP_TCB[5]= (int)FFT_IP_buff+1023;

I understand that the circular buffer length needs to be less than the data block size because of the need to shift to the next column/channel after reading in all of the samples in the previous column/channel.  I also understand that this is the reason why you must follow the circular buffer TCB with a second TCB that only reads the very last sample of the last column/channel.  What is confusing is that the 512 FFT is operating on packed complex samples (each sample is real immediately followed by imaginary).  Because the data is complex, I would expect that the circular buffer length would be 2 less than the block size (not 1 less like the example).  Alternatively, I feel like the DMA needs to be transferring 2 samples at a time, so the TCB size should be N-1, not 2N-1 (or 2N-2 as I suggested).  Please somebody help me!!!!

I'm beginning to think that the only way to de-interleave the data via the FFT DMA is to use the unpacked format.  That seems to resolve all of my issues with the TCB set up. I will try this tomorrow.  It seems to me that even though packed data is required for N>256 FFTs, the DMA is actually unpacking the data as it is written into the FFT's dedicated memory.  I may have just answered my own question.

I am also curious about the rules for chaining TCBs together to queue up multiple FFTs with different DMA configurations.  I have had success with batching several ffts using FFT_RPT bit and an single TCB that reads multiple data sets (with a similar TCB on the output).  I have not had much luck chaining multiple TCBs together to define different input and output buffer locations for example.  I assume that this should be possible.  Is there a trick I don't know about?

  • Hi Bryan,

    As you might know that the programming model for small FFT (N<=256) and large FFT (N>256) is different. Since your actual questions are more specific to 256 points FFT, let us first try to focus on them and then we can go back and discuss the TCB related questions you have regarding 512 points FFT.

    To be able to help you suggest a TCB scheme for performing FFTs on multiple interleaved channels, could you please provide the actual format in which you would have your input buffer ? For example, is it something like as mentioned below?

    CH1 sample 1->Real

    CH2 sample 1->Real

    CH3 sample 1->Real

    CH4 sample 1->Real

    CH1 sample 2->Real

    CH2 sample 2->Real

    CH3 sample 2->Real

    CH4 sample 2->Real

    CH1 sample 3->Real

    CH2 sample 3->Real

    CH3 sample 3->Real

    CH4 sample 3->Real

    ......

    ......

    and so on

    Thanks,

    Mitesh

  • Mitesh,

    Thanks for your reply.  It seems that I have this all figured out. My data is in the same form as you suggested in your email.  At least, that is how that data is formatted, given my original SPORT DMA configuration.

    Here are some key things that I have figured out:

    • In the 512 FFT example: FFT_CPACKIN is set, which is consistent with the alternating real/imaginary format that is being supplied to DMA.  But this is NOT how DMA writes the data into the FFT's internal memory.  The TCBs (see first email) end up converting the packed data to unpacked format as it picks off the vertical columns for the butterfly FFT.  So as it turns out, the FFT's operation is really inconsistent with the FFT_CPACKIN flag, which I guess is OK because I think the FFT ignores this flag when in >256 modes.  I believe the CPACK flags really have nothing to do with how the data is presented to FFT DMA, but rather how FFT hardware expects to receive the data from the FFT DMA.  While the FFT_CPACKIN won't effect the operation of the FFT, I think it is incorrect and adds confusion.
    • I can use the same TCB approach to de-interleave TDM data for the 256 FFT (which is what I'm really trying to do).  I think there are 2 different approaches possible.  In my case, I will be using External DMA to perform an "overlap and save" operation, and to move the data from the SPORT buffers, which I have in external RAM, to and internal location for the FFT.  I am using the "internal modify"=2, so that the data will be in packed format for the FFT.  But, the FFT's circular buffer DMA will be unpacking the data as it is de-interleaved and written to the FFT's memory, so the FFT_CPACKIN flag MUST NOT BE SET!  I believe an alternate approach exists.  I could have left the External DMA "internal modifier" set to 1, provided that I put a zeroed imaginary block below the real data.  In this case, the FFT's modify is set equal to the number of channels (in the previous case it was set to 2x the number of channels).  In either case, FFT DMA ends up writing the data to internal FFT memory in unpacked form (real block followed by imaginary block), so the FFT_CPACKIN flag MUST NOT BE SET.
    • TDM as a data storage format seems really inconvenient at first, but it has some big advantages.  It allows you to "stack" several buffers together to grow the number of samples, without breaking compatibility with the FFT.  Had the data been organized by sample, rather than channel, it would not be possible to grow the number of samples without forcing a major data reshuffle.

    Bryan

  • Hi Bryan,

    Please see my replies below.

    Bryan Althouse wrote:

    Mitesh,

    Thanks for your reply.  It seems that I have this all figured out. My data is in the same form as you suggested in your email.  At least, that is how that data is formatted, given my original SPORT DMA configuration.

    Here are some key things that I have figured out:

    • In the 512 FFT example: FFT_CPACKIN is set, which is consistent with the alternating real/imaginary format that is being supplied to DMA.  But this is NOT how DMA writes the data into the FFT's internal memory.  The TCBs (see first email) end up converting the packed data to unpacked format as it picks off the vertical columns for the butterfly FFT.  So as it turns out, the FFT's operation is really inconsistent with the FFT_CPACKIN flag, which I guess is OK because I think the FFT ignores this flag when in >256 modes.  I believe the CPACK flags really have nothing to do with how the data is presented to FFT DMA, but rather how FFT hardware expects to receive the data from the FFT DMA.  While the FFT_CPACKIN won't effect the operation of the FFT, I think it is incorrect and adds confusion.

             Mitesh>> I understand your point and agree with you here. Indeed, for N>256 points, the            packing bit is ignored and there is a strict programming and data storage model which needs to be followed to allow accelerator to calculate the output correctly.

    • I can use the same TCB approach to de-interleave TDM data for the 256 FFT (which is what I'm really trying to do).  I think there are 2 different approaches possible.  In my case, I will be using External DMA to perform an "overlap and save" operation, and to move the data from the SPORT buffers, which I have in external RAM, to and internal location for the FFT.  I am using the "internal modify"=2, so that the data will be in packed format for the FFT.  But, the FFT's circular buffer DMA will be unpacking the data as it is de-interleaved and written to the FFT's memory, so the FFT_CPACKIN flag MUST NOT BE SET!  I believe an alternate approach exists.  I could have left the External DMA "internal modifier" set to 1, provided that I put a zeroed imaginary block below the real data.  In this case, the FFT's modify is set equal to the number of channels (in the previous case it was set to 2x the number of channels).  In either case, FFT DMA ends up writing the data to internal FFT memory in unpacked form (real block followed by imaginary block), so the FFT_CPACKIN flag MUST NOT BE SET.

            Mitesh>> I understand and agree with you again. The problem here is that we don't have a two dimensional DMA which can support two types of modifiers and that's the reason of this limitation. 

    • TDM as a data storage format seems really inconvenient at first, but it has some big advantages.  It allows you to "stack" several buffers together to grow the number of samples, without breaking compatibility with the FFT.  Had the data been organized by sample, rather than channel, it would not be possible to grow the number of samples without forcing a major data reshuffle.

             Mitesh>>Understand your point.

    Bryan

    Thanks,

    Mitesh

  • This question has been assumed as answered either offline via email or with a multi-part answer. This question has now been closed out. If you have an inquiry related to this topic please post a new question in the applicable product forum.

    Thank you,
    EZ Admin