AnsweredAssumed Answered

ADAU1446 errata, delay on SDATA_IN0 and one clocking question.

Question asked by daniel.hojka on Mar 24, 2017
Latest reply on Mar 27, 2017 by daniel.hojka

Dear AD support,


we're in the middle of evaluating the ADAU1446 as a central part of a multi-DSP, multichannel audio solution. After initial tests with the official EVM, we're currently doing measurements of the ADAU1446 on a self built daughterboard that already fits our systems constraints. While most of the ADAU works as expected, we're having four questions/issues, that we would like to get some information on before we can continue developing with this IC.


Q1: We only found one official errata statement: 


... to the ADAU1446 referring to spdif out in silicon rev 0. Is this information still valid, respectively are there really no other known issues in the current ADAU1446 revisions?


Q2: While doing some research for the official errata, I stumbled upon the following article:


Dejitter issue 


Needless to say I am more than just interested in the attachment that is missing in that posting. Could you please elaborate?


Q3: When using the SDATA_IN0 (Pin 11) in I2S/LJ/RJ/TDM2 mode, the timing of the digital audio passing through the core is not as we expect. The audio data on the left channel is being delayed in time by exactly one sample in respect to all other channels. Using a "walking ones" test signal coming from an APx555 the delay is obvious.


The oscilloscope pic shows the LRCK in yellow, and output SDATA_OUT{0,1,2} in {cyan, magenta, blue}. As the Sigma Studio screenshot shows, this already happens in a pretty minimal configuration.


SDATA_IN0 delays left sample


You can clearly see the (t-1) historical data only on the left sample data on the first of the three I2S data streams. I also attached the routing in Sigma Studio that led to this behaviour (sorry for the heavy moiré):



It might help to know we're using three synchronous I2S streams per DSP going into the ADAU using SDATA_IN{0,1,2} and routing them out via SDATA_OUT{0,1,2} using Sigma Studio. Clocking is done by BCLK{3,4} and LRCK{3,4} for {IN,OUT}, a quick picture of the the clock setting in Sigma Studio:



As you can see, all ports are in slave mode receiving the clocks from external clock buffers. Also, we're seeing this issue on two datecodes of the ADAU1446 (#1514 and #1434).


During double checking our testbed, we had to find out that when we just swap the input from SDATA_IN0 to SDATA_IN3 there is no delay on the left pair of channel SDATA_IN. In other words - when we keep everything like it was and only changing the routing to:



... the ADAUs behaviour results in something we would expect:



Q4: According to the current Rev.D datasheet[1] on page 34 ...


"In a system with no sample rate conversion and with serial ports in slave mode, at least two pairs of LRCLKx and BCLKx pins must be connected: one pair for the input serial ports and one pair for the output serial ports [..]." 


... and ...


"Although a clock domain in slave mode can clock an arbitrary number of serial ports [...]"


... we assumed that we need two pairs of BCLK and LRCK feeding two clock domains when running the ports in slave mode. So we're currently using BCLK3 + LRCK3 (Pin 3 + 4) for the input "clock domain" and BCLK4 + LRCK4 (Pins 96
+ 97) for the "output clock domain". As this is a synchronous design, both BCLK and LRCK inputs are fed by a plain buffered copy with a very low, single digit ns skew (measured)). When selecting _only one_ of these BCLK/LRCK copies in Sigma Studio as clock, audio still passes through as with both clock pairs before. Does this mean we can safely omit one of these clock pairs in the final design? If so, why do you recommend two pairs of LRCLKx and BCLKx pins?



Kind regards,