Bus Clear Delay question

Gerry.Houlder at seagate.com Gerry.Houlder at seagate.com
Tue Jan 23 11:46:06 PST 2001


* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*

The specification you read today was set in place many years ago, when
there were cases where that specification made sense. The original bus
clear delay number was most useful for the "soft reset" alternative. This
was an option that allowed an initiator to force an existing command off
the bus right away so it could do a "more important" operation. Due to
problems with implementing the soft reset functionality, it was not
supported by targets and was eventually obsoleted a few years ago.

The existing requirement for getting off the bus within 800 ns controls the
target implemenation. Most targets filter the reset line as much as they
can but still meet the 800 ns limit in order to eliminate responses to
glitches, but targets will probably recognize any reset pulse longer than
500 ns.

The 25 us recommendation for initiators is intended to make it easy for
targets to recognize a real reset pulse from a glitch. Recommending a pulse
width 50 times more than the limit the target must implement to is probably
overkill, but the standard didn't want to have initiator vendors and target
vendors pointing fingers at each other about whether a 200, or 500, or 700
ns pulse should actually be treated as a real reset or not. This kind of
finger pointing was going on 15 years ago because initiator vendors were
trying to use the "narrowest possible" reset pulse and some targets
responded to narrower pulses than others.

The fixed length 25 us pulse is much easier for a chip vendor to generate
that to require it to assert reset, sample all bus bits until all are
released, wait 200 ns more for bus settle delay, then release reset. The
few microseconds saved are not worth the design complication. Especially
when you consider that asserting reset is going to commit the initiator and
targets to a multi-second system reconfiguration and reset cycle.





"Stack, Dick" <dick.stack at intel.com>@t10.org on 01/23/2001 11:43:22 AM

Sent by:  owner-t10 at t10.org


To:   "'t10 at t10.org'" <t10 at t10.org>
cc:

Subject:  Bus Clear Delay question


* From the T10 Reflector (t10 at t10.org), posted by:
* "Stack, Dick" <dick.stack at intel.com>
*
I am seeking clarification on the Bus Clear Delay specification.

Bus Clear Delay is specified to be a maximum of 800 nSec from assertion of
RST signal to release of all SCSI bus signals by a device.

( Reset Delay specifies that RST must be continuously true for 200 nSec
before a device initiates a reset.)

RST is specified to be a minimum of 25 uSec.

Why should a device be required to have all signals released within 800
nSec
when nothing can happen on the bus until RST is released 24.2 uSec later?


Why couldn't Bus Clear Delay specify that all device signals must be clear
prior to release of RST?

Dick Stack
Senior Engineer
Intel Corp.   CO5-138
15400 NW Greenbrier Pkwy
Beaverton, OR  97006
(503) 677-4337 office
(503) 870-1260 pager
dick.stack at intel.com


*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list