This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TLV320AIC3204: BCLK Master / Slave mismatch

Part Number: TLV320AIC3204
Other Parts Discussed in Thread: TLV320AIC33

Tool/software:

We use multiple CODECs (TLV320AIC3204) connected to a host. To have control over the MCLK quality we have an external MCLK source and make one CODEC Master, the other CODECs and host are slave.
Checking the timing we discovered that the BCLK Output rise/fall time of the Master CODEC (< 24ns) doesn’t match with the BCLK Input rise/fall time requirement of the Slave CODEC (< 4ns and for a BCLK of 10MHz/100ns this may be relaxed to 10ns).

What is the rational behind this and why is there a mismatch?

May we relax the input rise/fall time more, given that our BCLK period time is 488ns?

Side note, the application note SLAA301 describes the "TDM Function to Interface Four TLV320AIC33 Codecs With a Single Host Processor". The TLV320AIC33 has the same issues w.r.t rise/fall time for the DSP Master and DSp Slave mode.

Thanks.




  • Hi,

    Apologies for the delay, I will follow up on this and update the thread tomorrow.

    Thanks and Regards,

    Lakshmi Narasimhan

  • Hi,

    Basically, from a device timing perspective, for a BCLK period of 488ns (so a frequency of ~2.048MHz), the 24ns rise/fall times is not a concern. A few things to keep in mind:

    1) The device has an integrated PLL which can drive the internal clocks. When using the BCLK with this rise/fall time as the input source for the PLL, resulting jitters can possibly affect device performance. However, if the external MCLK source is shared to all the devices, this is not a concern.

    2) In the system, it needs to be ensured that due to any routing/coupling on the PCB, there are no glitches introduced into the BCLK line during the rise/fall events.

    3) Due to the slow rise times, there will be some impact to the IOVDD current, but it should still be fine from the overall system perspective.

    Thanks and Regards,

    Lakshmi Narasimhan

  • Hi,

    Thank you very much for the quick response and clear clarification, that makes sense.

    Best regards,

    Bert