setup, hold, and signal timing skew inconsistencies

Fan, Jie jfan at amp.com
Wed May 12 12:04:34 PDT 1999


* From the T10 Reflector (t10 at symbios.com), posted by:
* "Fan, Jie " <jfan at amp.com>
*
Wally,

The skew in the standard including 25 ps/ft is between the pairs. Skew
within the same pair is much lower than this. Currently, we have 12 ps/ft
maxumum within the same pair on our specs for fast 20 and fast 40. If
someone needs an extremely low skew cable, Madison will be happy to offer
the possibility. It seems to me that 25 ps/ft is good enough for current
SCSI application and it's a fare number for most of the cable manufacturers.

Jie

> -----Original Message-----
> From:	wally at eng.adaptec.com [SMTP:wally at eng.adaptec.com]
> Sent:	Wednesday, May 12, 1999 2:35 PM
> To:	Fan, Jie 
> Cc:	t10 at Symbios.COM
> Subject:	RE: setup, hold, and signal timing skew inconsistencies
> 
> Jie,
> 
> What I was pointing out, is that a spec like 25 ps/ft doesn't say
> whether it's from pair to pair, or from wire to wire within a pair
> of wires.  The SPI-3 spec doesn't elaborate on that point.
> 
> I hope after the cable meetings, some comprehensive specifications
> will be in the SCSI standards.
> 
> And, 25 ps/ft, if it is applied to wire to wire skew within a pair
> of wires, could cause a duty-cycle skew of 2ns, (for 25 meters)
> just for the cable part of the skew.  So, I would hope that the wire 
> to wire skew for a single pair of wires is a lot less than 25 ps/ft.
> 
> 
> Regards,
> 
> Wally
> 
> 
> 
> > 
> > * From the T10 Reflector (t10 at symbios.com), posted by:
> > * "Fan, Jie " <jfan at amp.com>
> > *
> > Wally,
> > 
> > I think the cable skew is included in the timing budget table. A cable
> > manufacturer like Madison has always put the cable skew performance both
> > between pairs and within the pair (the two leads of the same pair) on
> our
> > SCSI cable specs. The skew is well controlled per the SCSI standard. It
> > might not necessarily be tight enough on the existing SCSI document for
> the
> > cable skew requirment especially as the speed goes up and the shorter
> cable
> > being used a great deal. As of yesterday, the cable manufacturers who
> attend
> > cable performance meeting agreed to tight the skew to 25 ps/ft. This is
> a
> > big improvement to the existing standard.
> > 
> > Regards,
> > 
> > Jie Fan
> > Product Engineer
> > Madison Cable Co.
> > Tel:(508)752-2884x306
> > e-mail: jfan at madisoncable.com
> > 
> > 
> > > -----Original Message-----
> > > From:	wally at eng.adaptec.com [SMTP:wally at eng.adaptec.com]
> > > Sent:	Tuesday, May 11, 1999 8:09 PM
> > > To:	r_moore at qlc.com
> > > Cc:	t10 at Symbios.COM
> > > Subject:	RE: setup, hold, and signal timing skew inconsistencies
> > > 
> > > * From the T10 Reflector (t10 at symbios.com), posted by:
> > > * wally at eng.adaptec.com (Walter Bridgewater)
> > > *
> > > Richard,
> > > 
> > > 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
> > > the transmitter.
> > > 
> > > Wally
> > > 
> > > 
> > > > 
> > > > * From the T10 Reflector (t10 at symbios.com), posted by:
> > > > * Richard Moore <r_moore at qlc.com>
> > > > *
> > > > Wally,
> > > > 
> > > > 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
> > > > budget?
> > > > 
> > > >  -- Richard
> > > > 
> > > > >
> > > > >* From the T10 Reflector (t10 at symbios.com), posted by:
> > > > >* wally at eng.adaptec.com (Walter Bridgewater)
> > > > >*
> > > > >Jim,
> > > > >
> > > > >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?
> > > > >
> > > > >
> > > > >Wally
> > > > >
> > > > >
> > > > >> 
> > > > >> * 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
> > *
> > * For T10 Reflector information, send a message with
> > * 'info t10' (no quotes) in the message body to majordomo at symbios.com
> > 
*
* 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 mailing list