C6713B DMA HPI interaction

John,

Sounds like you would need to set up something like a mailbox system between the serial port activity and HPI activity.  The HPI module includes DSPINT and HINT signals that can be used to indicate when data is ready to be read or written.

-Tommy

Thanks for the reply. 

In my system, AES/ EBU audio enters a serial port that is linked to the EDMA. It's set up to do a typical ping- pong buffer scheme.  When the DMA cycle is complete, I fetch the available buffer.  Opposite on the way out.  The theory is, and correct me if I'm wrong.  An HPI transfer from the host uses the EDMA too. Moreover, at a higher priority, so it is possible to interrupt the audio DMA and loose samples.   Seems impossible but that is what I am led to believe.   

In an experiment, I eliminated the host communication and there are no longer errors, so the theory seems to hold out in practice. 

If all this makes sense, at what point can I allow HPI access? 

John,

The priority can be set in the PaRAM table.  If the audio transfer is at a lower priority, it is possible for the HPI requests to preempt the audio transfer requests.

Also keep in mind that data transfer requests are not always atomic.  When passing through the EDMA, data requests can be split up into bursts which are then subject to arbitration.

I think the best way to handle this is to use HINT and DSPINT signals when buffer data is ready.  Or perhaps setup additional buffering to give the system more slack.

-Tommy

Thanks Tommy,

Can you cite a reference for PaRAM table in 6713b documentation? Perhaps I'm missing something.

Are you saying it is best to control host communication so transfers through HPI occur at the end of a DMA cycle (while DMA is busy with next buffer)?

John

I verified the DMA channel is set to high priority. 

By eliminating host communication can confirm it is HPI access that is causing the audio error.  HPI is fixed at high priority.

Still need to know:

With double buffering via serial port, when is it safe to allow HPI communication in a 6713B?  I would rather not loose audio samples. 

BTW:  HPI is evil.

Hi John

I have not picked up on the details in this thread yet, but I hope you are aware of the EDMA Architecture application note on the c671x?

http://focus.ti.com/lit/an/spra996/spra996.pdf

Regards

Mukul

Thanks I'll take a look.

John,

Assuming that you are using EDMA to service the serial port, you can configure EDMA to trigger a CPU completion interrupt.  When the CPU services this completion interrupt, it can assert an interrupt to the HPI host letting it know that one buffer is complete.

Also, if the CPU is touching any of the audio data, you may have extra interconnect traffic attributed to the CPU cache trying to maintain coherency.  If the audio data resides in external memory, it could experience cache corruption.

-Tommy

Guess what I'm missing is, in the ISR for the EDMA, what action do I take with the host?  You recommend letting the host know one buffer is complete.  Do I suspend hpi communication at this time? 

BTW: Edma audio buffers are handled in internal memory.  I understand there should be no cache coherency issue with this arrangement. 

John,

This depends on the architecture of your system.  Since the activity is asynchronous, you will probably need some form of handshaking to let each party know when data is ready to be processed.

The HPI module includes interrupt signals for DSP->HOST and HOST->DSP.  If these interrupts do not meet your needs, you can also use GPIO signals.

For example, when EDMA finishes moving data from serial port to memory, it can assert a signal (HINT or GPIO) to the host letting it know that it can read out audio data.  Upon receiving this signal, the host should read the data ASAP and ideally signal the DSP back letting it know that the data was read successfully (DSPINT or GPIO).

The L2 memory controller should keep the memory coherent.

-Tommy