setup, hold, and signal timing skew inconsistencies
wally at eng.adaptec.com
Tue May 11 17:08:53 PDT 1999
* From the T10 Reflector (t10 at symbios.com), posted by:
* wally at eng.adaptec.com (Walter Bridgewater)
By duty-cycle skew, I mean the difference in time between when
clock (REQ/ACK) is low and when clock is high.
Ideally, for fast-80 DT, for each level of the clock (low/high), you would
have 12.5ns (25ns/2). But, because of, almost normal considerations,
you might have a clock (ACK/REQ) at the receiving chip of
11.3/13.7ns, low/high time or high/low time.
So, another way of describing duty-cycle skew, is to say how much
the clock deviates from the ideal 12.5/12.5ns high/low timing.
The duty-cycle skew could be as bad as 10/15ns and not violate
clause 9.2.20 in table 32 of SPI-3r5.
The are many things that cause duty-cycle skew, besides the obvious
ones in the transmitter and receiver chips. Things like a
different delay time in the plus and minus signals in the cable
will cause duty-cycle skew. For a given pair of wires in a cable,
1 of the wires could be longer than the other, but we really don't
even have any cable spec for this at all.
So, even if the transmitter does a good job of having low duty-cycle
skew, other things can still increase it, beyond the control of
> * From the T10 Reflector (t10 at symbios.com), posted by:
> * Richard Moore <r_moore at qlc.com>
> How big is this duty-cycle skew? I was trying to figure out what
> it means and my best guess is that this is due to a difference in
> slew rates on rise and fall of the clock signal -- am I right? If
> so, perhaps "slew rate skew" would be a better name for it. And if
> it's a slew rate problem, then shouldn't the effect of this be
> allocated to the transmitter, rather than the cable, in the timing
> -- Richard
> >* From the T10 Reflector (t10 at symbios.com), posted by:
> >* wally at eng.adaptec.com (Walter Bridgewater)
> >I don't think it's fine to say that DT technology is better
> >than ST technology, there aren't any facts to support this.
> >Every time I have tried to study this issue, letting all other things
> >be equal, it appears that ST is better. The duty-cycle skew is the
> >main thing that makes DT un-desireable. All things being equal, and
> >using cables of great bandwidth, ST is much better than DT, since ST
> >doesn't have the duty-cycle skew problem.
> >As you degrade the cable bandwidth, is there a point at which having
> >the slower clock speed, but with more skew pays off? By the time
> >the cables have degrade this far from the ideal, is the ISI from
> >both the clk and the data stopping and starting killing the performance
> >and any advantage from having slower clock with more skew lost?
> >> * From the T10 Reflector (t10 at symbios.com), posted by:
> >> * Jim McGrath <Jim.McGrath at quantum.com>
> >> *
> >> Richard,
> >> I think its fine for us to say that DT technology is better than ST
> >> technology, even slow speed ST technology - I think it would simplify
> >> everyone's life going forward if DT could be used as the
> >preferred protocol
> >> for LVD signaling. I could also see where some of the
> >timings for ST at
> >> lower speeds might have been specified in a way that make ST
> >look worse than
> >> DT, even if that is not technically true - I think we have
> >gotten a lot
> >> better over time at doing the timing budgets.
> >> On your specific points, if we've made a mistake somewhere
> >in going over
> >> from SCSI-2 to SPI-3 in the ST timings, then maybe George
> >can comment on
> >> whether these issues are in practice editorial in nature?
> >> Jim
> >> >
> >> > -- Richard Moore
> >> > QLogic Corp.
> >> >
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com
More information about the T10