Routing 32Mhz clock

[Bluestreak66]

I'm routing a 32Mhz clock signal to multiple devices across a pcb. How critical is the delay at 32Mhz? Any pointers on how to route this? It's going from a single point to 16 devices in 4 groups of 4 on a 2 layer PCB. The devices have an internal PLL that will multiply this to ~300mhz. Also how would you generate this signal? The original design show a 32Mhz crystal feeding into a dual schmitt trigger buffer and then into two banks of chips. Thanks

[duskglow]

The important thing here is to know what the period of a 32MHz signal is.  By my calculations that's 31ns.  It looks like the propagation speed through copper is about 5.3ns per meter.  So you'll have about, umm... 53ps? of delay per millimeter.

What kind of devices are you routing this signal into?

Of course, someone tell me if I'm wrong.

[marshallh]

1. What is the clock used for? Internal logic? What about busses between the asics?
2. Is the clock used for source synchronous busses, or is it a global clock?
3. What are the IO inputs used on the asics?

Assuming that the clocks were not used for any communications between asics, I would just use a 32mhz oscillator (3.3v), with proper termination. Use a tree distribution. It's basically a binary tree fanout. Google it if you don't know what I mean.

Read this for general tips:
http://www.altera.com/literature/an/archives/an075.pdf

http://www.signalintegrity.com/Pubs/straight/clockskew.htm

I don't know anything about your design but my guess is that you would benefit from a 4layer board.

[Kremmen]

Erm... 5.3 ps/m provided your original estimate was correct. Milli - thousand, you know

But to the OP's question: the critical delay depends on your circuit, not on the clock signal itself. 32 MHz is not that high a frequency; probably you can safely ignore possible delays bu if not, just equalize the track lengths until your problem goes away. You should buffer the oscillator to make sure it won't get overloaded. I would pick a ready made chip oscillator of which there are lots at say Digikey. Just make sure it has a reasonably robust output stage.
As to routing, no mysteries but the usual precautions should be observed: avoid noisy signal traces and components such as SMPS; minimize clock signal loop area to avoid noise pickup; avoid sensitive analog signals if any, yada yada.

[duskglow]

Ahh.  hence the question mark.  I had a feeling I got it wrong.  Also, hence me asking what kind of signal he was routing it into, because it struck me that we didn't have enough information - we could tell him how much delay to expect, but not whether it would affect his circuit badly.

[Bluestreak66]

The asics are SHA256 hash Processors. The clock drives an internal PLL that bumps up the frequency to ~300 to do the hash calculation. Communication between the asics is not directly affected by the clock. The chips only have 6 main I/O pins. They chain together and the data is shifted from the first out through the chain and the result is reported back via a bus. There will be two chains on the board so it will have 4 I/O connected to the micro. 4 layer board would be optimal but it more than doubles the cost per board. I think with some careful routing it is possible to do 2 layers. It seems to me that the delay wouldn't matter as much a jitter would.  I still thinks I will try and minimize it though. Atached is the data sheet for the asics. Thanks

[duskglow]

The protocol looks to be asynchronous.  You should be OK, I think.

[Bluestreak66]

Ya didn't think It would be a huge concern. I was just concerned because there are a few others building boards off the same design I am and are getting lots of errors which seem to be related to clock signals. Looking at one of the designs it looks like one of the clock signal snake throughout the board in and out of multiple vias and under some power traces which may be the issue. Can some one point me to one of the chips Kremmen mentioned? I seen some on digikey but they seem a little to complex for what I'm doing. I've never done a design that had one clock for multiple chips usually just a crystal per chip. I figured It's better to ask on here then to get the boards made and realize I did something wrong. Thanks for the input.

[duskglow]

I'm guessing that the buffering was what the schmitt trigger was for.

As far as chip oscillators go, I think this is what he was referring to:

http://www.digikey.com/product-search/en/crystals-and-oscillators/oscillators/852334?k=32MHz%20oscillator

It's a little more involved than a crystal, but only has three leads - Vcc, GND, and output.

[Bluestreak66]

Ok thats what was use in the original design. Would there be any difference in using a schmitt trigger for each set set of Asics or on the flip side just using a single schmitt trigger for all of them? The original uses a dual.

[codeboy2k]

hmmm.... nice chips.. 16 x 2W = 32W... 16 x 300 M Hash/s = 4.8G Hash/s ....

4.8G Hash/s @ 32W ....that is a pretty good bitcoin miner  

At electricity rates of 0.25 per KWh it will cost less than $100/yr to operate if it operates 24 hours a day, and will possibly generate 1 bitcoin in about every 7-10 days or so

[CarlG]

I would strongly advise at least a four layer board with 100 um core for GND and the ASIC core supply. At 300 MHz, discrete capacitors become very inefficient. You'll need the plane capacitance. I guess this is not a hobby project, so I would not take the risk of having random problems to deal with, rather than to have it working properly from the beginning. For the clock routing you might be able to get GND opposite the clock traces, but you'll have bad coupling with just at 2-layer board. Also, for EMI/EMC reasons , I don't know about regulation other than EU, but even if your product isndoesn't need to pass any EMC tests, you probably don't want this board to generate so much EMI that it everything else around it gets non-functional, or your product to get killed e g if anybody uses a cell phone around it.

[cthree]

I would strongly advise you use a local oscilator for each device that needs one unless you have a specific requirement to drive everything off of the same synchronous clock signal. Keep the oscillator layout as tight as possible to avoid crosstalk and noise and makes sure you put a ground plane under and around the oscillator circuit. Trying to debug a wonky distributed clock signal is going to make you sad. I'll with you spent the extra 70 cents I guarantee it.

Google for "Oscillator PCB layout" you will find documents from Atmel, Ti and everyone else on the recommended layout best practices from oscillators and crystals. The Ti one talks about distributed clock signals using a clock driver. By the time you go to that problem you could just drop in another crystal and two caps and call it a day.

[Bluestreak66]

I would strongly advise you use a local oscilator for each device that needs one unless you have a specific requirement to drive everything off of the same synchronous clock signal. Keep the oscillator layout as tight as possible to avoid crosstalk and noise and makes sure you put a ground plane under and around the oscillator circuit. Trying to debug a wonky distributed clock signal is going to make you sad. I'll with you spent the extra 70 cents I guarantee it.

Google for "Oscillator PCB layout" you will find documents from Atmel, Ti and everyone else on the recommended layout best practices from oscillators and crystals. The Ti one talks about distributed clock signals using a clock driver. By the time you go to that problem you could just drop in another crystal and two caps and call it a day.

One single clock is needed all the ascis have a pll that is controlled by the micro the bus data out from the asics depends on the clock frequency and the multiplier. I've read several app notes from ti and a few others. I plan on routing the clock in a star configuration on the  top plane and going though a single via once it get near the asics most of the board is flooded with a copper pour ground plane on top and bottom with large power planes on  the top layer around each group of asics.

I would strongly advise at least a four layer board with 100 um core for GND and the ASIC core supply. At 300 MHz, discrete capacitors become very inefficient. You'll need the plane capacitance. I guess this is not a hobby project, so I would not take the risk of having random problems to deal with, rather than to have it working properly from the beginning. For the clock routing you might be able to get GND opposite the clock traces, but you'll have bad coupling with just at 2-layer board. Also, for EMI/EMC reasons , I don't know about regulation other than EU, but even if your product isndoesn't need to pass any EMC tests, you probably don't want this board to generate so much EMI that it everything else around it gets non-functional, or your product to get killed e g if anybody uses a cell phone around it.

I am well aware of the importance of plane capacitance and  that is the reason for the large power planes around the asic groups I will also be having this board made with .8mm pcb in hopes it will increase capacitance as well as aid in cooling. ( let me know if you think this is a good idea or not) This is an opensource project that will probably not be sold its mainly for me and a few others so no EMI requirement other than the practical aspect, but I plan on having several hundred boards made. If I cant do this in 2 layers I dont think I will continue the project as i'm trying to keep cost down and a 4 layer board would more than triple the price. I will probably have 10~15 board made just to see if the 2 alyer design is practical.

hmmm.... nice chips.. 16 x 2W = 32W... 16 x 300 M Hash/s = 4.8G Hash/s ....

4.8G Hash/s @ 32W ....that is a pretty good bitcoin miner  

At electricity rates of 0.25 per KWh it will cost less than $100/yr to operate if it operates 24 hours a day, and will possibly generate 1 bitcoin in about every 7-10 days or so

I'm suprised that your the only one who has caught on to what this project is 

[codeboy2k]

I'm suprised that your the only one who has caught on to what this project is 

I'd like one

Those chips look dead simple with only 6 i/o lines and everything serial i/o, I am sure you can be successful with a 2 layer board.

Make the bottom layer an unbroken ground plane; you probably already know this. Use a 120mil trace width for your clocks, this will give you about 48-50 ohm surface microstrip on standard 1.6mm FR4. Definitely use a clock can oscillator, not just a crystal. For example, this one here XO52CTFLNA32M.  It can drive up to 50pf and has a 10ns rise time.  However, be wary of the clock drive capabilities, and make sure that the trace lengths are the same if you want to minimize skew. In this particular can oscillator, 50 pf is not enough to drive 16 clock inputs because they are 3.4 pf (typ) each. So you definitely need to buffer each group of 4 ASICs. The rise time at 10ns is no problem, you don't need to worry about clock terminations.  The formula is you usually need a series termination if the trace length exceeds T_r/(2*T_pd), where T_r is the rise time, and T_pd is the propagation delay, typically 150ps per inch in FR4. This means you need to series terminate the clock lines only if the trace length to the load (i.e. the first buffer) is more than 10ns/(2*150ps) inches, or 33 inches.  I think your board will be smaller than 33 inches, thus no need to worry about clock terminations.

Also, since these are essentially independent hash compute units, I don't think that a few ps clock skew from one chip to the next will really cause any trouble. You will have more trouble with impedance mismatches, drive and reflections I would think (but again, a 32Mhz clock with 10ns rise time is not that fast)

But since your are going 2 sided, you wont have any vias, and so you will only see reflections at your branch points. you could put a PCB pad and a zero ohm resistor at each of your branch points to go downstream.. if you find that you have clock problems on the final board, you can try to stop any reflections that come back to the branch points by replacing the 0 ohm with a 22 ohm .  At least you will have the pads in place for it.

This sounds like a fun project.. I wish I was involved

Is this a USB peripheral, or a standalone unit with ethernet and an ARM chip, running linux.. thats way more design work but also higher cool factor.

good luck!

[M. András]

and at what price point will this be?