Browse Prior Art Database

Automatic Bus Pacing On a Micro Channel

IP.com Disclosure Number: IPCOM000101664D
Original Publication Date: 1990-Aug-01
Included in the Prior Art Database: 2005-Mar-16
Document File: 4 page(s) / 165K

Publishing Venue

IBM

Related People

Chisholm, DR: AUTHOR [+2]

Abstract

This article describes a technique for use in a computer system to monitor slow slave devices on a MICRO CHANNEL*. Also disclosed is a circuit arrangement to do bus pacing on a MICRO CHANNEL. Three timers are used to determine whether one or more cycles can be taken before giving up control of the MICRO CHANNEL.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 38% of the total text.

Automatic Bus Pacing On a Micro Channel

       This article describes a technique for use in a computer
system to monitor slow slave devices on a MICRO CHANNEL*. Also
disclosed is a circuit arrangement to do bus pacing on a MICRO
CHANNEL.  Three timers are used to determine whether one or more
cycles can be taken before giving up control of the MICRO CHANNEL.

      During MICRO CHANNEL operations, bus masters are required to
get off the MICRO CHANNEL within 7.8 microseconds (usec) of the
PREEMPT line going active.  A further requirement is that all slave
devices must be able to complete a cycle without delaying the cycle
more than 3.5 usec. However, there is no provision in the
architecture to deal with a slow slave.  A hardware design is
provided to help software deal with this reliability, availability,
serviceability (RAS) deficiency.  This MICRO CHANNEL bus master
design has two timers that monitor bus operation durations.  One of
these timers works in Streaming Data mode, the other in Non-Streaming
Data mode.  Both of these timers are utilized whenever the PREEMPT
line is active. The timer used in Non- Streaming Data cycles is
enabled when the command line (CMD) is active and streaming data
strobe (SD STROBE) is inactive.  It begins with a zero count value
and will count up until CMD is driven inactive.  When CMD goes
inactive, the CMD timer will reset to zero.  If the CMD timer reaches
a time value of 3.5 usec, a latch will be set signifying that the
slave is responding too slowly.  This status is available to software
if, during the envelope of this bus master operation, a MICRO CHANNEL
timeout is signaled by ARB/GRANT going high.  Software can then
decide if the bus master data packet size (number of cycles in a
BURST) can be reduced and this error recovered from.  For instance,
some bus master designs have variable data packet buffers that are
adjustable by program control.  Some slave designs have fixed length
data buffers.  With this configuration, the most likely cause of the
slave to exceed the 3.5 usec delay is when the master is transferring
a data packet larger than the slave's buffer size.  When the slave's
buffer boundary is reached, it delays the start of the next cycle
until all or part of its data buffer is emptied.  Software could
adjust the master's data packet size, in this case, and avoid the
timeout.

      This design could also allow the slow slave to be reported even
on good transfers.  These are transfers that complete without a
timeout despite the fact that the slave took longer than 3.5 usec.
As in the case above, software could then reconfigure transfer
lengths to an acceptable length to insure completion.  If the
transfer is a Streaming Data cycle, the CMD timer is disabled and the
Streaming Data timer is started.  It works just like the CMD timer
except that it times the duration it takes from data accept to data
accept.  This is because in Streaming Data mode, the slave co...