Post Go back to editing

Output delay and other timing specs of ADAU146x audio serial ports (and SPI)

Category: Datasheet/Specs
Product Number: ADAU1462

Hi,

I'm trying to cross-check the timings of various high-speed signals (SPI and audio TDM) between chips that are interfaced on our board, specifically the ADAU146x, AD2428, and our host SoC (TI AM3358), and I'm running into the issue that some of the timings in the ADAU1462 datasheet don't really make sense to me.

The biggest problem is that unexpectedly high values are specified for max data output delay from clock input, for both SPI:

and audio serial ports:

Contrary to the assurance given in the commentary, an output delay in excess of 20 ns (let alone 35) would preclude communication at the highest supported data rate (BCLK = 24.576 MHz) regardless of signal integrity, and it can't really be more than 10-15 ns to have a realistic expectation of being able to achieve reliable communication at that data rate in practice. In reality it does work just fine and we've measured the output delay to be about 5ns, nowhere near the datasheet value.

Similarly, if that 39 ns output delay for SPI MOSI were true you'd need to limit the SPI clock frequency to 8-12 MHz or so (depending on the host's setup time requirements), far less than the 20 MHz specified to be supported. In reality we've been running it at 16 MHz without problems in another product of ours and on the scope we see a mere 7-8ns output delay, which is indeed fine for 20 MHz.

Are these just erroneous values, or am I missing something here?

This isn't the only problem with the audio serial port timing specs of the ADAU1462, for example this setup time would in practice also prevent operation with a 24.576 MHz BCLK:

and I don't understand why it's given at a particular LRCLK frequency, it makes no sense for this setup time to depend on that.

Also, I have no idea what this is even trying to spec:

and more generally the collection of data-vs-clock timings are confusing and appear to be incomplete. I think it would help to properly separate timing requirements on inputs versus switching characteristics of outputs, and to cover all configuration options would require specifying at least:

  • timing requirements:
    • BCLK_INz/BCLK_OUTz input low time (min) and high time (min). Typically this doesn't depend on BCLK frequency/period.
    • SDATA_INx and LRCLK_INy input setup time (min) to, and hold time (max) from, BCLK_INx output sample-edge (typ rising edge)
    • SDATA_INx and LRCLK_INy input setup time (min) to, and hold time (max) from, BCLK_INz input sample-edge (typ rising edge)
    • LRCLK_OUTy input setup time (min) to, and hold time (max) from, BCLK_OUTx output sample-edge (typ rising edge)
    • LRCLK_OUTy input setup time (min) to, and hold time (max) from, BCLK_OUTz input sample-edge (typ rising edge)
  • switching characteristics:
    • BCLK_INx/BCLK_OUTx output duty cycle (min, max), e.g. specified as 0.5 tBCLK ± some amount of ns. Beware of jitter from clkgen when configured as fractional divider.
    • LRCLK_INx output hold time (min) and delay (max) from BCLK_INx output drive-edge (typ falling edge)
    • LRCLK_INx output hold time (min) and delay (max) from BCLK_INz input drive-edge (typ falling edge)
    • SDATA_OUTx and LRCLK_OUTx output hold time (min) and delay (max) from BCLK_OUTx output drive-edge (typ falling edge)
    • SDATA_OUTx and LRCLK_OUTx output hold time (min) and delay (max) from BCLK_OUTz input drive-edge (typ falling edge)

Here for clarity I've used x = port number, y = LRCLK_IN/OUT pin (if used as input), z = BCLK_IN/OUT pin (if used as input).

The timing diagram also has issues, e.g. tSODS and tSODM are output delay times but in the diagram they're being drawn as input setup times.



trivial typo fix
[edited by: matthijs at 10:22 AM (GMT -5) on 16 Dec 2024]
  • Hello matthijs,

    Your observations are good and I had addressed some of this in the ADAU1452 datasheet revision I made back in 2018. These changes never made it to the ADAU1467/1466 family of parts due to internal organizational issues. These part families are VERY similar so you can use the serial port timing specs between the two families. The tSODS specification is one of the things I added a lot more info. 

    The timing specs you quoted is with the default drive strength which is the weakest setting so it is the slowest setting. The SPI output will be improved with the drive strength but I did not recharacterize that specification. 

    Here are the changes I made:

    Your next set of comments:

    This isn't the only problem with the audio serial port timing specs of the ADAU1462, for example this setup time would in practice also prevent operation with a 24.576 MHz BCLK:

    and I don't understand why it's given at a particular LRCLK frequency, it makes no sense for this setup time to depend on that.

    I recently had to look at this and I think it is because you emailed. I do not fully understand why but this will have to do with the start of the frame. At the start of the frame there are a few extra things that need to be done and this is why usually there is a 1-bclk delay for the serial format to allow more time at the start of the frame for housekeeping internally. 

    I agree, it does not make sense for this to have anything to do with the LRCLK frequency. 

    Next:

    Also, I have no idea what this is even trying to spec:

    This one is trying to define the timing of the signal that is driving the serial port since this is the slave mode. This defines the skew, or difference, in the edge of the BCLK and the edge of the start of the frame. If they are not close enough together the BCLK edge is counted as belonging to the last frame not the new one. Then if it is too far after then it thinks it either missed one or it is the next BCLK edge. This is an important spec. Most devices will output the BCLK and LRCLK edge at the start of the frame rather close together but if the PCB layout is not done well and someone did something like add caps on one of these clock lines and not the other one then the timing will be skewed. 

    Our spec for this as a master is 5ns. 

    For this comment,

    The timing diagram also has issues, e.g. tSODS and tSODM are output delay times but in the diagram they're being drawn as input setup times.


    Here is what is in the datasheet.

    What these timings describe is how late is the change in data is allowed to be after the bit clock changes? As a master or slave, either way, the bit clock changes and that triggers the new data bit to be presented out of the pin. When the BCLK is internally generated it is a lot faster because we do not have to sense the logic level with all the circuitry that the pin pad has which adds delay. So the tSODM is 10ns. For the tSODS we have the pad circuitry to sense the level then transmit it internally to change the data to the next bit so that takes longer. However, you can see by my addition of the drive strength settings to the datasheet it shows that you can make this be really fast if needed.

     I hope this helps. 

    Dave T

  • Your observations are good and I had addressed some of this in the ADAU1452 datasheet revision I made back in 2018. These changes never made it to the ADAU1467/1466 family of parts due to internal organizational issues.

    Ah, I see. Well, if you do eventually get around to updating the ADAU146x datasheets, I also reported a datasheet error in this thread where Ken.M confirmed it and said he was "working on updating the data sheet, but it will be a while before the revision is complete as there are a number of errors", but that was 5 years ago so I'm starting to suspect he's not working on it anymore. ;-)

    The timing specs you quoted is with the default drive strength which is the weakest setting so it is the slowest setting. The SPI output will be improved with the drive strength but I did not recharacterize that specification. 

    Here are the changes I made:

    This still makes no sense to me, was this computed assuming the net is loaded with a ton of capacitance or something? The 5ns output delay I observed (from BCLK_OUT0 input to SDATA_OUT1 output) was with default I/O settings (slew rate 2, drive strength 0), and both clock and data nets have significant size and are branched, i.e. definitely not a best case scenario for signal integrity.

    Even if I configure all BCLK/LRCLK/SDATA pins to the slowest I/O settings (slew rate 0, drive strength 0), the AD2428 still receives the data from the ADAU1462 without any bit errors at 24.576 MHz (32 bits × 16 slots × 48 kHz).

    At the start of the frame there are a few extra things that need to be done and this is why usually there is a 1-bclk delay for the serial format to allow more time at the start of the frame for housekeeping internally. 

    Well, I²S does that with the idea being that it should allow the port to work without having to configure the number of bits per slot, instead just reacting to LRCLK toggles (which requires LRCLK toggling 1 bclk delay in advance since it's is not actually a clock but just a control signal that's sampled synchronously to BCLK just like the data, I²S actually calls this signal "Word Select" (WS)).

    However other TDM formats typically don't bother with this 1 bit delay since the exact frame format typically needs to be configured anyway so the audio serial port knows exactly when the next frame starts (after it has seen its first frame sync). Regardless, this has nothing to do with the setup time of an LRCLK input to its BCLK sample-edge.

    This one is trying to define the timing of the signal that is driving the serial port since this is the slave mode.

    But it's saying LRCLK and BCLK are outputs, which by definition means the port is master.

    This defines the skew, or difference, in the edge of the BCLK and the edge of the start of the frame. If they are not close enough together the BCLK edge is counted as belonging to the last frame not the new one. Then if it is too far after then it thinks it either missed one or it is the next BCLK edge. This is an important spec. Most devices will output the BCLK and LRCLK edge at the start of the frame rather close together

    On every other chip I've worked with, the lrclk / frame sync / word select is simply synchronous to BCLK just like the data, and therefore a frame sync input just has setup/hold requirements relative to the bclk sample-edge. For example, in the AD2428 datasheet:

    The I²S specification also treats WS that way, it even just lumps it together with the audio data (SD) in the timing diagrams:

    Here is what is in the datasheet

    Not in the ADAU146x datasheet :)  But yeah, that timing diagram for tSODS/tSODM in the ADAU1452 datasheet looks fine.