Post Go back to editing

TDM 4 mode on ADAU1361: paralleling multiple devices

In the TDM4 mode, does the ADC_DATA pin on the ADAU1361 go tri-state during TDM slots in which it is not programmed to respond?

I want to parallel multiple codecs on the same serial port lines.  If the digital outputs don't go high-impedence during other slots, the outputs will conflict.

Optional bonus point question: Is there an equivalent to the ADAU1361 that will do multiple channels?  I'm looking for 4-8 channels of single-ended line input and differential line output.  SPI control is a must.

  • While I'm at it, can someone please explain the ADPAIR and DAPAIR serial data selection bitfields for TDM4? The description talks about selecting a "first pair, second pair, third pair, or fourth pair", yet a stereo signal should take TWO slots, not one slot.  It seems that there should be a slot selection for the left stereo side and a slot selection for the right stereo side.  For both the ADC and for the DAC.

    As I read this, I should be able to parallel two of these devices on common serial port I/O pins, and specify the slots times as 1L, 1R, 2L, 2R for a total of 4 slots.

    Correspondingly, BPF should be set at 011 for 128 bits, since 4*32=128bits.  Why is there no option for 4*24 = 96bits in setting BPF?

    Thanks.

  • Hello,

    Unfortunately, I don't think the ADAU1361 is going to work in your intended use case because there are some missing features and design quirks that make it impossible to put two of these devices in parallel operating on the same TDM stream.

    First, and most importantly, the ADAU1361 does not have a "three-state on idle channels" option, so the serial port will simply drive out zeros on inactive channels. This means that, unfortunately, you won't be able to run two of these in parallel and have them share the same TDM line.

    Of course, since it is useful from an applications perspective to have three-state logic on the serial data lines (as opposed to the ADAU1361's two-state implementation), that feature has been included in all of the new designs for our next generation of codecs and SigmaDSPs.

    The routing of data channels on the TDM stream is a little bit non-intuitive (this is another problem that has been addressed in our newer designs). In two channel mode, the order of the channels on the serial data lines will be as follows:

    ADC_SDATA: ADC0, ADC1

    DAC_SDATA: DAC0, DAC1

    This, of course, makes sense.

    However, in TDM4 mode, the channel routing is like this:

    ADC_SDATA: ADC0, Inactive channel, ADC1, Inactive channel

    DAC_SDATA: DAC0, Inactive channel, DAC1, Inactive channel

    This deviates from the "standard", which would look more like this:

    ADC_SDATA:ADC0, ADC1, Inactive channel, Inactive channel

    or

    DAC_SDATA:DAC0, DAC1, Inactive channel, Inactive channel

    The difference between the "first pair" and "second pair" in TDM4 mode can be summed up like this: the "first pair" mode corresponds to the channel mapping I described above, whereas the "second pair" mode looks like this:

    ADC_SDATA: Inactive channel, ADC0, Inactive channel, ADC1

    DAC_SDATA: Inactive channel, DAC0, Inactive channel, DAC1

    You can see that basically the position of the data channels and the inactive channels are swapped.

    The "third pair" and "fourth pair" settings only apply to the TDM8 mode of the ADAU1761, which is the "sister" of the ADAU1361, basically pin-compatible and register-compatible but with an included SigmaDSP core. They are not valid in the ADAU1361, and if you use either of those settings, you will simply see no data passing through the serial ports.

    Regarding your question on bits per frame... the options available in the register settings were basically selected after analyzing the market and seeing what kinds of settings were required by customers. It was deemed that in most I2S streams, common applications either use:

    • 24-bit data per channel / 32-BCLK cycles per channel, or...
    • 16-bit data per channel / 16-BCLK cycles per channel.

    I wasn't part of the design team, but I imagine that the 24-bit data per channel / 24-BCLK cycles per channel option was not included simply because there was no market demand for that operating mode. Please let me know if the 24/24 mode is something you'd like to use, and I will provide that as feedback to the design team.

    I hope this answers your questions.

  • Thanks for your excellent respnse, Brett.  I suppose that I could abandon TDM mode and apply some external selection logic to parallel them.  Which would take up more board space and design time.

    I saw something in the data sheet implying that the bit clock must be in sync with the master clock.  Does this mean same frequency?  Obviously, I won't be taking in data faster than the sample rate, but can't I run the serial port as fast as possible?

    "If the PLL of the ADAU1361 is not used, the serial data clocks must be synchronous with the ADAU1361 master clock input. "


    Optional bonus point question: Is there an equivalent to the ADAU1361 that will do multiple channels, or one that will allow parallel connection?  I'm looking for 4-8 channels of single-ended line input and differential line output.  SPI control is a must.  The extremely low power consumption is also very important.  I suppose that I could even separate the ADC from the DAC functions on different devices, if they were parallel-able on the serial port.

  • Hello,

    Brett is right about the ADAU1361. However, I suggest you look into the AD1939. It has  4 ADCs and 8 DACs and is SPI controlled. As a bonus it also supports some highly flexible TDM modes where you can daisy-chain TDM streams from other Codecs or add the I2S data from  an external ADC into the TDM stream out of the AD1939.

    The only issue which may or may not be important to you is that the ADC is differential. So feeding it with a single-ended signal will not allow you to drive it to 0dBFS. Therefore you will lose 6db in the dynamic range specification. Here is a link to the product page:

    http://www.analog.com/en/audiovideo-products/audio-codecs/ad1939/products/product.html

    Have a look and see if this might work for you. 

  • Thanks for your quick suggestion, Dave.

    I like the simplicity of the AD1939 (what happened to the "AU").  However, I really liked the options to power down individual DACs, and put the analog amps into extreme low power (low GBW, I suppose) mode, as in the (battery-powerable) ADAU1361. 

    On the AD1939, I see one control bit for powering down all DACs together, though I'd like to power down just 3 out of the 8 permanently.  Then there is one control bit for powering down the analog amps.  Though even that still takes 23 milliamps out of the analog supply, if I read that correctly. 

    Any other options?

  • The ADAU1772 might be a good solution to this problem. It has 4 ADCs and 2 DACs, extremely low power consumption, and it does tri-state TDM channels that aren't in use, so you could definitely use 2 ADAU1772s in parallel with each other to create a single TDM stream.

    http://www.analog.com/en/audiovideo-products/audio-signal-processors/adau1772/products/product.html

  • Thanks, Brett.

    Thanks, Brett,

    Pros: Very nice product, looks like TDM8 with tristate is supported, and it keeps the power consumption low. 

    Cons: I don't think that I need the SHARC core, the price is almost double, and the package size has increased.

    Questions: 

    You say dual devices will work in parallel, can I assume that 3-4 devices will also work in parallel in TDM8 mode?

    I understand that delta-sigma codecs developed for audio applications can (usually) work for DC in/out applications (which I require) but perhaps with some reduced performance or drift at zero frequency, compared to data converter ADCs and DACs.  Am I correct?  I can handle some drift, though I can't find specs for DC operation in your codecs.  Can you give me some qualitative indication of this?

  • Because the individual TDM channels can be tristate when they are not active, multiple ADAU1772 serial ports can be connected on the same data line. Of course, all of the parts must be running from the same LRCLK and BCLK timing. One of the parts must be master while the others are slave, or an external clock source can be master to all of the ADAU1772 running in slave mode.

    Sigma-Delta ADCs can operate as DC sensors, however we do not characterize them for either performance or drift; as audio parts, these are not specs that are critical for audio performance. We have run lab tests to confirm functionality in similar designs, the results suggest 10-bit resolution. What level of performance do you require for your application?

  • Thankks, Coleman.  Gotcha on the paralleling.  Looks like standard multiplexing techniques.

    On the DC performance requirement:  I figure that equivalent noise to 10 bits of resolution on the ADC side is sufficient.  Drift should also be less than or around 10 bits of resolution (0.1% over 1000 Hz bandwidth) during a 15 minute interval, for both the DAC and ADC.  Temperature changes on the device should be minimal: less than 5 degrees C during any 15 minute span.

    However, for the DAC side, I'd like to see noise at or below the 16 bit resolution level.

    If it's any help, I only need about 1000 samples per second.

    Are these specs restrictive?

  • We would have to make some measurements on this specific part to be sure about both the ADC and DAC resolution. Your sample rate of 1000 samples per second is also below our rated minimum of 8 kHz, but with the PLL turned off, this should not be a problem.

    There is no SHARC onboard, the ADAU1772 has a limited function SigmaDSP core which can be turned off.