setup, hold, and signal timing skew inconsistencies

Jim McGrath Jim.McGrath at quantum.com
Thu May 6 14:40:38 PDT 1999


* 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





More information about the T10 mailing list