Could I use a single oscillator to clock multiple devices?

[attie]

Hi all, I'm new around here :-)

I'm working on a brushless DC motor controller, primarily as a learning exercise, but also because I want to...
When/If it works suitably well, I will build 4 of them and move onto designing a flight control board in order to build a quad copter.

I've managed to make excuses to include a CPLD in my current design (XA9572XL) to tune up my VHDL skills, along side an ATMega328p (I am very familiar with AVRs already).
Initially I designed in a 20Mhz ceramic oscillator (FXO-HC736R-20 - http://www.foxonline.com/pdfs/FXO_HC73.pdf), this would clock the CPLD which will use the signal and buffer it, the buffered signal will then be passed onto the AVR.
The CPLD is pretty full of control and commutation logic at the moment, and simply removing the buffered clock output allows the 'Fit' step to succeed (is that the correct terminology?).

This causes me to raise this question - I know that I could probably optimise my VHDL somewhat, but I want to ask the question anyway.

Q: Would it be possible to drive both the CPLD and AVR from the oscillator? Or is that a stupid and outlandish proposition?

I understand that using a plain crystal like this would not work, but as the FOX oscillator consists of crystal, oscillator and a seemingly weedy buffer, I would imagine that it should be fine!

Thanks!
Attie

[gxti]

Yes, it will work fine. For what it's worth, "ceramic oscillator" means something different - a 2 or 3 terminal passive device sort of like a cheaper and less precise crystal. But a canned oscillator like the one you linked to can drive multiple inputs easily.

[AlfBaz]

I for one, would like to hear more discussion on the matter.
3ns rise and fall times and 15pF load capacitance from the oscilator... I can't help but feel there will be issues such as signal reflections, drive strength woes and layout concerns

[nctnico]

Its tricky. You'll need to read the datasheets carefully and maybe do some test and measurements to see if it would work. An oscillator circuit usually consists of an inverter so there is an input and output. The output signal level is not high so it may not be able to drive another oscillator input. The best way is to use a seperate oscillator module and drive the clocks from there. Its good practice to put a 33 Ohm (or more) series resistor in each clock trace to reduce reflections and HF emissions.

[attie]

Thanks for the replies!

@gxti: I was under the impression that a crystal and ceramic resonator were (almost) interchangeable parts that 'wobbled' at a given frequency and tolerance. To then make something useful out of it, you hook that up to a circuit (amplifier, feedback etc) to create an oscillator ('wobbler' + circuit) that provides the clock signal. I never was much good at terminology... apologies.

@AlfBaz: Me too! That's why I asked... admittedly there was no mention of this in my question, but it was hopefully implied.

@nctnico: Would you put the resistor close to the 'consumer' or just after the trace branches?

I think it should work, but just wanted to check with others who may have experienced this in the past.
The clock inputs between the ICs are close, keeping the trace lengths to a reasonable minimum.

[CarlG]

The FOX device is a "crystal oscillator" (XO), i.e. this oscillator contains a crystal for setting the frequency.
EDIT: I was a bit too quick when reading the datasheet, which is a bit confusing. On the first page they state it's a crystal oscillator, but the ordering information obviously indicates that the HC-version is based on a ceramic (resonator?)!

You can make an oscillator circuit based on either a crystal OR a ceramic resonator, or even without any of them, e.g. an "RC-oscillator" (as well as some other techniques e.g. MEMS).

Note the "Output load" parameter, max 30pF for frequencies up to 125 MHz. With two inputs + trace capacitance you may exceed that limit. Most MCUs have XIN and XOUT pins, where you can connect an external XO to XIN and use the XOUT as a buffered output. I would feed XOUT to the CPLD instead of splitting the XO output to two pins. Otherwise I would buffer the oscillator with a single gate such as LVC04 or similar before distributing to the MCU and CPLD.

The damping resistor(s) shall be placed close to the output driver, one for each trace.

//C

[AlfBaz]

Note the "Output load" parameter, max 30pF for frequencies up to 125 MHz.

They offer 3 versions the model number he shows is the 15pF version

I couldn't find the load cap spec for the atmega but for a pic32 its 50pF

With two inputs + trace capacitance you may exceed that limit.

I'm thinking that would be the case as well. If you have 2 devices with a capacitive load of xpF would the total become 2xpF?

Most MCUs have XIN and XOUT pins, where you can connect an external XO to XIN and use the XOUT as a buffered output. I would feed XOUT to the CPLD instead of splitting the XO output to two pins. Otherwise I would buffer the oscillator with a single gate such as LVC04 or similar before distributing to the MCU and CPLD.

Good idea!

[attie]

Thanks CarlG - I had considered using the buffered output from the AVR, but it would require a little rework to route, which lead me to thinking about buffering it in the CPLD, and then asking the question about driving both.

The CPLD (XA9572XL) states 10pF input capacitance (I assume the clock inputs have similar stats to the I/O as I can't find anything explicit in the datasheet), and I can't seem to find any numbers for the AVR...
10pF out of the available 15pF loading seems pretty close to me, so driving a second clock input probably isn't a great idea... I'll try to avoid it.

Thanks all!

[Neilm]

One question, are these two devices communicating with each other? If so you might find there are problems if signals change at the clock edge. Generally, there is a spec on devices to say how long the signal has to be stable for before the clock edge.

Neil

[CarlG]

Note the "Output load" parameter, max 30pF for frequencies up to 125 MHz.

They offer 3 versions the model number he shows is the 15pF version

Hmm,..sorry, I can't see that, but if you say so...as far I can see the "Model description" is not coupled to Output load. I only see that Output load = "Standard" is specified to 30 pF and "Operational to 125 MHz" is specified to 15pF. My interpretation of that is that it's OK with 30 pF for a 20 MHz part. Or is there some additional information available apart from the referenced datasheet?

Best, C

[CarlG]

Attie, since it only seems to be a single item, and you seem to have the board ready already, it might be better to rework your board as little as possible. For this one I would consider doing as you proposed, splitting the oscillator output to both the MCU and the CPLD. I guess you have pretty good control over temperature and supply voltage, and hopefully you have a scope so that you can check the waveform, so the risk is pretty small it will fail. It's no medical equipment after all (I hope ).

A small cap (2-3 pF) between the probe tip and the osc output make it possible to observe the waveform with minimal effect (from the cap load of the probe), but not the high/low voltage levels.

//C

[jahonen]

If in any doubt, use a clock fanout buffer, like CDCV304.

Regards,
Janne

[AlfBaz]

Note the "Output load" parameter, max 30pF for frequencies up to 125 MHz.

They offer 3 versions the model number he shows is the 15pF version

Hmm,..sorry, I can't see that, but if you say so...as far I can see the "Model description" is not coupled to Output load. I only see that Output load = "Standard" is specified to 30 pF and "Operational to 125 MHz" is specified to 15pF. My interpretation of that is that it's OK with 30 pF for a 20 MHz part. Or is there some additional information available apart from the referenced datasheet?

Best, C

Argh, I'm an idiot... Sorry
That was for a data sheet on an oscillator I'm using 

[attie]

Thanks for all your input guys!

I've ended up re-routing the board to clock the CPLD from the AVR's buffered output.
These devices won't be communicating as such - no clocked I/O, just control lines flying up and down.

@CarlG and AlfBaz, I found the wording and table in the datasheet a little murky...

http://www.foxonline.com/pdfs/FXO_HC73.pdf - bottom of page 2

Parameters	Condition	Maximum Value (unless otherwise noted)
Output Load	Standard Operational To 125MHz	15 pF 30 pF

I plan to use a < 125MHz oscillator, so is that 30pF?... or 15pF?
Take 15pF to be safe I think - oh well...

Thanks again!

[CarlG]

@AlfBaz
No you're not! Just a silly mistake like those I do now and then Nema problema

@attie
Glad I could help

[Kartika]

HI
 I have question how to use TCXO with two ICs   see attached photo
possible way "fanout buffer" I read,  but i do not have idea how...

[CarlG]

It's not what  I would recommend but it could work for a hobby project. However, since you have two inputs as load in parallel with C2 you should reduce C2 with the same amount as the C of the trace and input C of U2. That is, if the trace to U2 can be kept  "short". But likely it will be "long" i e probably pick up noise that could disturb the oscillator function. So I'd suggest adding a buffer in between. You'd still need to compensate for the added load though.

You say "TCXO" but that's not what the attachment shows, that's a XO (crystal oscillator) circuit. A TCXO is an integrated device with it's own suppply and one output for a single-ended signal (and of course two for a differential output).

[SiliconWizard]

Yes, it's not a TCXO whatsoever.

And I would avoid doing the above unless you were ultra constrained with cost. You'd need to check that the oscillator would even start in this configuration, given the extra load from the clock input of the second MCU. And its input capacitance will also be in parallel with the parallel capacitor of the resonant circuit, which will also tend to slightly shift the frequency, making it less accurate.

If you want to do something simple and with as few parts as possible, just use an external oscillator. Not the cheapest option of course, but the easiest one, with fewer parts, and no nasty potential issue to deal with.

If the loading from the second clock input causes issues, you could indeed consider adding a buffer, but make sure said buffer will load the signal less than your second clock input, otherwise it's absolutely useless.

This kind of trick would really be only for ultra-low cost designs IMO. Otherwise, just use a proper external oscillator and call it a day. Example: SXO53C3A071-16.000M, on Digikey, $0.75 per 1... (your 16MHz crystal is probably more expensive than that, or at least pretty close.)

[MarkF]

I've been using these Standard Clock Oscillator modules.   Used a 48MHz one in my DIY function generator to drive a pic18f2550 MCU and an AD9834 DDS chip.  No buffering and haven't had any issues.

I tend to avoid the crystal/dual capacitor configuration.  Even if I'm only driving one MCU.

[nctnico]

Yes, it's not a TCXO whatsoever.

And I would avoid doing the above unless you were ultra constrained with cost. You'd need to check that the oscillator would even start in this configuration, given the extra load from the clock input of the second MCU. And its input capacitance will also be in parallel with the parallel capacitor of the resonant circuit, which will also tend to slightly shift the frequency, making it less accurate.

It is not that dramatic. A crystal oscillator like from the picture has an input and output (check the datasheet which is which). The output has a relatively low output impedance so it can drive some load. Using this to drive other oscillator inputs is commonly done.

[Kartika]

Hi I apologies for bad explanation, question is I have desire to replace this with TCXO it is possible.. ?

[PCB.Wiz]

Hi I apologies for bad explanation, question is I have desire to replace this with TCXO it is possible.. ?

Yes, that should be possible.  Of course, the MHz needs to be inside the MCU specs.

You need to check if your TCXO is CMOS out, or clipped sine (0.8V p-p).

If it is clipped sine you will need to AC couple to the XIN pin, via 100pF~1nF

If it is CMOS, you can direct connect to XIN, - it does not matter if you drive both XIN's, or if you cascade XOUT to XIN of slave device, provided the swings are compatible.
(some MCUs have lower swing xtal oscillators, for lower RFI and lower ICC )

[MarkF]

Hi I apologies for bad explanation, question is I have desire to replace this with TCXO it is possible.. ?

That is exactly what I did with the Oscillator module mentioned above.  They have TTL outputs and can drive 5 loads.
I would NOT use the crystal.  These oscillator modules have buffered outputs.

Sorry, I quoted a 5V part before.  Here is the 3.3V version.
   ACHL-20.000MHZ-EK  Standard Clock Oscillator for 3.3V

[Kartika]

Thank you, but I stil heave question from this record... 

https://www.edaboard.com/threads/single-tcxo-for-multiple-ics.380345/

[SiliconWizard]

Oscillators, including TCXOs, have a specified max output load (capacitance). Read datasheets, and check that the added input capacitance of both clock inputs doesn't exceed the maximum rated for the oscillator you select.

Taking a random 16 MHz TCXO, as an example, I can see a max output load of 15 pF.
Now reading the AT86RF215 datasheet, the input capacitance of the TCXO input pin is 5 pF. So, a typical TCXO should be able to drive 2 of those inputs without buffering. BUT: be aware that connections from the TCXO to the input pins will have some added capacitance. You'll need very short connections to both to guarantee a total capacitance <= 15 pF.

So, check datasheets, but it's likely you'd need to add some buffer to be safe. Something like the 74LVC1G17 should do fine.