LVD Release Glitches

Lohmeyer, John JLOHMEYE at cosmpdaero.ftcollinsco.ncr.com
Thu Jan 11 07:52:00 PST 1996


* From the SCSI Reflector, posted by:
* <"Lohmeyer, John" <JLOHMEYE at cosmpdaero.ftcollinsco.ncr.com>>

The SPI-2 Working Group has identified a new kind of transmission line
glitch that I call a "release glitch".  You may already be familiar with
"wired OR" glitches that occur when multiple devices are asserting a
wired-OR signal and one releases its drivers.  These cause brief apparent
negations (duration depends on cable length).  SCSI protocol is designed to
ignore these glitches.

A release glitch occurs when an actively negated LVD signal is released and
it causes a brief apparent assertion (once again, the duration depends on
cable length).  These glitches are new with LVD and SCSI protocol currently
does not ignore them.

On Monday, the SPI-2 LVD working group started down a path of re-designing
LVD drivers to eliminate these glitches (by changing to an asymmetric driver 


design).  This is a change in direction (and may be worth doing as it may
reduce power dissipation somewhat), however, it does complicate driver
designs and terminator designs.  Another concern is that it may delay
reaching stability on LVD.

On Tuesday, the SCSI Working Group agreed that release glitches from LVD
drivers are acceptable and can be dealt with by the digital logic.  They are 


instructing the SPI-2 LVD working group to not change from balanced drivers
unless there is a good analog reason to do so.

So far we have identified the following places in SCSI protocol where
release glitches may occur:

1.  Normal Disconnects

Following a number of situations the target releases BSY and all other
negated lines may have release glitches (including REQ and ACK):

a)     after a reset condition is detected;
b)     after an ABORT message is successfully received by a target;
c)     after a BUS DEVICE RESET message is successfully received by a
       target;
d)     after a DISCONNECT message is successfully transmitted from a target;
e)     after a COMMAND COMPLETE message is successfully transmitted from
       a target;
f)     after a RELEASE RECOVERY message is successfully received by a
       target;
g)     after an ABORT TAG message is successfully received by a target;
h)     after a CLEAR QUEUE message is successfully received by a target.


2. Unexpected Disconnect

Unexpected disconnects are catastrophic conditions.  Targets use them to
tell the initiator that something is so wrong that the entire I/O process is 


to be aborted. Following almost any state, the target may release all driven 


lines to go to BUS FREE phase.  While this may briefly cause release
glitches (for about one microsecond), the firmware should see the BUS FREE
phase without one of the above situations and ignore the effect of the
glitches.  In fact, firmware should ignore virtually everything that
happened during the prior connection.  New target designs (all LDV designs
will be new) may be able to minimize the impact of this glitch by releasing
BSY slightly ahead of releasing REQ (say 400 ns).


3. SCAM protocol   (NOT!)

The working group talked about release glitches as being present during SCAM 


protocol and being no problem.  I think we were wrong about release glitches 


being present during SCAM protocol.  I think there are no places in SCAM
protocol where a signal goes from actively negated to released.  (And thus
there is still no problem.)


4. Selection and Reselection

During a selection or reselection phase, there is a point when the target or 


initiator, having put its ID and the other device's ID on the data bus,
releases the data bus.  At this point, all of the other ID's may glitch
true.  Since the other device has already latched the IDs and responded with 


BSY, it should cause no problems.

There may however be a problem on a selection or reselection timeout
procedure.  The device driving the bus must either:

a) _negate_ the data bus during the abort procedure instead of _releasing_
the data bus (or all other devices might see a false selection).   or

b) release the non-asserted ID bits throughout the selection or reselection
phase so as to avoid the negated-to-released signal transitions on all data
bus bits.


If anyone knows of any other places in SCSI protocol where a non-wired-OR
signal transitions from actively negated to released, please let me know.

John Lohmeyer, Chair X3T10 Technical Committee
 --
John Lohmeyer             E-Mail:  john.lohmeyer at symbios.com
Symbios Logic Inc.         Voice:  719-573-3362
1635 Aeroplaza Dr.           Fax:  719-573-3037
Colo Spgs, CO 80916     SCSI BBS:  719-574-0424 300--14400 baud






More information about the T10 mailing list