This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

C6726B dMAX FIFO mode

I am using a C6726B DSP chip in an audio application.  I use the McASP
peripheral (in slave mode) to receive 2  8-slot TDM streams on 2
serializer pins.

The audio sample rate is 48 KHz, which generates DMA events every
2.604 uS to the hi-priority dMAX channel.  The dMAX engine is
currently depositing data into a 3D ping-pong buffer in Internal RAM.
The dMAX engine is clocked at 125 MHz.

I am looking into the feasibility of changing the input architecture
so that the dMAX engine deposits audio samples into a FIFO that resides
in External RAM (SDRAM).  The SDRAM uses CL=2, and clocks at 125 MHz.

My questions at the moment are:
1. What percentage of dMAX capacity will be consumed by this TDM stream?
Your dMAX performance spreadsheet does not provide a calculation
scenario for this configuration.

2. If the hi-priority dMAX channel is using a FIFO for receiving audio
samples from McASP (a FIFO write), can I use the low-priority dMAX
channel to transfer data from that FIFO into Internal RAM (FIFO read)?
I.e. can the hi-priority FIFO channel and the low-priority FIFO channel
share the same FIFO descriptor, without corrupting the descriptor's
contents?  The DMA request events would be asynchronous to each other.

3. If the hi-priority dMAX channel is set for a quantum size of 4
elements, and there are 2 McASP serializers to read for each DMA event,
then are other hi-priority DMA transfers locked out during the period
where the 2 McASP serializers are being read by dMAX?

4. If the hi-priority dMAX channel is set for a quantum size of 1, and
McASP generates a DMA request event (with 2 serializers to read), what
will dMAX do in that case - will it only read one of the 2 serializers
in response to a TDM slot DMA event?

5. Would a hi-priority dMAX 'quantum in progress' lock out the low-
priority dMAX engine from reading that same FIFO during the period
where the hi-priority dMAX engine is reading data from the 2 McASP
serializers?

  • Dear TI Support,

    It is now July 21st.  I first submitted these questions on July 11th.  I have not received a reply yet.

    Can you please look into these issues, and get me the answers?

    Thanks,

    Steve Tuttle

  • Steve.

    In the past two weeks while you have been waiting for a response, have you tried coding up these scenarios and trying to evaluate the performance? What results have you found, if so?

    It is not clear to me how anyone will be able to answer your questions without building these scenarios and trying them. I do not have the facilities for that, and it would appear that no one else has been able to do it, either. Perhaps some added experience from your work over the past two weeks will gather some feedback based on your observations.

    Regards,
    RandyP

  • Randy,

    While there is some information I can gain by experimentation, I cannot answer the most fundamental question without help from TI support:

    Can the Hi priority dMAX unit and the Lo priority dMAX unit share the same FIFO descriptor without corrupting the descriptor's data?

    Note that both of these dMAX units run asynchronously, and both units will be updating the FIFO descriptor's contents.  Are you telling me that no one at TI can answer that question for me?

    Steve

  • Randy,

    In those 2 weeks, I have built a system that uses dMAX to transfer 2 8-slot TDM streams from McASP into external SDRAM.

    I used the CPU to copy data from the FIFO (in SDRAM) to buffers in internal RAM.  This is not an ideal solution, since I would rather have the CPU doing other processing during that 'copy' time.  The CPU manually updates the 'read pointer' in the FIFO descriptor after a block of samples has been read from the FIFO.

    This seems to be working well, but I would rather have the dMAX unit copying the data from the FIFO into the internal RAM buffers.

    The problem is, if I need to use the hi priority dMAX unit for reading the FIFO, I am going to miss McASP DMA events.  It takes 274 dMAX clocks for the hi priority dMAX unit to service the 2 serializers I am using in McASP, which equates to 2.192uS, given the dMAX clock is running at 125MHz.  TDM/McASP dma events arrive every 2.604uS.  If that hi priority dMAX unit has to compete for bandwidth with a hi priority dMAX transfer from SDRAM (the FIFO read) to internal RAM buffers, then the latency problems will cause some of the McASP dma request events to be lost.

    However, the lo priority dMAX unit can run concurrently with the hi priority unit, and they should only conflict with each other when contending for simultaneous access to the SDRAM resource (the FIFO).  So I could use the hi priority dMAX unit to write data into the FIFO (from McASP), and use the lo priority dMAX unit to read the FIFO and copy data into the internal RAM buffers.

    The catch here is that both the lo priority and hi priority units need to share the same FIFO descriptor.  Both dMAX units will need to update the status flags in the FIFO descriptor.

    How does the dMAX unit update the flags in the descriptor?  Is it some form of read-modify-write operation?  If so, then is there a chance that the hi priority dMAX unit will modify the flags in the FIFO descriptor, while the lo priority unit is in the middle of its own read-modify-write sequence?  Or are these writes to the flags in the descriptor indivisible?

    Steve

  • Still waiting for your reply.

  • Steven,

    TI (and I) should be flattered that you have such high expectations, sending out a reminder after 1/2 day's time. When I jump into a discussion on which I am not the expert, it is my hope that I can at least offer suggestions before or in lieu of any other advice coming in. We try to support products like dMAX with the User's Guide and Wiki topics (in some cases) and the examples that come with the software packages. My experience with dMAX was in support of a customer's project a couple of years ago and I do not recall looking into the use of FIFOs or their descriptor resources, so I cannot help you with your specific question. By replying, I may be hinting to someone else that I do know answers, so I was giving it time to allow someone else to join in.

    Since I have no idea about the FIFO descriptor resource that you are asking about, I will not try to address that. This may be an excellent feature of the dMAX that I am missing out on, but that is the truth.

    The more common way to do what you seem to describe is with two buffers, the well-named ping/pong buffers. It would be appropriate to have the hi priority dMAX dealing with McASP accesses to fill the ping buffer. When it fills ping, it would signal to the DSP and/or the lo priority dMAX that ping is full and ready for processing. And the hi priority dMAX would change its pointers to start accessing the pong buffer. The same would happen when pong is full, and the hi priority side switches back to ping while the lo priority side accesses pong.

    When the ping buffer is filled, the lo priority dMAX is started for whatever size sub-buffer you want to work with. This could be the whole ping buffer, but most likely a portion of it, such as 1/8th for example. When all of the ping buffer has been used, the lo priority dMAX would then change or load a new set of pointers so it will start accessing the pong side for the DSP to consume.

    The FIFO method may be better for your system, but if it requires two independent functional units to access the same resource control points, you can expect problems. That does not seem like a smart way for us to design a system for capturing data and consuming that data, so I have to think there is either a protected way to do what you want to do or another way to do what you want to do. I have suggested another way, for what it is worth.

    If this has not been helpful, then I apologize and will wait for an expert to join in. If that is the case, you are welcome to post another "knock, knock" post with a link back to here, and tell them that the guy who replied did not have the expertise you still need.

    Regards,
    RandyP

  • Randy,

    Thanks for sending me a reply.  Forgive my impatience - but I have been waiting over 2 weeks.  It is OK in an academic setting to wait for 'some other expert' to make a contribution to a discussion.  But I am in a business setting, and I have a schedule to meet.  This is not an academic exercise for me.

    The FIFO mode of dMAX offers me advantages over a ping-pong buffer scheme.  I can see how one could 'sort of' simulate the larger set of buffers the FIFO mode offers, by using a large ping buffer and a large pong buffer, and using dMAX to transfer a subset of that data to internal memory for processing, as you have suggested.

    The FIFO method does work better for us, in our application.

    Since you are not familiar with the FIFO mode details, please put me in touch with a TI employee that has the information I need.  The answer to my questions should be readily available to the engineer(s) that designed the dMAX subsystem.

    Steve

  • Steve, sorry for your trouble. Many of the queries you have raised require us to spend significant time to get accurate response. I request you to write to c6swlib_dev@list.ti.com where we can discuss some of the options we have to help you get the information you are requesting

    Cheers,
    Gagan