https://patents.google.com/patent/US5353417A/en
Before turning in greater detail to a description of the functions
served by the BIC 35, it is appropriate to first consider the support by
a personal computer of what have been known as multiple masters or bus
masters. As here used, a "master" is a processor or any circuit designed
to gain control over a bus and drive address, data and control signals
on the bus. Having such capability enables a master device to transfer information between system memory and other devices.
It has been proposed that masters be divided among three types--system
master (usually the CPU), DMA controller, and bus master. The system
master controls and manages the system configuration. It is usually the
default master in the system. The default master owns the bus when no
other master requires it. A DMA master is a special type of master which transfers data between DMA slaves and memory slaves, and does not
arbitrate for the bus but services the DMA slave that is the arbitrator.
As here used, a bus master arbitrates for use of the bus and supports information transfers with an I/O slave or memory slave.
What makes a device a "bus master" can be confusing, as bus masters do
not necessarily require a processor. Also, a bus master may be called on
to respond as a slave when accessed by another bus master. A bus master
is distinguished by the capability of gaining control of the bus through arbitration and controlling the execution of a defined bus cycle.
Generally, there are three types of bus masters: full function, special function controllers, and programmable special function controllers. The fundamental differences among them are degrees of flexibility, function
and cost. The full function bus master is the most flexible, has the
most function, and costs most. Typically, a full function bus master
will have its own programmable CPU and be capable of controlling all
system resources, including operating system software. Special function controllers have the least flexibility, function and cost. Typically, a
special function controller will use logic circuits but no CPU to
perform a specific function while requiring little or no assistance from
other masters. Programmable special function controllers span the range
between the other two. The fundamental difference between special
function and programmable special function controllers is the ability to
modify the function and/or execution characteristics of the bus master.
Such modification can be accomplished through use of processing units or through settable registers.
Within the definitions here given, the CPU 32 and SCSI controller 40 may function as masters directly coupled to or on the local bus 34, while
the I/O controller 58, DSP 51, VSP 46 and possibly accessory boards 45
mounted in the MICRO CHANNEL slots may all function as masters directly
coupled to or on the input/output bus 44.
With such multiple masters, the BIC 35 functions to provide for
arbitration among devices directly coupled to the input/output bus 44
for access to the input/output bus and to the local processor bus 34,
and for arbitration among the input/output bus 44 and the master devices coupled directly to the local processor bus 34 for access to the local processor bus 34. This "layering" of arbitration procedures is
illustrated and described more fully in co-pending application Ser. No. 07/706,602, filed May 28, 1991 and owned in common with the present
subject invention. As there shown and described, the BIC 35 functions as
a central arbitration control point (CACP) for the I/O bus 44 by the
exchange of certain signals with that bus and also functions as a local
bus arbitration control point (LBACP) by the exchange of certain signals
with the CACP, the I/O bus 44 and the masters directly connected to
local processor bus 34.
At this point, it is to be noted that the-BIC 35 and each local bus 34
master (CPU 32 and SCSI controller 40 in the illustrated embodiment) are connected by signals dedicated to bus arbitration. In the instance of
the CPU 32, such signals are identified as HOLD and HLDA; of the SCSI controller 40 and any other master device coupled directly to the local processor bus, BRQn# and BGTn# (the lower case letter "n" to be replaced
by a digit identifying a specific master). BRQn# is an output from the
master to the LBACP function of BIC 35 indicating a request for control
of the local bus 34. BRQn# is an active LOW signal. The masters will
drive the corresponding BRQn# active and await assertion of BGTn# before driving the local bus 34. A winning local bus master will take BRQn#
inactive when BGTn# is sampled inactive or when it has finished using
the bus. Taking BRQn# inactive serves as an indication that the address
bus and bus cycle definition signals are being placed in a high
impedance state.
BGTn# is an output from the LBACP function of the BIC 35 to the master indicating that the master has been granted control of the local bus 34.
BGTn# is an active LOW signal. This signal will be held active by the
LBACP until BRQn# is driven inactive or another bus request is received
by the LBACP. If BGTn# is taken inactive by the LBACP, the current local
bus master will release the bus (driving BRQn# inactive) as soon as the
current transfer is completed. The LBACP will not drive BGTn# active for
the next local bus request pending until the previous master has driven
BRQn# inactive and it has completed the last transfer. PG,12
A priority and simple rotational fairness scheme are implemented in the
LBACP, with local bus devices being ranked by assignment of priority
numbers from highest priority (identified as device "1") to lowest
priority (identified as device "n" where the letter represents the
highest number provided for in the functional design). Due to the
possibility of a higher priority device precluding a lower priority
device from winning the bus, the pendency of bus access requests will
cause the LBACP to put any winning master into an inactive state after
it finishes data transfer and not grant the bus to that device until
after all other requestors have received bus service.
When an input/output bus device (such as the I/O controller 58, digital
signal processor 51 or video signal processor 46) controls the
input/output bus 44 and requests are pending on the local bus 34, the
LBACP will compete on behalf of the local bus masters in I/O bus
arbitration cycles performed by the CACP function. The LBACP function
may have a different arbitration level assigned for each master,
recognizing the priorities assigned as described above. If any assigned arbitration level wins at the I/O bus level, then the LBACP function
will drive BURST# active and allocate control of the bus among all local processor bus masters that have pending requests.
As will be recognized by the knowledgeable reader, memory controllers conventionally use row address select (RAS) and column address select
(CAS) signals for selecting particular areas of system memory (such as
memory 36 in FIG. 3) to access. Many memory controllers keep a RAS line
active during Input/Output and ROM cycles for the purpose of improving performance. In such a system, data access to memory is quickened if the
next memory cycle is in the bank and page previously activated. Such
memory control logic will deactivate a RAS line when the maximum
allowable time is exceeded for RAS to be active; during a refresh cycle;
and when a memory cycle is not in the same bank and page. In the latter instance in particular, wait states are necessarily introduced to effect
the necessary shift in memory access.
In accordance with the present invention, such wait states are reduced
or eliminated by an anticipatory pre-charge of RAS. More particularly,
and as discussed more fully hereinabove, the various masters in a
multiple master personal computer system will most likely use different
pages of memory. Knowing that, then the memory controller function of
the BIC 35 will vary RAS signals (if active) each time that a master
captures the associated bus. By doing this, the memory controller
function is free to service the first cycle more quickly. Various
sequences of such operations are illustrated more specifically in FIGS.
4 through 8.
In FIG. 4, a RAS pre-charge occurs in the absence of an indication of a
new master. At a first point (1), a local bus slave requests pipelining
and the current master for the local processor bus is unable to supply
the next memory address. The local bus arbitration control point (LBACP) function then takes BGT1# inactive during an idle state on the bus, at a
second point (2), and the first device removes BRQ1# at a third point
(3) and places a number of other signals in a high impedance state at a
fourth point (4). The LBACP signals a change in active master at a fifth
point (5) by taking BGT2# active. Thereafter, the memory controller
logic detects a bank and page miss at a sixth point (6), causing a RAS pre-charge.
In the sequence of FIG. 5, a RAS pre-charge occurs during an
input/output bus arbitration cycle. The LBACP function takes ARB/GNT#
and CACP-- HOLD active at a first point (1) in response to an
input/output bus master requesting to preempt the bus. The then active
device places a number of signals in a high impedance state at a second
point (2), and then removes BRQn# indicating a readiness to release the
bus at a third point (3). The LBACP function takes BGTn# inactive and
activates a signal known as NEWMASTER at a fourth point (4). The memory controller logic detects the change of bus masters indicated by
NEWMASTER and inactivates RAS# at a fifth point (5).
For comparison, FIG. 6 illustrates a similar sequence during arbitration
on the local processor bus. There, a local bus slave requests pipelining
and the current master for the local processor bus is unable to supply
the next memory address at a first point (1). The LBACP function then
takes BGT1# inactive during an idle state on the bus, at a second point
(2), and the first device removes BRQ1# at a third point (3) and places
a number of other signals in a high impedance state at a fourth point
(4). The LBACP signals a change in active master at a fifth point (5) by
taking BGT2# and NEWMASTER active. Thereafter, the memory controller
logic detects the change of bus masters indicated by NEWMASTER and
inactivates RAS# at a sixth point (6).
A RAS pre-charge can occur when the LBACP gives the local bus to the
system default master or system processor 32 as illustrated in FIG. 7.
There, a master device responds to NA# by removing BRQn# at a first
point (1), indicating that it is ready to release the bus, and places a
number of other signals in a high impedance state at a second point (2).
The LBACP function then takes BGTn# inactive at a third point (3), and
takes HOLD inactive and NEWMASTER active at a fourth point (4).
Thereafter, the memory controller logic detects the change of bus
masters indicated by NEWMASTER and inactivates RAS# at a fifth point (5).
FIG. 8 illustrates a sequence when the LBACP bumps the system processor
and gives the local processor bus to another device. There, a requesting
device activates BRQn# at a first point (1). The LBACP function detects
BRQn# active and activates HOLD at a second point (2). The system
processor 32 returns HLDA and turns off output drivers at a third point
(3). The LBACP detects HLDA at a fourth point (4) and activates BGTn#
and NEWMASTER. The memory controller logic detects the change of bus
masters indicated by NEWMASTER and inactivates RAS# (if then active) at
a fifth point (5).
In the drawings and specifications there has been set forth a preferred embodiment of the invention and, although specific terms are used, the description thus given uses terminology in a generic and descriptive
sense only and not for purposes of limitation.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)