• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 30 subscribers
  • Views 524 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: TLV320AIC3204 Daisy chain (DOUT in particular)

Bert Maarsen
Prodigy 40 points
Part Number: TLV320AIC3204


Hi,

We want to connect multiple CODECs (TLV320AIC3204) to one I2S bus and understand that we can connect DOUT with each other and then define per CODEC during which bits a CODEC may drive DOUT.

What kind of output driver is DOUT? If it is push-pull, how do you prevent contention when one CODEC goes from driving to HiZ and the other from HiZ to driving? Both transistions need time and will be (slightly) different ...

which could lead to short DOUT contentions.

Thanks,

Bert

  • 0
    TI__Mastermind 47945 points

    Hi Bert,

    I believe the DOUT pin is driven with an open source method. Also any kind of glitching between the two codecs is avoided due to the data latching only after DOUT has stabilized. You can see this in the timing diagram in the datasheet.

    If your receiver is set to latch on the rising edge of BCLK (this is typically default), then the DOUT transitions occur on the falling edge, meaning any glitches between the codecs handing off the daisy chain will be avoided.

    Best regards,
    Jeff McPherson

  • 0 in reply to Jeff McPherson
    Prodigy 40 points

    Hi Jeff,

    Thanks for you response. My worries are not about the latching moment, that is no issue since rising (sample) and falling (drive) edges are used. With a CLK out to DOUT delay of max. 22ns (td,do-bclk in the datasheet) there is possibly a short time where two driving CODECs can cause contention on DOUT (unnecessary currents can flow). The td,do-bclk of multiple CODECs in the design will be (slightly) different. This isn't of course an issue when the DOUT driver is open drain or i.e. ... but I can't find  information about this DOUT driver.

    Best regards,

    Bert

  • 0 in reply to Bert Maarsen
    TI__Mastermind 47945 points

    Hi Bert,

    I see. I'm pretty sure the drive being open source avoids this issue but just to be sure I've reached out to our designers to get a bit more clearer detail on how the DOUT driver works and how it avoids any shorts/contentions between the two pins. I'll follow up once they give a response.

    Thanks,
    Jeff McPherson

  • 0 in reply to Jeff McPherson
    Prodigy 40 points

    Hi Jeff,

    Thanks, I am looking forward to their answer.

    BR,

    Bert

  • 0 in reply to Bert Maarsen
    TI__Mastermind 47945 points

    FYI There is a holiday happening this week in India where the design team is located so it may be until early next week until I hear back from them.

  • 0 in reply to Jeff McPherson
    TI__Mastermind 47945 points

    Hi Bert,

    I heard back from our design manager and this part doesn't have any dedicated protection for the short condition you're describing. It's estimated that the mean time difference between two codecs switching the DOUT pin would be only a few nano-seconds, meaning the current likely won't have any time to have an impact. It's similar to what I described initially.

    You're the first person I've seen bring up this scenario over many customers using the daisy chaining feature, so I think it's a condition that will not have an impact on your system and you're safe to treat it as negligible. Though if you do run into issues with it please let us know.

    Thank you,
    Jeff McPherson

  • 0 in reply to Jeff McPherson
    Prodigy 40 points

    Hi Jeff,

    Thanks for the feedback and good to know what the DOUT behavior is.

    Thanks,

    Bert