ΣSigmaStudio Ask AI Русский Log in

EVAL-ADAU1467 termination resistors for SDATA_IN# lines?

SigmaDSP & SigmaStudio MDThommo81 Aug 2, 2021 00:00 7 replies Original on forum ↗
Subscribe
MDThommo81 Question
Aug 2, 2021 00:00

Hi there,

I am looking at the EVAL-ADAU1467Z-schematic for some pointers on how to start our own design base around the ADAU1467 DSP and I can't understand why you place termination resistors (R12 and R14) on the LRCLK and BCLK lines, but not the SDATA_IN lines. There are termination resistors on all of the serial outputs, including the SDATA_OUT lines. Should there be termination resistors also on the SDATA_IN# lines?

Kind regards,

Mark

Audio Signal Processors

adau1467

EVAL-ADAU1467Z

SigmaDSP Audio Processors

termination resistors

SDATA_IN

Show More

Ken.M Reply
Aug 2, 2021 00:00

At these speeds, true impedance matching isn't necessary. It's common practice to use a termination resistor only at the sending end of the trace. Since SDATA_INx are inputs, you'll find the termination resistors close to the source rather than there. The idea (he says waving his hands) is that one reflection, from the impedance mismatch at the receiving end, is acceptable since it doesn't interfere. This single reflection is damped by the resistor when it gets back to the source so it doesn't keep bouncing back and forth. Placing it at the sending end is a good convention since it works if there is more than one receiving IC (a branch in the trace). If there is more than one receiver, it is best practice to make the trace branches the same length for best signal integrity, though that was not done on this board. This video explains this practice well. Robert Feranec has some other excellent videos, as well. Highly recommended.

MDThommo81 Reply
Aug 2, 2021 00:00

Thanks Ken. I get what you are saying about the SDATA_OUT now.

And, I'm still curious as to why you then included them for the LRCLKIN and BCLK_IN and not the SDATA_IN. Are you saying that the resistors for the LRCLK_IN and BCLK_IN pins should actually placed nearest to the source where those clocks are coming from (wherever that may be), and that I wouldn't need the resistors at the source of the SDATA_IN signals purely because of the data rate of the SDATA_IN lines?

Just so I am clear. If I'm running TDM8 for all serial inputs, should I then also include the resistors on the SDATA_IN paths at the source end because of the higher data rates?

DaveThib Reply
Aug 6, 2021 00:00

Hello MDThommo81,

I always like to treat the SDATA lines the same as clock lines. The timing between the clock lines and data lines are important so if one has slightly slower rise or fall times then it could cause issues. So I like to try to make the edges be as close to the same as possible. You are correct that the SDATA rate is basically about half the frequency as the bit clock rate. Of course it depends on the data but if you have the data change every other bit it would be half the bitclock rate.

Dave T

MDThommo81 Reply
Aug 7, 2021 00:00

Thanks, Dave.

Sorry, but it still doesn't explain why SDATA_OUTx lines have termination resistors and the SDATA_INx lines don't. Wouldn't we consider them to be operating at the same (or similar) data rates? I'm obviously missing something here, so bear with me...

Ken.M Reply
Aug 9, 2021 00:00

MDThommo81 said:
And, I'm still curious as to why you then included them for the LRCLKIN and BCLK_IN and not the SDATA_IN.

We generally use the termination resistors at the source end of the trace. It's a little confusing, but the clock signals are used as outputs even on the input port. The DSP is a used as a clock master here. Eval boards are always a compromise since you never know how they will be used for prototyping. Dave's comment below is not untrue, but that was not done here.

DaveThib Reply
Aug 9, 2021 00:00

As Ken mentioned, I was just pointing out something that was not done here but is a good idea to do. There are always design tradeoffs in any design.

Dave T

MDThommo81 Reply
Aug 9, 2021 00:00

Aha! Got it now. Thanks, Ken. That makes sense for this design. And thanks, Dave for your explanation as well!