EEVblog Electronics Community Forum
Electronics => Beginners => Topic started by: dolbeau on September 24, 2020, 11:14:13 am
-
Hello,
I'm trying to route a single-ended parallel bus with a 25 MHz clock [1]. In a perfect world all traces would be the same length, but I'm routing them to a pair of 2.54mm-pitch header (0.1") that are several centimeters apart, so I end up with some major differences in lengths. However, I'm not sure if it really matters at this (historically fast, now somewhat slow) speed, with a period of 40 ns.
In millimeters, my current numbers look like the following (parenthesis are nanoseconds assuming a propagation speed of ~150mm/ns, which I thinks is the right ballpark):
MIN 60.32
MAX 106.43
diff 46.11 (307.3879E-03)
CLK 65.57
REL_CLK MIN -5.25 (-34.9766E-03)
REL_CLK_MAX 40.86 (272.4113E-03)
I've already tuned some of the shorter lanes to push them beyond 60mm so they're not too early before the clock, but I can't shorten the longer ones - and I don't really have the space to lengthen all of them to ~10cm (this is inclusive of the trace length on the daughterboard as supplied by the manufacturer).
Would that kind of differences (about 1% of the period, approximately) be a major issue ? I could redesign by pushing back the headers to make room for more traces, but then every signal would end up much longer (12 to 14cm), I don't know if that would be preferable - in particular as the design uses level-shifters with a specified ~5ns delay already ...
[1] Context here: https://www.eevblog.com/forum/fpga/designing-a-fpga-board-for-a-90s-sparcstation/ (https://www.eevblog.com/forum/fpga/designing-a-fpga-board-for-a-90s-sparcstation/), this is an attempt with yet another FPGA board as the prospective daughterboard (e.g. https://www.ztex.de/usb-fpga-2/usb-fpga-2.13.e.html (https://www.ztex.de/usb-fpga-2/usb-fpga-2.13.e.html))
-
May not even matter, as parallel buses are usually a bunch of data/address lines that do whatever, then they only need to be stable by the time the strobe signals come along. The strobes then are more critical, so shouldn't have much crosstalk, and bounce and runt pulses are avoided. Schmitt trigger inputs may be a good idea too (but may not be necessary for the buses themselves).
I don't know if that's exactly the case here.
Light speed in transmission lines is typically 1ns every 20cm. So 40ns is 800cm, and presumably a fraction of that will be critical, i.e. on the order of 1 or 2 meters. So, most likely it's safe to run through ribbon cables of significant length, let alone a few mismatched PCB traces.
Things to check and confirm: input threshold levels, drive strength, termination, timing and skew between clocks/strobes and data (maybe it's more tightly timed, maybe it's even looser say because 25MHz is the bus clock while bus cycles take several clocks?), uhh, typical data patterns, that sort of thing.
Grounding shouldn't need to be very impressive either, but I would still recommend alternating signal and ground in the headers, if you have that option.
Tim
-
At 25 MHz it's not an issue. The trouble starts when routing SDRAM or DDR buses, but that's at 125 MHz and up.
-
(..) they only need to be stable by the time the strobe signals come along.
If by 'strobe' you mean 'rising edge of the clock signal' (I'm a complete HW newbie), it should be the case, as the standard says: SBus Devices shall sample SBus signals on the rising edge of CLK.
so shouldn't have much crosstalk, and bounce and runt pulses are avoided. Schmitt trigger inputs may be a good idea too (but may not be necessary for the buses themselves).
More stuff for me to look up and understand :-)
Things to check and confirm
Thanks for the advice. I'm not sure how much skew the level-shifters will add, and the standard says this:
- Output hold time after rising edge of CLK (...) 2.5 ns
- Input setup time required before rising edge of CLK (...) 15 ns
- Input hold time required after rising edge of CLK (...) 1 ns
I think this is saying that basically, I have 1ns to read the signal after detecting the clock rising edge - meaning that for any signal that has gotten a head start of 0.4ns because of trace length, I only have 0.6ns left.
In all cases - thanks everyone for reassuring me that I don't have to exactly length-match the 82 signals; I wasn't looking forward to doing that :-)
-
I guess 'strobe' means here when the bus controller latches the bus status to its memory (so when IOREQ and RD are asserted)
-
Yes; typical control signals are momentary, so it doesn't really matter if they drive clocked flip-flops, or transparent latches. You can use 74LS373s or 374s on an ISA bus for instance (AFAIK).
If this is some other format, like if the clock is periodic and even duty cycle (like SPI, for a single-ish bit example, but there are wider bus examples that I don't know of offhand), then it depends when the bus signals are set up; usually this happens on CLK falling edge, leaving maximum time for setup without requiring more complicated timing. For example if the clock is 50% duty and data is set up on the falling edge, then there's +5/-19ns skew per line that will still meet the -15/+1 ns setup/hold shown above, out of a 20ns half-period. (This doesn't leave any room for CLK pulse width variation; presumably there's a few ns for that as well.)
If instead, the bus signals are set up on the same rising edge, then there's a race condition already, and presumably the clock is skewed at least enough to avoid the hold time constraint to begin with. In this case, it is safer to delay the clock than the data; any skew between data lines doesn't matter, as long as no path is shorter than the clock path, nor longer than a full cycle minus the setup time (so, 25ns).
(This is common enough when building buses from logic gates -- you just clock everything at once, *kachunk*, and all the register outputs update in unison. Those values propagate through combinatorial logic and etc., and settle before the next clock's setup time. *Kachunk*, and so the process repeats. This is the preferred way to make state machines, in particular FPGA tools are streamlined to work with this style of construction.)
Tim