setup, hold, and signal timing skew inconsistencies

Walter Bridgewater wally at eng.adaptec.com
Thu May 6 16:44:43 PDT 1999


* 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
> 
> 
> > -----Original Message-----
> > From:	Richard Moore [SMTP:r_moore at qlc.com]
> > Sent:	Thursday, May 06, 1999 10:59 AM
> > To:	't10 at symbios.com'
> > Subject:	setup, hold, and signal timing skew inconsistencies
> > 
> > * From the T10 Reflector (t10 at symbios.com), posted by:
> > * Richard Moore <r_moore at qlc.com>
> > *
> > Recently I've noticed that there are still what I consider to be
> > inconsistencies in the SPI-3 timing budgets
> > (Figures 46 and 47, and Tables 31 and 32 in rev 5).
> >  
> > First, I think that the huge signal timing skew allocation for slow DT
> > transfers is not only unnecessary,
> > but inconsistent with the ST signal timing skew. For example, the latest
> > proposal has Fast-20 DT signal
> > timing skew at 13.4 ns, and Fast-5 or Fast-10 ST signal timing skew at 8
> > ns.
> > Are we saying that a cable
> > plant that works fine at Fast-20 DT may not work at Fast-5 or Fast-10 ST?
> >  
> > It was said at the working group meeting this week that this is because DT
> > is supposed to give relief
> > to the cable. But DT gives relief to the cable by driving it with REQ and
> > ACK signals that are less subject
> > to distortion, because they are half the frequency of the corresponding
> > REQ
> > and ACK signals for the
> > same transfer rate in ST. By relaxing the skew we are in effect providing
> > redundant relief. In the end I don't
> > think it matters to those who are designing silicon with Fast-80 DT in
> > mind
> > (except that the change may
> > force them to repeat all their slow DT simulations that passed with the
> > old
> > timings), but it does send a
> > peculiar message.
> >  
> > Another inconsistency is the difference in setup and hold budgets for
> > Fast-5
> > (Figure 46). Fast-5 setup
> > and hold times are 23 ns and 53 ns at the transmitter, and 15 ns and 25 ns
> > at the receiver. To account
> > for the differences, signal timing skew was set to 8 ns for setup and 28
> > ns
> > for hold. At the working group
> > meeting it was stated that this was due to active negation; this was then
> > restated to say that it was due
> > to reflected-wave signaling. This explanation does not make sense; if the
> > data lines used reflected-wave
> > and the REQ/ACK lines used incident-wave, then it is the setup, not hold,
> > that would be degraded.
> >  
> > Fast-5 setup and hold times changed between SCSI-2 and the first
> > generation
> > of SPI. SCSI-2 called
> > for the sender to provide "one deskew delay plus one cable skew delay" of
> > setup time, and "one deskew
> > delay plus one cable skew delay plus one hold time" of hold time. These
> > phrases equate to 55 ns setup
> > and 100 ns hold time. A careful reading of SCSI-2 shows that this extra
> > hold
> > time was budgeted to the
> > receiving device, not to the cable: "The initiator [target] shall read the
> > value on the DB(7-0,P) signals within
> > one hold time of the transition of the REQ [ACK] signal to true" (SCSI-2,
> > section 6.1.5.2). For consistency,
> > Figure 46 should be altered so that the signal timing skew is 8 ns for
> > both
> > setup and hold, and the 20 ns
> > difference should be allocated to the receiver hold time.
> >  
> > I don't know why the Fast-5 numbers were so dramatically reduced going
> > from
> > SCSI-2 to SPI.
> >  
> > As a footnote, I would like to repeat that SCSI does not work with
> > reflected-wave signaling on the data lines:
> > With 6-meter cables you need 60 ns for a cable round trip, and this far
> > exceeds the 8 ns (10 ns in SCSI-2)
> > allocated for Fast-5. Although electrically you may expect to see
> > reflected-wave signaling with 48 mA drivers
> > on a low impedance cable, in practice single-ended usually works anyway
> > because most devices drive
> > somewhat higher than 48 mA, and hence really do use incident-wave
> > signaling.
> > Note that I said, "usually";
> > anyone who's been in the initiator business for 10 years has at some point
> > configured a system that doesn't
> > work, and discovered that it can be made to work by moving the offending
> > device from the middle of the cable
> > to the end of the cable.
> >  
> >  -- 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