[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: PCI Clock
> What are the implications of this long length , any ideas to over come?
The two most obvious implications are (1) your card would be out of spec and could not claim to be PCI compliant, and (2) your card's clock would be skewed rather late. The latter could cause Hold time violations on signals being received by your card, and Setup time violations on signals sent from your card, especially at 66MHz.
You might compensate for the late clock, either by carefully tuning things in the PCI interface chip you use (it would have to deviate from the component timing specs in the PCI Spec, thus making it unique to your card), or by inserting something like a PLL in the clock path.
A PLL is legal for 66MHz PCI operation (and there are provisions in the PCI Spec for using a PLL with spread-spectrum clocking); but all 66MHz PCI devices must also operate at 33MHz, where the clock is 0-33MHz, and a PLL is not appropriate in that range.
A third implication of using an out-of-spec clock trace, is that the reflections might line up wrong. The system (i.e., motherboard) designer is counting on your card having exactly 2.5 inches on that trace. By making it longer, it has more capacitance than anticipated, and because the trace is unterminated, the reflection arrives at a different time. In certain cases, that might cause unexpected things to happen, which the system designer didn't need to consider. You might avoid that by adding some sort of clock buffer at the 2.5 inch point on the trace, but an ordinary (non-PLL or DLL) buffer only makes your late-clock problem that much worse.
Adding termination on the end of the clock trace is also not advisable because the system designer didn't count on it, and there is no provision for it in the PCI Spec. It is likely to significantly reduce the clock amplitude below spec, and make many systems fail.
If the clock is 7 inches long, how are you able to keep all the bussed signals under 1.5 inches?
Regards,
Andy