DIX4192: SPDIF-output: AESOUT vs. TX

Correction:

the receiver is the SRC4392, not the SRC4192.

... and still having loss of lock every now and then.

Only with 192kHz or 200kHz as input sample rates.

This does not happen with the CS8422 as SPDIF receiver, and not with the CS4265 as a transmitter...

???

Christian Erle55 said:

... and still having loss of lock every now and then.

Only with 192kHz or 200kHz as input sample rates.

This does not happen with the CS8422 as SPDIF receiver, and not with the CS4265 as a transmitter...

???

Did you see my response to your other question?

Hi Christian, 

I'm sorry you are having these issues. One thing to consider is that the AESOUT does not have the same drive strength as the TX+ pin, so it may be possible if you have any series resistance on this line and/or sufficient parasitic capacitance that the AESOUT pin is unable to keep up with the slew rate necessary to drive a 192kHz signal at 3.3V. 

Another possible source of error is that the DIT transmitter on DIX4192 and DIR receiver on SRC4392 both require reference clocks that should be multiples of your intended sample rate, and if the reference clock you are providing has too much jitter this could potentially lead to missing clock edges, which will cause the DIR to unlock (even missing a single edge can be problematic). It may be that the Cirrus receiver you are using is more tolerant to this jitter, but I'm not sure.

Best,

Zak

Hi Andy,

over here in Germany, 7AM now, work starting...

To your reply in the other thread:

I definitely need the SRC, and it is in the signal path:

SPDIF --> RX1 --> SRC --> I2S (MCLK)

I know that the PLL-settings refer to the known MCLK, so I change these registers according to the I2S / MCLK-side.

Hi Zak,

1) drive strength: no, I checked it on the scope, signals look perfect, nice flanks, no overshoot. And AESOUT works with the CS8422 as a receiver. As I said, on the scope the AESOUT and TX signals look identical.

2) jitter: no, pretty sure that we're really clean on that too, because our analyser software is providing high resolution FFTs and signals are super clean.

Our system is used for NVH stuff including high resolution RPM measurements, so we need to have clean clocks.

So this new prototype board with the SRC4392 is part of that system, the sender with the DIX4192 is obviously another external device, but running on similarly accurate clocks.

Yesterday I checked every signal, played with every component in the signal path and with all the registers on both sides, still losing lock regularly with SPDIF rates of 192kHz and 200kHz.

Any more ideas?

I do not want to switch back to the CS8422 because it does not provide full access to channel status and user data.

Christian Erle55 said:

Hi Andy,

over here in Germany, 7AM now, work starting...

To your reply in the other thread:

I definitely need the SRC, and it is in the signal path:

SPDIF --> RX1 --> SRC --> I2S (MCLK)

I know that the PLL-settings refer to the known MCLK, so I change these registers according to the I2S / MCLK-side.

Hi, Christian,

It's evening here in the US, almost time to sleep,

I am looking at my code for a recent SRC4392 design I did and I use the same signal path you describe. I have a fixed reference clock of 24.576 MHz, input on the RXCKI pin. This clock is constant, regardless of input sample rate. Therefore, the PLL1 register settings never change. This is the key thing to understand here.  PLL1 generates a high-frequency clock (98.304 MHz) that is used to oversample the incoming AES3 signal and decode it.

PLL2 takes the output of the AES3 decoder and synthesizes a new MCLK (called RXCKO) which is at the correct oversampling frequency for the input sampling frequency, that is for a 48 kHz sample rate input RXCKO is 12.288 MHz and for 44.1 kHz RXCKO is 11.2986 MHz. Note that the latter is [I]not[/I] related to the PLL1 reference clock! I've verified this in my design up to 192 kHz (from an XMOS thing, yes) and indeed it works for all sample rates. The data sheet even says that you can use the common 27 MHz clock for the PLL1 reference clock, and that's not related to any standard audio sample rate, and the DIR still works.

You should enable the RXCKO output pin and look at it with an oscilloscope to prove this for yourself. Also monitor the LOCK output, which tells the status of PLL2; when that's true, RXCKO will output a clock at the oversampling frequency related to the input. It is instructive to configure the chip to enable RXCKO to toggle even if PLL2 isn't locked.

Next is the SRC block. This block too has a reference clock input, which should be at whatever rate your I2S port (and the DAC connected to it) should run at. So for 200 kHz output sample rate the SRC reference clock should be 25.6 MHz. For 192 kHz this should be 24.576 MHz. The only configuration for the SRC block is to set its input source (set it to the DIR output). The rate detector automagically determines the input-to-output rate ratio with no intervention required.

All of this is a long-winded way of saying: [I]the only configuration you need for the signal path you describe is to set the PLL1 constants based on the reference clock you provide to the DIR.[/I] The rest of it just works. The only reason to change the PLL1 constants is if its reference clock changes, and generally there's no reason at all for it [I]to[/I] change.

One more thing. ASRCs are commonly used to "clean up" jitter from the AES3 data. So while you could use the RXCKO output for your DAC's MCLK input, you get better converter jitter performance by using an oscillator for that. So this oscillator needs to drive the SRC reference clock as well as the DAC's MCLK. And it can drive the DIR's reference clock, too, as a convenience. And it must also be the audio serial port's (I2S port) master clock source. LRCLK and BCLK are divided down from that clock. 

But if your I2S port drives a DSP or something not a DAC, then jitter on the recovered clock doesn't matter. The DSP won't take in the modulator clock, anyway, it'll just shift in using BCLK. So you could use RXCKO as the SRC's reference clock.

Hope this helps. The part really does work as advertised.

Hi Andy,

thanks for your late night reply!

I have already considered all the above in my design.

Further info:

- The SRC4392's port A I2S  is connected to an FPGA and is controlled like an ADC slave.

- I2S sampling rate may change, our system offers 24/48/96/192kHz (with MCLK at 24.576MHz (or half for 24kHz)) and 25/50/100/200kHz (with MCLK = 25.6MHz or half).

- The PLL1 registers are set according to the system's sampling rate / MCLK.

- LOCK pin and lock interrupts are constantly monitored, and results are compatible with what I see in the audio output (data lost when lock is lost)

- reference clock for RX is MCLK

I have 3 sources for testing:

1) some cheap XMOS USB-to-optical-SPDIF thing which can deliver up to 192kHz output (so nice to see the FFT of a digitally synthesized sine! ;-) ), this one has a standard TOSLINK optical output.

2) a CS4265 codec with up to 192kHz output, optical driver is a versatile link thing AFBR-1624Z - which has the same wavelength as TOSLINK, but can easily drive 100m of optical cable, tested and working in industrial settings

3) another prototype board with TI's DIX4192 and the same versatile link driver as in 2), now sourced by the TX+ pin

Reference for comparison are existing SPDIF input boards with the CS8422, 2 versions with different optical receivers (TOSLINK & versatile link). These run in parallel with the exactly same I2S interfaces and signals. As mentioned before, the CS8422 versions are working perfectly with all 3 sources (even with the DIX4192's AESOUT output).

I checked the RXCKO output and played with the PLL1 registers:

it's definitely the receiver and PLL1 which is causing the problems.

When lock is lost, also RXCKO goes low, otherwise it shows the SPDIF's MCLK.

So I played with the PLL1 register settings and found out that if I tune these, I can get a stable signal, no matter what the sampling rates are.

The not so funny thing is:
I have 2 identical prototype cards, after having tuned PLL1 with card 1 to about 100MHz (datasheet says 98.304MHz), on card 1 everything was stable.
Then 1 used the exact same settings on card 2 (checked all components and connections) - and did not get always a stable signal. Very frustrating...

Again, this problem occurs only with SPDIF sampling rate 192kHz or 200kHz.

Below are the settings for card 1, which worked for every combination of IO rates:
("TAS" is our measurement system)

for SPDIF sampling rates <=100kHz all combinations of TAS sampling rates
and PLL1 settings work!

TAS 200kHz, SPDIF 192/200, several sources
SRC4392
RX PLL1:
0x21 0xDF 0xBD
P = 2
J = 7
D = 8125
K = 7.8125
PLL1 = MCLK * K / P = 100.0000 MHz

TAS 192kHz, SPDIF 192/200, several sources
SRC4392
RX PLL1:
0x22 0x05 0x64
P = 2
J = 8
D = 1380
K = 8.1380
PLL1 = MCLK * K / P = 99.9997 MHz

Christian Erle55 said:

- The SRC4392's port A I2S  is connected to an FPGA and is controlled like an ADC slave.

- I2S sampling rate may change, our system offers 24/48/96/192kHz (with MCLK at 24.576MHz (or half for 24kHz)) and 25/50/100/200kHz (with MCLK = 25.6MHz or half).

- The PLL1 registers are set according to the system's sampling rate / MCLK.

- LOCK pin and lock interrupts are constantly monitored, and results are compatible with what I see in the audio output (data lost when lock is lost)

- reference clock for RX is MCLK

Ok, I admit I'm confused, let me understand it.

1. The FPGA is an I2S data sink. For our purposes we can consider as you say that an ADC with I2S port is connected to the FPGA. Got it.

2. The FPGA's I2S port is a slave, so the SRC4392 provides LRCLK and BCLK along with the data.

3. Your design provides a 24.576 MHz clock or a 25.6 MHz clock to both the FPGA and to the SRC; only one is active at a time. The selected clock acts as the audio serial port A's master clock as well as the SRC's reference clock.

4. For convenience reasons, the selected MCLK above is also used as the DIR (S/PDIF input) reference clock. When the clock changes, you load the correct PLL1 settings to ensure that PLL1's synthesized output is the 98.3 MHz noted in the data sheet.

5. The idea here is to take the S/PDIF input at any sample rate (standard or not) and convert it to a specific sample rate which may be standard or not. (That's what ASRCs are for!)

6. The problem: The DIR fails to lock reliably at either 192 kHz or 200 kHz input sample rates. As you note, this points to an issue with PLL1.

So -- 

The data sheet has a section on Page 40 titled "Applications Information." It has a peculiar recommendation:

The substrate ground, BGND (pin 44), should be connected by a PCB trace to AGND (pin 10). The AGND pin is then connected directly to the ground plane. This connection helps to reduce noise in the DIR section of the device, aiding the overall jitter and noise tolerance for the receiver.

There is also a comment about putting a small series resistor or a ferrite bead between the 3.3 V rail and pin 9 which is noted as "DIR comparator and PLL power supply."

On my boards I did both (that series resistor is 5.1 ohms). Did you? My design locks the PLL reliably at 192 kHz. I can't test at 200 kHz because I don't have anything convenient that can generate S/PDIF at that rate.

I assume TI wouldn't put such recommendations in the data sheet if they didn't matter. (And yeah, I know, some old converter data sheets offer the bad advice about splitting ground planes and joining them under the converter chip ...) This means that TI knows the receive PLL1 is sensitive to noise on its power supply rail and the substrate of the device, and these two suggestions are their mitigation.

Anyway, that's about all I got. Good luck/

Hi Andy,

I see I was a little unclear:

the FPGA is the master, providing all I2S clocks, with data coming from from the SRC.

PCB layout / schematics:

- pin 44 BGND is connected to a GND plane almost directly

- pin 9 VCC is decoupled with ferrite bead, and has the prescribed 10uF + 100nF caps very close

I will play with the hardware, although I'm pretty confident in the layout and schematics.

The thing is, why does it work when I change the PLL1 frequency?
Yesterday I checked the 2 prototype cards, and I could get good signals by changing the PLL1 frequency, depending on the card and the input sample rate.
And the problem only occurs at 192kHz and 200kHz...
Maybe you could ask one of the chip's design engineers?

I just checked and changed the hardware, step-by-step:

- improved pin 44 GND connection

- replaced ferite bead for VCC with 10R

- added some 10µF caps

--> no change in behavior

I also checked all the supply voltages, noise is below my scope's noise.

So either I'm still doing something wrong (definitely possible, and preferred...), or the chip has some problem.

It's very interesting how sensitive PLL1 seems to be: for 2 different SPDIF sources with 192kHz each (different devices, so probably slightly different 192kHz), the PLL1 settings need to be changed to get a stable signal. Once the right values are set, it is 100% stable.

About PLL1: what are the upper and lower frequency limits?

Any more help, please?

I do want to use the SRC4392, but right now it does NOT work as advertised.

After having checked all hardware (clocks, power supplies, IO signals), checked the firmware, and "played" with the PLL1 settings, I still do not get a PLL1 setting so that all input sample rates up to 216kHz (as in the datasheet) are "locked" in and produce stable signals.
Up to 100kHz all is fine, but I need it to work with 192kHz and 200kHz.

Hi Christian,

I'm sorry you are having issues with the device. Unfortunately with the device being 15 years old, there aren't many people left that were directly involved with this project. I did manage to find someone that had some involvement though and he offered similar suggestions as my initial reply and confirmed that the drive strength of the AESOUT pin is significantly lower than that of the TX+ pin. He also mentioned that the AES decoding should be less sensitive with higher PLL1 frequencies, but I don't have any information on the upper and lower limits of this outside of what is offered in the datasheet. Since replacing either the DIX4192 OR the SRC4392 resolves the issue, it would seem that the problem is a combination of the drive capability of the DIX along with the jitter tolerance of the SRC since improving either of these leads to a stable lock. Since a lot of this depends on variables in your system, I'm not sure this is an issue I would be able to recreate, but I can at least try to do so with our EVMs as a proof of concept. Please give me a few days to attempt this.

I'm also trying to dig deeper into this to see what I can find about this device's test program. I will keep you posted on my findings but it will take some time to gather this information.

Best,

Zak

Christian Erle55 said:

Any more help, please?

I do want to use the SRC4392, but right now it does NOT work as advertised.

After having checked all hardware (clocks, power supplies, IO signals), checked the firmware, and "played" with the PLL1 settings, I still do not get a PLL1 setting so that all input sample rates up to 216kHz (as in the datasheet) are "locked" in and produce stable signals.
Up to 100kHz all is fine, but I need it to work with 192kHz and 200kHz.

Hello Zak, hello Andy,

thanks for your ongoing support!

Maybe I was a little unclear, but the main problem I have is now "only" the SPDIF receiving side with the SRC4392.

Maybe I should start a new thread, or switch over to the old one which I started because the SRC's datasheet was a little unclear:
"SRC4392: auto-detect/set varying SPDIF input sample rates possible?" (closed thread, which I cannot link somehow...)

The DIX4192 is currently only used on prototype / development board.
That board has 4 ADCs (TI's ADS127L01 - btw, the best ADC ever built (digital filters, DC, SNR, THD) connected / driven by 2 DIX4192.
The DIXs convert the I2S signals to SPDIF via AESOUT, which is connected to an optical driver. I changed the output to the TX+, but
both signals look identical on the scope. The signals and clocks look really good, and our current SPDIF-input card with the CS8422
has no problems receiving signals (no matter if driver is AESOUT or TX+), with 192kHz or even 200kHz SPDIF sample rate.
The SRC4392 board can only receive data when the AESOUT pin is used with SPDIF up to 100kHz.

Anyway, that DIX4192 board is not that important, I just use it as another source for testing the much more important prototype boards with
the SRC4392, which I have 10 boards, to replace the board with the CS8422.

So my main problem is that the new SRC4392 boards do NOT lock on all SPDIF inputs at 192kHz or 200kHz.

The SRC4392's I2S side works perfectly with all our system's sample rates (48, 50, 96, 100, 192, 200 kHz), with all these I2S sample rates
the I get stable data, but only with SPDIF sample rate up to 100kHz.

With SPDIF sample rates of 192kHz or 200kHz I must manually tune the SRC4392's PLL1 to get a stable lock.
The worst thing is, that the PLL1 setting does not depend only on the input sample rate (and device), but also on the card with the SRC:
I have 2 cards, and for the same SPDIF input at 192/200 the PLL1 settings for both SRC4392 are different.

And the PLL1 settings also need to be tuned depending on the input source, of which I have 3:

1. Douk Audio U2, USB to TOSLINK adapter working with an XMOS-chip, max. SPDIF output rate is 192kHz
2. a sensor board from our company, sending SPDIF via versatile link with up to 192kHz, SPDIF source is the Crystal codec CS4265
3. the prototype board described above with the DIX4192 which can send SPDIF data with 48, 50, 96, 100, 192, 200 kHz (now using TX+ as a driver)

And again, the SRC4392 can receive all these signals, but only with special PLL1 tuning!

I tried some more desperate things with the SRC4392, like checking/changing for the Xth time all registers, on the hardware side I put an additional driver to the MCLK, tried all kinds of terminations (serial, parallel AC, ...) - with no effect.

So please try to connect several SPDIF sources with 192kHz - or preferably the maximum 216kHz as in the datasheet.
I'm really curious if that works, here it does definitely not, and I've turned my stuff inside out several times now.

Hey Christian,

I'm sorry I know this problem is frustrating. I still need to do more testing, but so far I have tested an SRC4392 on our TLV320AIC3268EVM-U, which has two of them on the ASI buses to provide optical input/output. I was generating an optical stream from an AP555, running it through the SRC, and back into the AP to make sure I could see the same signal. What I've found so far is actually very similar to your results. I was able to get it to pass a 96kHz signal through with no problem, but as soon as I went higher I lost the signal. I didn't have a chance to play with the PLL1 settings yet to see if I could get it to lock but I plan to do this along with testing some other boards that the SRC4392 is on. I don't have much else to offer yet, but on the bright side, you are not the only one seeing the issue!

Best,

Zak

Hello Zak,

thanks for your efforts!

It really helps - even if it's only to ease my mind...

About my PLL1 experience:

I can't really tell if it's good ro raise or lower the PLL1 frequency.
I found the DIR to lock in some combinations with 96MHz, in others with 102.4MHz or even higher.

Good hunting!

Hey, guys -- 

This is getting weird.

I just sat down to do some more careful re-testing.

First, the simple loopback test, with the converter's coax out looped back into its coax input, and the TOSLINK out looped back into the TOSLINK input. I stepped the ADC sample rate, which drives the S/PDIF and TOSLINK output rate directly, through my six steps: 44.1 kHz, 48 kHz, 88.2 kHz, 96 kHz, 176.4 kHz and 192 kHz. For all cases, the PLL1 settings remained the same, and they are the values given data sheet for 24.576 MHz reference clock.

The SRC4392 locked for all rates with the coax input. It did not lock for 176.4 kHz and 192 kHz on the TOSLINK input.

Next I used my XMOS USB 2 audio eval kit, which has coax and TOSLINK ins and outs. Well, the TOSLINK out doesn't work -- dunno why. But for its coax out the SRC's DIR synchronized for all six of the sample rates.

The data sheets for the Everlight TOSLINK transmit and receive modules both claim 16 Mbps maximum transmission rate, which should work for the sample rates involved. They support 3.3V supply, and so  I don't have any ferrites on the supply pins for the TOSLINK modules. The connection to the SRC is right out of the data sheet. Maybe it fails to work at the highest sample rates because I have crappy Monoprice plastic fibers? 

I need to look at the TOSLINK receiver's digital output on the oscilloscope and see if the signal degrades in some way with increasing the sample rate.

I've had issues in the past with the TOSLINK modules' housings being misaligned, too.

Anyway.

Hi Andy,

the standard TOSLINK stuff with 16Mbps might be too slow. For SPDIF you need about the bandwidth of 192kHz * 32bit * 2 channels * 2 (biphase encoding), so that is equal to the (often used) MCLK rate of 24.576MHz.

I have had the same experience with other TOSLINK receivers and drivers with 16Mbps, some make the 192kHz, some don't.

That is one reason why we switched to versatile link: higher bandwidth.

But even with the VL drivers and receivers and really good looking waveforms (squares, not "shark fins" as we call it in Germany) the DIR does not lock reliably.
I have checked and changed and switched everything on the optical input side, even with a Schmitt-trigger installed.
That's why I narrowed it down to the DIR and its PLL causing the problems. Anyway, the CS8422 even works with the crappy TOSLINK signals.

Andy,

Thank you for doing some additional testing and sharing the results! The optical modules we have are rated for 16Mbps and I thought this would be sufficient but also forgot to account for the additional factor of 2 from the biphase encoding...

Chris,

Are you able to test the SRC4392 with a coax input instead just to see if the device is ever capable of locking at 192kHz? I know you are using much better optical links but I think this would be an interesting test to help narrow down where the problem might be.

Best,

Zak

Hi Zak,

I checked with an electrical signal at 192kHz from coax (2 sources), and it is the same:

The DIR PLL1 only locked after tuning it a little, in this case it was 102.4MHz.

As I said, locking at these high input rates is possible, but only with tuning the PLL,

AND what is worst:

1. the tuning depends on the source: 2 different SPDIF sources with 192kHz -> 2 different PLL settings were necessary
2. and yet even worse: 2 different SRC4392 -> 2 different PLL settings were necessary between the 2 chips

This is the main problem: that the receiver does not automatically work for high input SPDIF rates.
I know what's going on on our system's I2S side, sampling rate, MCLK, ... - but on the SPDIF side it needs to be totally automatic, which it is not.

Hello TI,

any news?

We need some of these cards working very soon, and right now it looks like I have to switch back to the CS8422 - which I don't like, but it seems I have no other choice.

Most disappointing with the current status is that we cannot use the 10 assembled boards with the SRC4392.

Hi Christian,

I apologize for the delay. I was able to test the SRC4392 EVM using coax input/output with a 24.576MHz reference oscillator. I was able to reliably lock onto a 216kHz signal from an AP and generate the same signal on the DIT and read it back on the AP without issue. I used the PLL settings recommended in the datasheet with P = 2, J = 8, D = 0. I think on our boards the previous issues were most likely a result of the optical connectors we use not being rated sufficiently for 216kHz operation. 

I also checked with the team and there are no known issues with the device or any records of faulty material being sent to customers so I do not believe this is a quality issue. While I know you have been very diligent in your design and testing, I think the root of this may be in layout or our original suspicions of clock and power supply integrity. The SRC4392EVMs are still available if you want to use one of these to compare against or possibly use for testing.

Best,

Zak

Hello Zak,

hmm, I've been through all: power, noise, clocks. Noise is low, clocks look good.
I'm doing mixed signal pcb layouts for over 20 years now - this does not mean I don't do mistakes - but I've checked the layout and every signal, it all looks good.

I have to check any temperature influences, because yesterday all cards with the SRC4392 were running very stable and always locked.
Right now it's about 10°C cooler in my office than it was when I last tested it.

Any news? Still not working here...

Hi Christian,

The only other thing I could suggest would be to try transformer coupling the receiver if you are not doing so already. If there is possibly a ground disturbance on your source or receive board from high current nodes, SMPS, etc. then this may contribute to the device's inability to maintain a stable lock. I have verified that we do not see any issues operating the device up to 216kHz with the standard recommended PLL settings, so unfortunately I'm not sure what else to suggest that we have not already discussed,

Best,

Zak