ADAU1761 TDMA clocking

The BCLK frequency can be increased independently of the LRCLK, depending on how many channels of data you are transmitting. However, there are certain restrictions. Could you provide a little more detail about what you're trying to accomplish? With more information, I can provide a more detailed answer.

Hi Bret,

Thank you for getting back to me.

Our system is composed of the following paths:

Analog input to a codec -then to the SigmaDSP for processing- then out on a TDM slot

Digital input on all eight of the TDM slots - then to the SigmaDSP for processing-then out to analog via one of the DACs.

Out sampling rate is 8KHz, with 16 bit resolution.

In the data sheet it seems that 32 clock are required for each slot, we will save the upper 16 bits for the application.

In order to do all of the processing for the entire system, we would like to get the TDM stream in and out as quickly as possible so as to allow time for other processing before the next sample time.

Towards that end we would like to clock the BCLK at ~ 5-10 MHz (commensurate with setup times etc.), so that TDM transfer is completed with adequate time left over before the next sample period.

Any further comment would be appreciated.

Regards,

Fred

From: BrettG analog@sgaur.hosted.jivesoftware.com

Sent: Tuesday, September 06, 2011 12:22 PM

To: Fred Pulver

Subject: New message: "ADAU1761 TDMA clocking"

<https://ez.analog.com/index.jspa>; Analog Devices EngineerZone

ADAU1761 TDMA clocking

reply from BrettG <https://ez.analog.com/people/BrettG>; in SigmaDSP Processors - View the full discussion <https://ez.analog.com/message/31717#31717

Hi Fred,

There are still a few things I'm confused about. Could you please clarify?

fredp wrote:

In the data sheet it seems that 32 clock are required for each slot, we will save the upper 16 bits for the application.

Does this mean your applications processor wants to use the TDM line as well? Unfortunately, the SDATA pins on the ADAU1761 do not tri-state when they are inactive, so you cannot have another device sharing this bus and outputting data during the ADAU1761's down-time.

fredp wrote:

In order to do all of the processing for the entire system, we would like to get the TDM stream in and out as quickly as possible so as to allow time for other processing before the next sample time.

Is this processing on the SigmaDSP or on the applications processor? The SigmaDSP will not benefit from faster clock rates, as any data that is received in the span of a frame will be ready at the core for processing at the same time (a few frames later) regardless of the time within the frame when it arrived.

fredp wrote:

Towards that end we would like to clock the BCLK at ~ 5-10 MHz (commensurate with setup times etc.), so that TDM transfer is completed with adequate time left over before the next sample period.

As long as the transfer is completed within the span of the frame, this faster clock rate should not make any difference, at least from the SigmaDSP's point of view.

Thanks!

Brett

Hi Brett,

Thank you again for your response.

Please see below, in-line.

"Does this mean your applications processor wants to use the TDM line as well? Unfortunately, the SDATA pins on the ADAU1761 do not tri-state when they are inactive, so you cannot have another device sharing this bus and outputting data during the ADAU1761's down-time."

The processor will have a dedicated port to the TDM line.

"Is this processing on the SigmaDSP or on the applications processor? The SigmaDSP will not benefit from faster clock rates, as any data that is received in the span of a frame will be ready at the core for processing at the same time (a few frames later) regardless of the time within the frame when it arrived."

We want to complete the transfer faster so that the application processor can address other tasks. I realize that, depending on the extent of processing, there will be frames of delay before the SigmaDSP completes its tasks.

"As long as the transfer is completed within the span of the frame, this faster clock rate should not make any difference, at least from the SigmaDSP's point of view."

Thats is what I hoped your answer would be.

Regards,

Fred

Hi Fred,

I have a few disclaimers.

First of all, I've never actually tried this, because all of the audio sources/sinks that we use in our labs and evaluation equipment (Audio Precision, etc...), as well as all customer designs I have worked with, stick to the 32 BCLK per channel scheme and their clocks are synchronous to the sample rate, aligning perfectly to what the ADAU1761 expects.

That being said, I believe that the design of the serial ports is such that they are simply latching data in on clock edges, not necessarily depending on everything being synchronous.

The first half of the TDM frame (in 50% duty cycle LRCLK mode) relies simply on the BCLK counter. Data will be read in on the appropriate BCLK edge, with the settings of the "Data Delay by X BCLKs" and "BCLK Cycles per Channel" registers being taken into account by that counter. However, the second half of the frame definitely aligns with the LRCLK edge (in other words, I believe that counter resets to 0 half way through the frame), so you need to make sure that yours does as well.

So, I think this might work, but it definitely was not designed to operate in this mode. With no sample rate converters on this chip, it was only designed to operate with nice, synchronous clocks, exactly as described in the datasheet, so I hesitate to make any guarantees. Is this something that you're easily able to try out on your system?

Hi Brett,

Thank you for the further analysis.

I had planned on using LRCLK in the pulse mode to avoid the 50% point, althgough this may just be wishful thinking.

The start of the 256 BCLKs will always be synchronous with the LRCLK frame, as per the data sheet timing diagram, however the 256 periods would end sooner. If the system doesnt quite work like a shift register clocked at an indepoendent rate, we will use the entire sampling perios for the 256 clocks, and do the other microprocessor chores on an interrupt bassis.

I am in the schematic stage, and do not as yet have hardware. I will let you know if this works out when I have a board running. We will initially create the filled TDM stream with data from the ADAU144x /ADAU1442 eval board that we have, send it to the system micro, then re clock it into out target board.

Regards,

Fred

This question has been closed by the EZ team and is assumed answered.