Routing 32Mhz clock - Page 1
Forum section: electronics / beginners

author: Bluestreak66
author_rank: Regular Contributor
timestamp: July 05, 2013, 05:31:06 am
content: 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

author: Unknown
author_rank: Unknown
timestamp: July 05, 2013, 06:08:17 am
content: 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.

author: marshallh
author_rank: Unknown
timestamp: July 05, 2013, 06:14:48 am
content: 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.pdfhttp://www.signalintegrity.com/Pubs/straight/clockskew.htmI don't know anything about your design but my guess is that you would benefit from a 4layer board.

author: Kremmen
author_rank: Super Contributor
timestamp: July 05, 2013, 06:16:53 am
content: Erm... 5.3 ps/m provided your original estimate was correct. Milli - thousand, you knowBut 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.

author: Unknown
author_rank: Unknown
timestamp: July 05, 2013, 06:18:59 am
content: 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.

author: Bluestreak66
author_rank: Regular Contributor
timestamp: July 05, 2013, 06:43:22 am
content: 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

author: Unknown
author_rank: Unknown
timestamp: July 05, 2013, 06:47:55 am
content: The protocol looks to be asynchronous. You should be OK, I think.

author: Bluestreak66
author_rank: Regular Contributor
timestamp: July 05, 2013, 07:03:09 am
content: 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.

author: Unknown
author_rank: Unknown
timestamp: July 05, 2013, 07:09:19 am
content: 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%20oscillatorIt's a little more involved than a crystal, but only has three leads - Vcc, GND, and output.

author: Bluestreak66
author_rank: Regular Contributor
timestamp: July 05, 2013, 07:35:38 am
content: 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.

author: codeboy2k
author_rank: Super Contributor
timestamp: July 06, 2013, 07:20:48 am
content: 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 minerAt 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

author: CarlG
author_rank: Regular Contributor
timestamp: July 06, 2013, 01:03:29 pm
content: 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.

author: cthree
author_rank: Frequent Contributor
timestamp: July 07, 2013, 03:09:51 am
content: 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.

author: Bluestreak66
author_rank: Regular Contributor
timestamp: July 07, 2013, 03:53:44 am
content: Quote from: cthree on July 07, 2013, 03:09:51 amOne 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.Quote from: CarlG on July 06, 2013, 01:03:29 pmI 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.Quote from: codeboy2k on July 06, 2013, 07:20:48 amI'm suprised that your the only one who has caught on to what this project is

author: codeboy2k
author_rank: Super Contributor
timestamp: July 07, 2013, 07:35:17 am
content: QuoteI'd like oneThose 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 hereXO52CTFLNA32M. 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 Tr/(2*Tpd), where Tris the rise time, and Tpdis 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 involvedIs 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!

author: M. András
author_rank: Super Contributor
timestamp: July 07, 2013, 10:26:47 am
content: and at what price point will this be?