FAQ13.pdf

(4 KB) Pobierz
Maximum Clock Input Rise/Fall Time
Q: What happens if a system design fails to meet the PowerPC specification for
maximum clock input rise/fall time?
A:
All of our microprocessor's input and output timings are referenced to when
the SYSCLK crosses the Midpoint Voltage. A slower rise time clock will still
cross the Midpoint Voltage but will require the system designer to plan his
timing budget to allow for additional uncertainty in when this threshold
crossing actually occurs on chips that have to communicate with one another.
We have to specify a rise time on the clock to reduce the uncertainty
associated with this crossing of the threshold voltage. By specing 2ns rise
time max from .2 to 2.4V, we can assume about .5ns uncertainty in the reference
for input and output timing. We use that .5 ns in specifying the worst case
input and output timing at maximum bus speed.
For example, if we know the part requires 2nS minimum setup time to a perfect
clock (one with infinite rise time or zero uncertainty in crossing the
threshold), then we can add .5ns of uncertainty in crossing the Midpoint
threshold for a clock that might vary in rise time from 1-2ns. We probably add
another 150ps for potential jitter, and round up to a minimum of 3ns set-up
time within the 15ns period of a 66MHz bus. That way if the designer gives us
3ns of setup time and a clock with a rise time of anywhere from 0-2ns, we are
guaranteed to have adequate setup.
Likewise for input hold time, if the part requires zero hold time to a
perfect clock, we can spec 1ns minimum required input hold time and feel
confident that if the designer meets that we will be unaffected by the
uncertainty in the rise time of his clock.
Output times are more of a problem to the logic we are driving. A slower ramp
introduces more uncertainty in how long we hold a signal or how soon it is
valid. If the logic we drive (or are driven by) is clocked with the same
slowly ramping signal then the only uncertainty is the difference in actual
threshold switching voltage between the parts.
Suppose a customer wanted to use a crystal clock with rise and fall times of
4ns, it could add uncertainty to when we sample the input (perhaps 1.0ns -
half of the difference between spec and actual). It also could add uncertainty
to how long they need to hold the input valid (maybe adding 1.0ns to our input
hold time requirement).
The customer should account for this uncertainty by adding or subtracting it
from our published specification. For an application using the PID6-603e, for
example, the following specifications should be adjusted for system timing
analysis
In Table 6 pg 7:
Assume spec2,3 rise/fall time increases from 2ns max to 4ns max (1 additional
ns of uncertainty)
Then for input timing shown in Table 7 pg 8:
change spec 10a (input setup) to 4ns min (add 1ns).
change spec 10b (input setup) to 6ns min (add 1ns).
change spec 11a (input hold) to 2ns min (add 1ns).
change spec 11b (input hold) to 2ns min (add 1ns).
And for output timing shown in Table 8 pg 10:
change spec 12 (output enable) to 0ns min (subtract 1ns).
change spec 13a (output valid) to 12ns max (add 1ns).
change spec 13b (output valid) to 11ns max (add 1ns).
change spec 14a (output valid) to 14ns max (add 1ns).
change spec 14b (output valid) to 12ns max (add 1ns).
change spec 15 (output hold) to .5ns min (subtract 1ns).
change spec 16 (output high impedance) to 10.5ns max (add 1ns).
change spec 18 (artry high impedance before precharge) to 10ns max (add 1ns).
This additional uncertainty is hard to accommodate in the 15ns period of a
66MHz bus. But in a 33MHz design, the designer has a 30ns period to work with.
At 66MHz, 1ns is a lot of uncertainty in a clock period of 15ns. At 33Mhz, 1ns
of uncertainty is a lesser part of the period.
THE SECRET IS FOR THE SYSTEM DESIGNER TO ANALYZE IF HIS SYSTEM
WILL TOLERATE THE INCREASED UNCERTAINTY IN THE TIMING BUDGET.
Our parts should switch at the same relative times with regard to the threshold crossing but
the threshold crossing (and any associated variability, or jitter, caused by noise around
that threshold) needs to be comprehended between our chips and chips that we
communicate with.

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin