Problem with SPDIF_RX with the XS2-L16A-512

[lilltroll]

I have problem with glitches using the module_spdif_rx. It works for 44.1 and 48 kHz, but for higher sampling-rates I get a lot of glitches.


  **********TILE[0]******** | ****** TILE[1]************
TOSLINK -> SPDIF_RX ->
                                            FIFOwrite | FIFOread->I2S.
     COAX -> SPDIF_RX ->


If I prefill the FIFO with a sine-wave and skip the writing part of the FIFO their are no glitches.

I'm using

Code: Select all

<Node Id="0" InPackageId="0" Type="XS2-L16A-512" Oscillator="24MHz" SystemFrequency="500MHz" referencefrequency="100MHz">

I have 6 cores running on the SPDIF tile. (Reducing it to 5 cores by disabling one of the SPDIF_RX doesn't help)

Code: Select all

on tile[0]:{ //The thread will fail silently if it does not have enough MIPS to parse the input stream.
            set_thread_fast_mode_on();
            SpdifReceive(p_toslink_rx, c_toslinkRX, 1, clk_spd_toslink); 
        }
        on tile[0]:{
               set_thread_fast_mode_on();
               SpdifReceive(p_spdif_rx, c_spdifRX, 1, clk_spd_spdif); //c_spdif_rx
          }

For TOSLINK:
... the signal quality of the LVTTL @192 kHz looks like this at the XMOS pin.

LVTTL signal @192kHz.png

A 1 kHz sine-wave looks like this on the output.

1kHz @192kHz.gif

The 1 kHz tone becomes a very glitchy 1133 Hz tone at the output, suggesting that the SPDIF_RX is missing samples.

FOR S/PDIF coax
... the signal quality of the LVTTL @192 kHz looks like this at the XMOS pin.

LVTTL signal @192kHz COAX.png

and the 1 kHz sine-wave looks like this on the output.

1kHz @192kHz coax.gif

A lot better but still some glitches.

Any ideás ?
Why the difference between the TOSLINK / SPDIF ?
What is the meaning of:
From SPDIFReceive.S | "There is also a subtlety that rise and fall times are not equal, and hence '0111' and '1110' are actually ones."
Is the SPDIF_RX very sensitive for different rise times / fall times ?

[infiniteimprobability]

HI,
I have seen issues where rise and fall times are long. Whilst it will transmit a square-wave OK and look OK in a one shot trace, slower rise/fall times will cause inter symbol interference where the biphase coding effective sees jitter. For example, on the wire when you see 1-0-1, the rising edge of the last one will happen sooner than the rising edge of 0-0-1 because the 0 was stronger on latter case. If you leave persistence on the scope, you will see a reduced eye, which is enough to send the SPDIF rx state machine down the wrong path.

The practical upshot of this is that most optical receivers can't reliably receive 192KHz optical, although 96KHz seems to be OK. Coax /electrical drivers should be fine up to 192KHz as long as the source is good and doesn't have too much jitter. Actually the XMOS SPDIF transmitters should be very good as the resynch the data to MCLK.

[lilltroll]

I think you are right!

toslink_96.png

toslink_192.png

The jitter level is much worse at 192 kHz.

It would still be possible to extract the data from the 192 kHz TOSLINK if we reconstructed the clock with an PLL, and read the data in sync with the clock. (I have another PCB with a PLL-based SPDIF receiver, and it can recover the data without any losses from TOSLINK @ 192kHz with the same optical reciever)

Is it impossible to write a state machine with fixed time-interval (50MHz) that is as jitter-robust as an PLL based approach ?

[infiniteimprobability]

Hi Lilltroll,

Yes, cleaning up with a local PLL could be an option.

Is it impossible to write a state machine with fixed time-interval (50MHz) that is as jitter-robust as an PLL based approach ?

There are limits with sampling at 50MHz for a signal which has a raw content at 192000 * 64 * 2 = 24.576MHz. Edges only need to come in a little faster momentarily (jitter) before three 1s or 0s could be seen as two ones or zeros.

Increasing robustness to jitter can be done by increasing the oversample ratio. For example, when running at 176.4, things should be much more robust by definition. Other ideas including using an external clock for the port, shifting the whole ref clock upwards (can break other stuff), or use the trick of dividing from the core clock (eg. 500/8 = 61.25MHz), but of course the tables will need reprogramming. Go too high though and you will break the neat method of sampling 4 bits and using the nibble as a vector with immediate offset to implement the state machine. For example, oversampling by 4.x would mean a 256 entry lookup table for each state, which is 16x more entries, and you would have to move to a different addressing scheme which will consume further code memory and push timing..