Issue with 768kHz ADC Input on XMOS XU316 Not Working Properly

[masaikemlol]

Hello, I am using the XU316 audio evaluation board with crystal frequencies of 45.1584MHz and 49.152MHz on sw_usb_audio_8.1.0
I found that the 768kHz digital loopback ADC input on XMOS is not functioning properly.

I set the Master Clock to 1024 and configured the maximum frequency to 768kHz like this:

Code: Select all

/*** Defines relating to audio frequencies ***/
/* Master clock defines (in Hz) */
#ifndef MCLK_441
#define MCLK_441           (1024*44100)   /* for  45.1584MHz */
#endif

#ifndef MCLK_48
#define MCLK_48            (1024*48000)   /* for  49.152MHz */
#endif

/* Maximum sample frequency device runs at */
#ifndef MAX_FREQ
#define MAX_FREQ           (768000)
#endif

and I enabling 2-channel ADC and DAC on ports 1O and 1P:

Code: Select all

    
    <!-- Audio Ports -->
    <Port Location="XS1_PORT_1L" Name="PORT_MCLK_IN"/>
    <Port Location="XS1_PORT_1N" Name="PORT_I2S_LRCLK"/>
    <Port Location="XS1_PORT_1M" Name="PORT_I2S_BCLK"/>
    <Port Location="XS1_PORT_1O" Name="PORT_I2S_DAC0"/>
    <Port Location="XS1_PORT_1P" Name="PORT_I2S_ADC0"/>

When I short the 1O and 1P ports, I found that digital loopback works fine for 384kHz and lower frequencies, as shown in the attached diagram.


However, when I switch to 768kHz digital loop, the situation changes — the overall noise level becomes significantly higher.


I tested the I2S output on port 1O by connecting it to an external DAC that supports 768kHz, and it worked correctly, ruling out issues with the I2S output.
I suspect the problem lies in the 768kHz ADC digital input on port 1P.
Since the setup is for a special high-frequency microphone with an effective bandwidth of up to 240kHz, the 768kHz rate is crucial for our application.

Does anyone have any insights or suggestions regarding this issue with the 768kHz ADC input?
I would greatly appreciate any response.

[MaximLiadov]

I would:
1. Try to change buffer size. As 768 mode needs twice. And it could be driver/software issue.
2. Try to (record in an editor and) look at the waveform. Spectrum doesn't tell you what's wrong with the signal. Not sure if many software apps support 768 though.
3. Try a software loopback inside the firmware with no any in/out port connection. To exclude any hardware issue.

[masaikemlol]

I would:
1. Try to change buffer size. As 768 mode needs twice. And it could be driver/software issue.
2. Try to (record in an editor and) look at the waveform. Spectrum doesn't tell you what's wrong with the signal. Not sure if many software apps support 768 though.
3. Try a software loopback inside the firmware with no any in/out port connection. To exclude any hardware issue.

Hi MaximLiadov, thank you for your suggestions. I am a beginner with XMOS, so I have a few questions.

1. Where can I change the buffer size? Is it in the ASIO driver or in the code?

2. I haven't worked with software loopback before. Do you have any examples or documentation on this?
I believe I saw an i2s loopback application in the document AN00162: Using the I2S library.
Is the loopback you're referring to the example in the AN00162 document?

Thank you again for your response.

[MaximLiadov]

Buffer size is in the drivers panel. Default 256 samples is not good enough for 768.

Software (firmware side) loopback could be easily implemented in the audio loop. Exactly where you read data from input port array / send to the XMOS output port array. You don't need any application note here. Just look at the source code. AN00162 is misleading and outdated.

[Ross]

Could well be a code timing issue, we don't test up to this sample rate.

To prove/disprove this theory; *temporary* crank up the core clock frequency of the xcore (in the xn file). Something like 800 MHz.

You cannot sell a product in this state (likely your parts are 600 MHz rated) but it might help narrow down the issue between device/host issues etc.

If this fails it could be an I/O timing issue at these speeds - that is the port is sampling at the wrong part of the clock period. There are some tricks for dealing with this but try the code timing "check" first.

[masaikemlol]

Buffer size is in the drivers panel. Default 256 samples is not good enough for 768.

Software (firmware side) loopback could be easily implemented in the audio loop. Exactly where you read data from input port array / send to the XMOS output port array. You don't need any application note here. Just look at the source code. AN00162 is misleading and outdated.

Hi MaximLiadov,

Thank you very much for your clarification and guidance!

I tried the software loopback and adjusting the ASIO buffer size, but unfortunately, it's still not working.

Nonetheless, I’m really grateful for your assistance!

[masaikemlol]

Could well be a code timing issue, we don't test up to this sample rate.

To prove/disprove this theory; *temporary* crank up the core clock frequency of the xcore (in the xn file). Something like 800 MHz.

You cannot sell a product in this state (likely your parts are 600 MHz rated) but it might help narrow down the issue between device/host issues etc.

If this fails it could be an I/O timing issue at these speeds - that is the port is sampling at the wrong part of the clock period. There are some tricks for dealing with this but try the code timing "check" first.

Hello Ross,

Thank you so much for your reply!

① I have another potential issue that I haven’t mentioned yet. The ES9822 ADC works perfectly with the XU316 at 352.8kHz using I2S, but when I switch to 384kHz under 600MHz, the same high background noise issue occurs.

② Unfortunately, the 768kHz digital loopback still does not work properly, even at 800MHz. Could this be the timing issue you mentioned?

I know your time is valuable, so if you have any quick tips or "some tricks" you mentioned, I would greatly appreciate them!

[infiniteimprobability]

I agree with @Ross and think this may be related to port timings. Over 20 MHz you need to start thinking about the setup and hold timing of the port - in this case the BCLK is 24.576 for 384k. If this is violated then you will get noise for sure as you will sample outside of the data valid window and it will happen at higher rates but be fine at lower rates. In cases where it is source synchronous (all signals are in the same direction - eg. driving a DAC) it usually just works because all delays are the same but anything that is round-trip (clock output from XMOS followed by capture on data pin) then things get a bit more complex. My sense is that this is what you are seeing.

There is a document for xcore-200 which is published which explains all of the concepts here https://www.xmos.com/download/I-O-timin ... 0(1.0).pdf

The xcore.ai one has been written but I can't see it on the website. However the ports are logically identical so the same delay registers etc. are in xcore.ai and do the same things as xcore-200. The silicon delays will be a bit different for ai but not much. I suggest taking Quick Look at that (section 4.1 Input: Calculating setup and hold times for an internal application clock) and I'll check internally about getting the ai version published.

[infiniteimprobability]

You can see some examples in audio ports.xc for TDM where the bit clock is fast:

Code: Select all

#if (I2S_CHANS_ADC != 0)
    /* Some adustments for timing. Sample ADC lines on negative edge and add some delay */
    if(XUA_PCM_FORMAT == XUA_PCM_FORMAT_TDM)
    {
        for(int i = 0; i < numPortsAdc; i++)
        {
            set_port_sample_delay(p_i2s_adc[i]);
            set_pad_delay(p_i2s_adc[i], 4);
        }
    }
#endif

[infiniteimprobability]

It's published now!

xcore.ai IO timings