The XMOS Support Board is closed to further postings.

If you have a sales or technical support question that is not answered in the XMOS knowledgebase, please send us a support ticket.

If you are interested in discussing products, applications and ventures with other XMOS developers, please join our open community at: www.xcore.com.

We also encourage developers to contribute towards the XMOS Open Source project which collaboratively develops software peripherals under a unified open source license.

External clock

Discuss the XMOS processor range here e.g. XS1-L1, XS1-G2, XS1-G4

External clock

Postby sjalloq_xmoslinkers » Wed, Sep 02 2009 13:43:07

Hi there,

I'm trying to work out from your documentation if it's possible to use an external clock as a source for your I/O cells. Specifically, I want to use an external clock for an I2S interface and use that clock to synchronise the BCLK, LRCLK and DATA outputs. My goal is to minimise jitter by using high quality external clocks.

In a description of the clock block in section 3.4 of "XS1 PORTS: USE AND SPECIFICATION (1.02)", it states that any external clock is itself clocked-in using the internal 400MHz clock. Surely this negates the benefit of using an external clock or am I misinterpreting the documentation? I couldn't find a diagram of the I/O architecture anywhere.

Thanks.
sjalloq_xmoslinkers
 
Posts: 7
Joined: Wed, Sep 02 2009 13:23:14

Re: External clock

Postby ross » Wed, Sep 09 2009 10:18:49

Hi sjalloq,

We replied to you question on our ticketing system regarding this, did this resolve your issue?

The reply (from Larry) was as follows:

Yes, any external clock is resampled to 400MHz

If you tie I2S signals BCLK LRCLK and DATA to a low-jitter external
clock on the XMOS device, this will introduce a jitter in the order of
one to two 2.5ns (400MHz) cycles

From our experience, audio CODECs are immune to jitter/phase error on
the I2S lines as long as they are drift free with respect to the master
clock, so in this case the introduced jitter should not affect the audio
path.

ross
 
Posts: 303
Joined: Tue, Aug 12 2008 10:12:46
Location: Bristol

Re: External clock

Postby sjalloq_xmoslinkers » Wed, Sep 09 2009 11:34:09

Hi Ross,

yeah I got the reply, just thought I should post it here too so that others searching could find it. I actually forgot to post the reply so you've done me a favour.

As for resolving my proplem, yes, in a way it does as it rules out your device for my current product development. However, I am still keen to possibly have a play with one of your dev boards and am still waiting a reply regarding your USB Audio implementation. I replied to Larry's email on the3rd and am still waiting on a reply.

Cheers, Shareef.
sjalloq_xmoslinkers
 
Posts: 7
Joined: Wed, Sep 02 2009 13:23:14

Re: External clock

Postby ross » Wed, Sep 09 2009 12:27:33

sjalloq wrote:I replied to Larry's email on the3rd and am still waiting on a reply.


Hi sjalloq, chased this up for you as Larry is on holiday.

For the benefit of others:
Yes, that is correct - inputs are resampled. For audio applications, we
often input the MCLK (eg 24.576mHz) and then use that to clock the other
IOs (LRCLK, BCLK, SDIN, SDOUT). Note that you can run the device from
the audio frequency (use MCLK as the input to our PLL) which will then
lock the IO sampling clock to your audio clock.

We support both Master and Slave mode codecs, so if you are concered
about jitter on the LRCLK, you can use a master codec which generates
the LRCLK from the MCLK with low jitter, and have that as an input into
the XMOS device.

Note that jitter on BCLK, SDIN, SDOUT has no effect on the audio quality.

We are currently writing some application notes on this area, which will
be published soon.
ross
 
Posts: 303
Joined: Tue, Aug 12 2008 10:12:46
Location: Bristol

Re: External clock

Postby Berni_xmoslinkers » Mon, Sep 21 2009 5:11:45

Why are you running the MCLK trough the MCU anyway? As master clock is not a clock for any datastream its only the operating clock for the ADCs and DACs so you dont even need to connect the clock to the xmos chip at all.But if you want to keep the bit clock in sync with it i would recommend you simply run the external MCLK source to the ADC/DAC and the MCU at the same time. Then divide the MCLK inside the MCU by 512,256,128... whatever your ratio is and then generate the bit clock (BCK) from that.

I personaly think this is not really nesesery to get great audio from it but it only needs a external clock source to make it work so why not.

The project im working on also involves I2S but i toght of generating the MCLK inside the MCU.
Berni_xmoslinkers
 
Posts: 30
Joined: Wed, Sep 02 2009 15:13:03

Re: External clock

Postby ross » Tue, Sep 22 2009 14:57:19

Berni wrote:But if you want to keep the bit clock in sync with it i would recommend you simply run the external MCLK source to the ADC/DAC and the MCU at the same time. Then divide the MCLK inside the MCU by 512,256,128... whatever your ratio is and then generate the bit clock (BCK) from that.



Yes, this is what we would recommend.
ross
 
Posts: 303
Joined: Tue, Aug 12 2008 10:12:46
Location: Bristol

Re: External clock

Postby lilltroll_xmoslinkers » Mon, Oct 26 2009 10:22:31

Hi
I can't understand the problems here, I only se possibilities with XMOS so far !?

The way to reduce jitter is to feed the CODEC with its own low-jitter clock source, and to run the codec as MASTER in the intercommunication. The clock typically clocks the oversampling DAC inside the CODEC without a PLL in the clockpath (in low jitter mode)

Since the clock in always running, an extra pin is needed for framing in the communication, but nothing of this will create jitter. The burden on the MCU is to communicate data back in time to the CODEC before next sample is clocked out.

A typical problem that arises with common MCUs in slave mode & using low latency, e.g. running sample by sample and not block based processing with long FIFOs; is that if another interrupt occurs, the MCU might be starved out of time before it can respond back to the CODEC and a very noticeable glitch is introduced in the sound.

The use of deep buffers can reduce the possibilities of glitches, but deep buffers also introduce time-delay which isn’t an option in feedback systems.
lilltroll_xmoslinkers
 
Posts: 30
Joined: Mon, Oct 26 2009 9:26:42
Location: Sweden, Eskilstuna

Re: External clock

Postby sjalloq_xmoslinkers » Mon, Nov 23 2009 12:11:04

Hey guys,

sorry but I missed all these replies and never bothered to follow up.

Berni, I wanted to connect the MCLK to the MCU in this case because my intended application was an Asynchronous Isochronous USB device - that info was missing from my original post. In this case you have to connect your MCLK to the MCU in order to provide the reference clock. This is exactly what XMOS have done in their reference design. However, what I was trying to understand was the limitation of all the I/O being clocked at 100MHz even if you use an external MCLK - i.e. there's no way of using an external clock to directly clock the I/O. Perhaps this doesn't matter too much for I2S as it is a clocked protocol, but for SPDIF it would be awful and is why they reclock the SPDIF output using the MCLK in the reference design.

Shareef.
sjalloq_xmoslinkers
 
Posts: 7
Joined: Wed, Sep 02 2009 13:23:14

Re: External clock

Postby lilltroll_xmoslinkers » Mon, Nov 23 2009 20:30:48

OK, now I follow. The S/PDIF is a way to create problems in only a 1 meter long shielded interconnect cabels at 1.4Mbit/s 8-). Sounds stupid to me at the year 2009.

I also checked out how XMOS had solved the S/PDIF jitter dilemma when I first saw the card, since you proably want to avoid the need for 'adaptive reclocking' at the reciever side.
lilltroll_xmoslinkers
 
Posts: 30
Joined: Mon, Oct 26 2009 9:26:42
Location: Sweden, Eskilstuna

Re: External clock

Postby Berni_xmoslinkers » Mon, Nov 23 2009 20:59:47

Well i don't know what idiot engineer came up with the bright idea of clocking the whole thing over that piece of coax cable. They are fixing the mistake tho and using there own clock to run the guts of stuff.

This problem only happens when you interface a DAC or ADC over SPDIF as jitter only causes problems in the analog world. For purely digital the jiter would need to be absolutely enormous to screw up the bits them selfs. Also if that would happened the SPDIF link you constantly lose sync so what you would hear would be nothing but noise. Thats just how it is in digital it ether works perfectly or doesn't work at all
Berni_xmoslinkers
 
Posts: 30
Joined: Wed, Sep 02 2009 15:13:03

Re: External clock

Postby sjalloq_xmoslinkers » Mon, Nov 23 2009 23:07:54

We're not talking about jitter causing bit errors in the transport medium - I agree that would be horrendously broken - we're talking slight deviations that show themselves up as audible distortion in the reproduced music. Think low frequency as well as high. Wow/flutter in a record player is a an example of the effects you might expect, just to a lesser extent.

The reference design doesn't really take care of the SPDIF jitter problems as well as you theoretically can. I realise it's one of those topics that causes a lot of friction so I'm going to build it and see how it performs. Changes I plan on making are dropping the optical output and using a transformer coupled BNC output. Using a high quality master clock and a separate power supply for the clock. However, this is all academic if you can feed I2S straight into your DAC but a lot of people can't so you need to cater for both.

lilltroll - one way, allegedly, to reduce the problems associated with SPDIF (coax) is to always use a cable longer than 1.5m. I saw some interesting TDR plots on the web somewhere along with a good description by an RF engineer. The problem is made worse by the fact that most commercial gear is designed to pass EMC tests rather than perform as well as it could. All very interesting... :)
sjalloq_xmoslinkers
 
Posts: 7
Joined: Wed, Sep 02 2009 13:23:14

Re: External clock

Postby Berni_xmoslinkers » Tue, Nov 24 2009 5:09:47

Well making stuff pass those tests is more inportant than making it work good, cause if the tests fail thy cant even sell the thing.

Well your clocks probably are not the reason why you hear errors in your audio, it might be that the impedances are not matched properly or that your signal you put in the output matching circuit doesn't have enough umph (Too little current or too slow rise/fall times). Or it could just be the bounced back signal from the other end messing it up.(operantly the cinch connectors used on SPDIF are sead to be horrible for the job)
Berni_xmoslinkers
 
Posts: 30
Joined: Wed, Sep 02 2009 15:13:03

Re: External clock

Postby sjalloq_xmoslinkers » Tue, Nov 24 2009 9:39:56

Berni, I never said I had any errors in my circuit. I thought we were talking theoretically on the best way to implement the design. But yes, you are thinking along the same lines as me...make sure you buffer the output correctly, match the impedance from source to receiver which will by definition minimise any reflections.
sjalloq_xmoslinkers
 
Posts: 7
Joined: Wed, Sep 02 2009 13:23:14

Re: External clock

Postby lilltroll_xmoslinkers » Tue, Nov 24 2009 11:31:35

If I do no rember wrong, you usally use [fs] (not micro, not nano, not pico second) when writing out the audioable jitter deviation that can be heard of the human ear.

You can easily show how senitive the THD is for timing errors of the sampling interval in theory.

The humar ear has a high tolerance to harmonic distortion, and typically you can add upp to 1% of second tone to a sine-wave without detection by the human ear.
Timing errors on the other hand generates non harmonic dist, which is much more easy to detect for the ear.

Creating a clock with a fs precision regarding to deviation should not be seen as a trivial task from my perspective.
lilltroll_xmoslinkers
 
Posts: 30
Joined: Mon, Oct 26 2009 9:26:42
Location: Sweden, Eskilstuna


Return to Silicon Devices


cron