Clock routing dilemma
Question for the gurus here:
On the board below, I have clocks coming in from the left and being distributed to two ICs. The pads you see are 50R resistors. SDATA, LRCK, and BCK are all relatively low-frequency clocks, but MCK is running at 24.576MHz.
My question is about how best to route MCK. The desired path is indicated by the brown line, and I could push it through almost as depicted, but I am concerned about crosstalk.
Other options would be jumpering MCK over this block via the topside, or under the board.
As for routing on the bottom layer, I am concerned about routing under clock lines. Routing completely around these blocks would create very long traces, which is not an option.
How would you route this signal?
I would route it as indicated but use through hole resistors. This will give more clearance.
I recognise the situation; you have forced yourself in a tight corner making it difficult to route the last trace. Widen up the design.
As MCK and the othet clock dsignals are perpendicular to each other you will have minimal interaction.
You seem to be busy, hu ? ;)
I think the solution relies on the resistors. Sorry Elso, but I don't think using THT resistors would be a good idea. They add a lot of inductance, whithin the resistor itself, and with the leads too.
If I understand clearly from your drawing (hard to see without parts' silouhette), you drive two resistors with one signal (let's call this side the input), and the other side of the resistors (let's call 'em outputs) feeds the two ICs (which ones, I wonder :p) separately.
If I'm right in my deductions, I think you'd better use a SMT resistor array. Vishay makes nice ones with a 50 mils or 25 mils pitches, which would fit nicely on you board as they look like SOIC or SSOP packages (Sorry, I do not have any link or reference handy, but I'll post it as soon as I refind it). The advantage is that they provide some space beneath them (more than a 0805 or 1206 part) that allow you to route some signals under the part. As a drawback, this implies that you also route MCK through this array...
And speaking of crosstalk... Trying to avoid it is a nice rule (and I also try to do it), but I wonder what happens inside an IC with a 26 mils pitch... :confused:
Hope this helps
Found it !
Aging is not an everyday's joy :( I found the link in my bookmarks. Try to reroute with this part, and tell us :p
Through Hole Resistors
I don't have absolutely no problems with through hole resistors; even in a 100 MHz clock!;)
I didn't expect you to have problems :p. What I just meant is that when frequency increases, parts do not behave as ideal ones, and parasitic (R, L, C) can ruin a lot of efforts. And SMT parts usually have lower parasitics than THT ones. I'm sure you can obtain even better results with your asynchronous reclocker if you try to build it with only SMT parts (knowing you, perhaps you've already tried, hu ?).
Thanks for the input guys. A SOIC resistor array was just the ticket.
A couple of 32mil leadless arrays would probably have been best, but I decided they weren't worth the aggravation of trying to solder more fine pitch devices!
general thoughts on clock crosstalk
Slower clocks still have the same edge speed, so they might produce almost the same amount of crosstalk as a higher frequency clock. As they are synchronous to MCKL and do not contribute to timing accuracy (maybe with the exception of WDCLK on older multibit DACS), I would not worry about crosstalk into them.
On the other hand, SDATA is synchronous to MCKL (albeit with some delay), but also aperiodic, hence it might induce pattern-dependent crosstalk into MCKL, i.e. the device receiving the MCKL might detect the edges at different times depending on what data there is on SDATA.
In a modern system with an integrated filter DAC I would suggest the following scheme: use a high quality oscillator close to the DAC and route the clock through a buffer with a well-decoupled supply, using no or only a small series impedance in this line. A separate buffer should distribute the clock to all other parts of the circuit. The SDATA (and all other derived signals) should be decoupled at their buffer outputs with a relatively high-value SMD resistor, i.e. 100 - 470 R.
Thanks for the response. All of my clock signals are actually generated at a counter, buffered, with a single line driving two chips per block (the upper and lower ICs in the gif above). The board will have 3-4 of these blocks, so there are constraints on how short clock traces can be made.
Does your statement about series resistance still hold? My thought was that since trace lengths could reach 3-4 inches and pass by other circuit blocks it might be advantageous to decouple all clock lines.
Depends on what those chips do, i.e. if they are jitter sensitive. If you have a modern integrated DAC some place and a master clock close by, all I would worry about is not to corrupt the MCKL clock line that goes from the oscillator to the DAC and controls all internal timing. If you are using a digital filter / multibit DAC approach, the digital filter usually controls the timing of the DACs, but you also reclock the WDCK lines with a 74F74 that is driven from the master clock.
If you don't have a master oscillator and all those nice chips are part of a semi-discrete PLL, my statement would probably not hold.
I like to use a small series resistance (20 - 90 R) on critical lines because it keeps the worst switching transients from the receiving input. If it is too large, the edges become even cleaner but are so round the input gate has too much freedom to decide when it is time to switch. The same goes basically also for non-critical inputs on the same chip because the input gate draws a high current while the signal is between valid states.
For non-critical input on other chips all you have to worry about is that the digital information gets transmitted correctly, so you have to look at the setup times given in the timing diagrams. In many cases, you can get away with 1 k.
|All times are GMT. The time now is 04:02 AM.|
vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2017 DragonByte Technologies Ltd.
Copyright ©1999-2017 diyAudio