No subject

GFRAZIER at ausvm6.vnet.ibm.com GFRAZIER at ausvm6.vnet.ibm.com
Mon Apr 11 13:58:16 PDT 1994


ULTRA-SCSI SYSTEM CONSIDERATIONS

The minutes of the ultra SCSI meeting included a list of "System Level
Issues" which the Ultra-SCSI group should address. I would like to add
one more system level consideration dealing with slew rates.

A slew rate is 600 mv/ns (max), as discussed at the meeting, is faster
than the maximum allowed SPI slew rate. This can be shown as follows:

        * SPI slew spec is: t(rise, 10-90%) > 5 ns.
To calculate the maximum possible slew rate for SPI,
        * Assume:
           low voltage = 0v (min allowed).
           high voltage = 3.24 v (max allowed for active negation)
        * Therefore
           10% - 90% swing = 2.92 - .324 = 2.6v (max):
        * Finally, calculating slew rate (max):
           Slew rate (max) = 2.6v/5ns = 520 mv/ns
Therefore, the maximum allowable SPI slew rate (520 mv/ns) is below
the maximum proposed ultra slew rate of 600 mv/ns. (Nominal SPI slew
rates will probably be even smaller.)

Combining this fact (i.e. that an ultra device may have a slew rate
above the maximum allowable SPI slew rate), with the fact that ultra
devices must slow down to FAST (i.e. 10Mby/sec) timings after
negotiations complete, means that some ultra devices will not
interoperate with SPI devices even though speed negotiations succeed.

One solution to the problem is to require ultra devices to operate at
SPI slew rates (i.e. < 520 mv) when operating at 10 MBY/sec or less.
In other words, when a lower data rate is negotiated, a lower slew
rate should be required along with the longer setup and hold timings
which are already required.

Another solution would be to require ultra devices to fail speed
negotiations if they could not meet the SPI slew rates (i.e. < 520
mv/ns).

Another solution would be to limit ultra slew rates to < 520 mv/ns
(or some agreed to value within SPI limits).

If one of the above is not done, there is little use to require data
rate negotiations at all. This is because even though the ultra device
has slowed its data rate, it will still be unreliable because it is
using a slew rate out of specification for the SPI Fast device.

This is an important system issue because many non-ultra customers
will want to upgrate existing systems by replacing SCSI-2 DASD with
newer ultra-capable DASD. They will expect the system to function
whenever the data rate negotiations succeed.
This requirement should be explicitly stated in SPI.

                                        Giles Frazier
                                        IBM Austin
                                        gfrazier at ausvm6.vnet.ibm.com




More information about the T10 mailing list