 |
Description  |
|
|
TECHNICAL FIELD
The present invention relates to computer systems that have more than one
processor that share a memory. More particularly, the present invention
relates to systems and methods for controlling a shared memory bus that
connects to a number of processors and to a shared memory.
BACKGROUND OF THE INVENTION
In computer systems, it is common for one or more processors to access a
memory, referred to as a "shared memory". Also, the shared memory may be a
memory array that contains a number of memory modules. Access to the
shared memory is generally over a shared memory bus. One such system is
disclosed in copending application Ser. No. 07/546,547, entitled "HIGH
SPEED BUS SYSTEM" filed on even date herewith.
Two separate uni-directional buses may connect a shared memory or memory
array to a memory controller. One bus is for transmissions from the memory
controller to the array and the second is for transmissions from the
memory array to the memory controller.
The memory controller, in turn, may interface with a bus system that
connects to memories of the system processors. This bus system may include
a bidirectional bus or two uni-directional buses, with one for
transmissions from the memory controller to the processor memories and the
other for transmissions from the processor memories to the memory
controller.
A characteristic of a system having a shared memory and number of
processors is that one of the processors can issue a read command followed
by an address, which when placed on the bus system is supplied not only to
the memory controller but also to all of the other processors connected to
the bus. This increases the system's processing speed by avoiding the need
for the processor to separately notify each of the other processors.
After the memory controller receives the read command and address, it
places this on the unidirectional bus between it and the memory array. The
memory array responds by providing refill data on the other
uni-directional bus between the memory controller and the memory array.
The refill data is then placed on the bus system that supplies such data
to all of the processors including, of course, the processor that
requested it.
A consideration in the design of shared memory systems involving the
request for, and receipt of, data from memory is memory latency, i.e., the
period between the placing of a command on a bus and the returning of
refill data from the memory on the bus. Without consideration of memory
latency, this entire request and refill data scheme will not operate
effectively since the system may not be able to handle the number of
requests that are made resulting in collisions on the shared memory bus.
Most activities in any system, which include shared memory systems, require
one or more cycles to complete. Typically, activities take more than one
cycle and the required number of cycles vary depending on the dynamic
conditions. Since this is the case, there is a strong possibility that
simply placing commands and data on a common bus without controlling them
may result in collisions on such a bus. Thus, such shared memory systems
must have a means to prevent such collisions.
Another compounding factor is that in a single or multiprocessor system,
there can be a plurality of successive read commands sent to memory. Each
includes a command and an address. These read commands can be issued at a
rate that exceeds the ability of the system to supply the refill data
because of things such as memory latency.
Some shared memory systems include a number of state machines that are used
to control placement of commands and addresses on the shared bus leading
from the memory controller to the memory array. The number of state
machines usually determine the number of commands and addresses a system
is capable of handling at one time. Each of these separate commands and
addresses that are being handled by a separate state machine, however,
must be directed to different memory modules of the memory array.
If more than that number of commands and addresses are sent than can be
handled by the state machines, they will be waiting for memory access at
the memory controller. The memory controller, therefore, must have a
queueing mechanism to handle them. Implementation of such a mechanism at
the memory controller or dramatically increasing the number of state
machines to expand system capabilities adds to system complexity and cost.
Hence, it is desirable to accomplish memory accesses without the need to
make these costly implementations.
Another consideration is a desire to efficiently use a shared bus. Normally
unused or empty cycles occur between blocks of refill data on the shared
bus. Preferably there should be no dead space or time on the bus. At a
steady state operating condition, after each predetermined number of
cycles of refill data are placed on the bus, a predetermined number of
cycles of read commands and addresses should follow, immediately followed
by another predetermined number of cycles of refill data. However, the
elimination of dead space has to be done without causing collisions and
without implementing a costly queuing mechanism.
Many systems also include a cache memory system which further complicates
the collision problem. In such systems, each time a memory command and
address are sent out, a check must be made to see if the requested
information is contained in a cache memory of one of the system
processors. If the data is found, that processor must be given access to
the shared bus that links the processors, and links the processors to the
memory controller. When this access is given, it will prevent other read
commands from being sent out on that bus. Thus, systems must consider
cache memory reads ("snoopy reads") in collision analysis.
A further complicating factor is that systems typically do not have just
one type of memory in a memory array, but many types. These different
memories have different read access times and, therefore, different memory
latencies since read access time is part of memory latency. It follows
that any method or scheme for memory bus control that depends upon a fixed
timing schedule for placing commands and data on a shared bus will result
in collisions on that bus. Hence there must be a method of memory bus
control that considers the read access time in placing commands and
addresses, and refill data on a shared memory bus.
There is a need for a memory bus control system that will overcome these
problems.
SUMMARY OF THE INVENTION
The present invention is a system and method for controlling a shared
memory bus in multi-processor systems. The control of the shared memory
bus according to the system and method of the present invention is based
on dead reckoning. That is, it relies on the known memory latency for a
specific memory module in the memory array. Using known memory latency and
the time required for refill data, steady state operations may be
performed with successive commands and addresses being placed on the bus
and provided to the memory controller at a rate which does not exceed the
ability of the memory controller to handle such commands and addresses.
The system and method of the present invention also ensures that during
system start-up, the commands and addresses are sent out fast enough so
that there are no dead spaces, while at the same time ensuring that the
"snoopy read" operations are permitted. This is accomplished by sending
out three successive commands with each separated from the other by an
amount of time at least equal to the "snoopy read" time. If there is a
"snoopy hit," the data is read from the processor memory holding the
information and the next command and address are not sent out until after
the snoopy read operation is completed.
According to the present invention, memory control also is carried out in
such a way that different read access times are taken into account. To do
this, the read access times are stored for each memory module in the
memory array and a shadow counter having a count down value based on the
read access time of the module being addressed is used. The output of the
shadow counter indicates when the next read memory command and address may
be placed on the shared bus.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a general block diagram of a system in which the system and
method of the present invention may be implemented.
FIG. 2 is a simplified block diagram of a first implementation of the
present invention using OR gates in the system shown in FIG. 1.
FIG. 3 a simplified block diagram of a second implementation of the present
invention using multiplexers in the shown in FIG. 1.
FIG. 4 is a more detailed block diagram of a portion of the central unit
shown in FIG. 3.
FIG. 5 is a more detailed block diagram of the scheduling logic shown in
FIG. 4.
FIG. 6 is a more detailed block diagram of the resource check logic shown
FIG. 4.
FIG. 7 is a timing diagram for read command timing.
FIG. 8 is a timing diagram for snoopy refill command timing for snoopy
hits.
FIG. 9 is a timing diagram for a SWAP command timing.
FIG. 10 is a timing diagram for no dead space on a shared bus.
FIG. 11 shows a command format according to the present invention.
DETAILED DESCRIPTION
The present invention is a system and method for controlling a shared
memory bus such that collisions on a shared bus are prevented and the bus
is filled at system start-up and during steady state operations. The
present invention may be used in a bus system such as that described in
copending application Ser. No. 07/546,547, entitled HIGH SPEED BUS SYSTEM.
FIG. 1 is a general block diagram of a system in which the system and
method of the present invention may be implemented. This system has CPU 0
at 11, CPU 1 at 13, CPU 2 at 12, and CPU 3 at 14. These CPUs are coupled
to central unit 15. Central unit 15 will be described in detail
subsequently.
Each of the CPUs is connected to the central unit 15 over a point to point
bus. Accordingly, E-BUS O TA bus 17 (i.e., the E-BUS associated with CPU 0
which carries signals to an A-BUS associated with a shared memory 31)
connects CPU 0 at 11 to central unit 15, E-BUS 1 TA bus 19 connects CPU 1
at 13 to central unit 15, E-BUS 2 TA bus 18 connects CPU 2 at 12 to
central unit 15, and E-BUS 3 TA bus 20 connects CPU 3 at 14 to central
unit 15 (collectively, "E-BUS TA buses"). These unidirectional buses are
for transmissions from the CPUs to central unit 15. For the transmission
of data from central unit 15 to the CPUs, there are E-BUS 0 FA bus 21
(i.e., the E-BUS associated with CPU 0 which carries signals from a A-BUS
associated with the shared memory 31), which connects CPU 0 at 11 to the
central unit, E-BUS 1 FA bus 23, which connects CPU 1 at 13 to the central
unit, E-BUS 2 FA bus 22, which connects CPU 2 at 12 to the central unit,
and E-BUS 3 FA bus 24, which connects CPU 3 at 14 to central unit.
Each of the CPUs also connect to an I/O bus adaptor 25 over two
uni-directional buses. Each is a 16-bit bus. One bus is an input bus and
the other is an output bus.
As shown in FIG. 1, control console 29 is associated with CPU 0 at 11.
However, it is understood that it may be associated with more than one
CPU.
Central unit 15 is connected to shared memory 31 by uni-directional A-BUS
FA 33 and uni-directional bus A-BUS TA 35. A-BUS FA 33 is for
transmissions from the central unit to the shared memory 31. Conversely,
A-BUS TA 35 is for transmissions from shared memory 31 to the central
unit.
Shared memory 31 includes memory modules which are designated 31a, 31b,
31c, 31d, 31e, and 31f. Each memory module connects to central unit 15 via
A-BUS FA at 33 and A-BUS TA at 35. It is to be understood that there may
be more shared memory, or there may be more or less memory modules for a
single shared memory and still be within the scope of the invention. It is
further understood that each module may be of the same type of memory or
each may be of a different type.
E-BUS TA buses 17, 19, 18, and 20, E-BUS FA buses 21, 23, 22, and 24, and
A-BUS FA bus 33 are 32-bit parallel buses, and A-BUS TA bus 35 is a 64-bit
parallel bus.
The central unit 15 performs two basic functions. First, it combines the
signals input to it from the CPU and memory on the E-BUS TA and A-BUS TA
buses, respectively, so that they are provided as outputs on the output
buses E-BUS FA and A-BUS FA. Second, it contains a memory controller for
memory modules 31a-f. Central unit 15 also controls system timing. This is
done through a central clock which is not shown.
FIG. 2 is a block diagram of the system shown in FIG. 1, with the first
implementation of the present invention in the system shown in FIG. 1. In
this implementation, OR gates are used to combine the point to point
signals from E-BUS TA buses 17, 19, 18, and 20 into a common signal.
As shown in FIG. 2, the 32-bit wide E-BUS TA buses 17, 19, 18, and 20
connect to the series of OR gates 37 and 41. For simplicity of description
only single lines as shown for the 32-bit wide buses and only one series
of OR gates are shown for handling these buses. It is understood, however,
that in actuality there would be 32 series of OR gates 37 and 41 to
accommodate the 32-bits of the buses. It is further understood that the
single 32-bit wide output of OR gate 37 is input to memory controller 45
and OR gate 41, and the single 32-bit wide output of OR gate 41 is input
to state device 42. With this understanding FIG. 2 will now be discussed.
According to this first implementation, E-BUS O TA 17 from CPU 0 at 11
connects to a first input to OR gate 37, E-BUS 1 TA bus 19 from CPU 1 at
13 connects to the second input to gate 37, E-BUS 2 TA bus 18 from CPU 2
at 12 connects to the third input of OR gate 37, and E-BUS 3 TA bus 20
from CPU 3 at 14 connects to the fourth input to OR gate 37. The output of
OR gate 37 is bus 36 which is the first input to OR gate 41. Bus 36 is
also input to memory controller 45. The second input to OR gate 41 is the
output from memory controller 45. The output of OR gate 41 on bus 39 is
input to the data input of state device 42. When state device 42 receives
the input from OR gate 41, it stores the output for one cycle before
providing it at its output.
Although not shown, conventional arbitration logic and communication
between the CPUs exist. This arbitration logic, which can be centrally
located or in one or more of the CPUs is necessary to ensure that only one
of the CPUs has access to the bus 36 at a time. This logic functions on a
request/request granted type of operation.
The output of state device 42, after passing through driver 43, is input to
CPU 0 at 11, CPU 1 at 13, CPU 2 at 12, and CPU 3 at 14 via E-BUS 0 FA bus
21, E-BUS 1 FA bus 23, E-BUS 2 FA bus 22, and E-BUS 3 FA bus 24,
respectively. It is understood that the output to the state device is a
32-bit wide output.
Notice that anything applied on the E-BUS x TA buses (where "x" represents
any of the bus elements) will show up in the next bus cycle on the
E-BUS.times.FA buses. Therefore, arbitration for the E-BUS.times.FA buses
must be done prior to any element transmitting on the E-BUS.times.TA
buses.
As stated, the output of OR gate 37, bus 36, is input to the memory
controller 45. The second input to OR gate 41 is the output of memory
controller 45. Therefore, the refill data from memory 31 that is on the
A-BUS TA bus 35 passes through memory controller 45 for input to the
second input of OR gate 41. This data is later caused to be input to state
device 42. After processing by the state device, the refill data is
supplied to the CPUs via driver 43 and the E-BUS FA buses. This is how
refill data operates for a read.
When it is necessary to write data to the memory, data from OR gate 37 on
line 36 is coupled through memory controller 45 onto the A-BUS FA 33. No
refill data is provided because the data is written to memory.
FIG. 3 is a simplified block diagram of a second implementation of the
present invention incorporated in the system shown at FIG. 1. Here,
multiplexers ("MUXes") replace the series of OR gate. According to this
implementation, MUXes 37a and 41a replace the OR gates. As shown in FIG.
3, logic element 50 is also added.
Port logic 49 is disposed at the input to MUX 37a. The buffer in port logic
49 can hold up to three words, the number of words being a function of the
length of time for the CPUs to recognize a bus grant condition from one of
the E-BUS TA buses.
Although most of the signals from the E-BUS TA buses are poised ready for
input to MUX 37a, there are certain bits from port logic 49 for output to
logic element 50. Logic element 50 processes these bits and provides
selection inputs to MUXes 37a and 41a.
FIG. 4 is a more detailed block diagram of the central unit 15 of FIG. 3.
Logic element 50 in FIG. 3 includes as part thereof port select logic 65
that is shown in FIG. 4. Port select logic 65 is combined with multiplexer
37a to form scheduling logic 66.
Other logic included in the logic 50 of FIG. 3 is resource check logic 67.
Resource check logic 67 combines with MUX 41a and state device 42 to form
arbitrator 51.
Again referring to FIG. 4, E-BUS O TA bus 17, E-BUS 1 TA bus 19, E-BUS 2 TA
bus 18, and E-BUS 3 TA bus 20 connect to port logic 49. Each of these
E-BUS TA buses from one of the CPUs is connected to its own port of port
logic 49. For example, E-BUS O TA bus 17 connects to port 49a, while E-BUS
1 TA 19 connects to port logic 49b.
Four types of information may be communicated on the E-BUS TA buses. These
types are: (1) data, commands and address information ("DAL"); (2) FC
information, which are signals to indicate whether the information on the
DAL lines is a command, or address or data; (3) "snoopy hit"information,
which indicates that a CPU associated with that bus has a "snoopy hit;"
and n(4) parity information.
Although not shown, each of the CPUs may include a cache memory. These
memories may be used to speed up access to data which is being used
extensively by a CPU. Thus, each time a read command is sent out, each CPU
checks to see if the associated address is in its cache. In a manner that
will be explained in more detail below, this operation which is known as a
"snoopy" operation, is done with timing that insures that any response to
a "snoopy" read, which is a "snoopy hit," takes place before refill data
returns from one of the memory modules in memory 31.
Again referring to FIG. 4, the information on buses E-BUS O TA bus 17,
E-BUS 1 TA bus 19, E-BUS 2 TA bus 18, and E-BUS 3 TA bus 20 is input to
state device 53. The output of the state device 53 is coupled to MUX 59
and to buffer 55. Buffer 55 can store up to three words of predetermined
length.
The output of the state device 53 is also input to validity logic 57. The
second input to validity logic 57 is a signal that is fed back from the
output of validity logic 57. The other output of validity logic 57
connects to the selection inputs of MUX 59. The PORT GRANT signal on line
61, which is output from arbitrator 51, is also input to validity logic
57.
The function of validity logic 57 is to determine if commands and data are
valid, and which of the data, either in buffer 55 or input directly to
port MUX 59, are to be switched onto bus 63 at the output port MUX 59.
The output of port MUX 59 on bus 63 is input to MUX 37a. The output of port
MUX 59 on bus 63 is also input to port select logic 65. MUX 37a and port
select logic 65 are part of scheduling logic 66.
Port select logic 65, in response to outputs from the arbitrator 51,
selects one of the four inputs to MUX 37ato be coupled to the output of
that MUX. This is coordinated with the operation of validity logic 57
which controls the output of port MUX 59 on bus 63. Port select logic 65
grants the four ports supplying inputs to bus 63 access to bus 36 on a
round robin basis.
Output bus 36 is input to resource check logic block 67 of the arbitrator
51, MUX 41a, and a number of other units. These units are memory map unit
("MMAP") 69, lock logic unit ("LOCK") 71, input/output unit ("CPIO") 73,
interrupt request unit ("IREQ/SNIT") 75, memory controller ("MEMC/DBEC")
77, and memory write data path unit ("MWDP") 79. Each of the units 69, 71,
73, 75, and 77 also provide inputs to the MUX 41a.
Resource check 67 receives status inputs from MMAP 69, LOCK 71, CPIO 73,
IREQ/SNIT 75, MEMC/DBEC memory controller 77, and MWDP 79. These are the
memory module status, the lock register status, the I/O module status, the
error status, the memory controller status, and the write buffer status
messages, respectively. In addition, the resource check logic block 67
generates ARB (arbitration) commands for input to the MUX 41a and a ARB
MUX SELECT command for selecting which input will be output from MUX 41a
for input to state device 42.
A-BUS TA 35 is a 64-bits wide bus. The signals on that bus include DAL
information, ECC (error correction code) information, and ACK
(acknowledgement) information. The ACK bit is processed by memory read
data path ("MRDP") 81. The output of MRDP 81 which includes the DAL and
ECC information is input to MEMC/DBEC 77. The DAL information here is
generally refill data. The output of MEMC/DBEC is the refill data and this
output is one of the inputs to MUX 41a.
MEMC/DBEC 77 also provides an output on A-BUS FA bus 33. This output
includes the DAL, ECC, FC, and parity information. This information on
A-BUS FA bus 33 is input to memory modules 31a-f. The output of MUX 41a
through the state device 42 includes the same information that MEMC/DBEC
77 put on A-BUS FA 33 except that the ECC information is not included.
When the appropriate command signal on bus 36 is input to resource check
logic 67, the resource check logic uses the status information input from
MMAP 69, LOCK 71, CPIO 73, IREQ/SNIT 75, MEMC/DBEC 77, and MWDP 79 to
arbitrate between the different inputs to determine which input will be
given access to E-BUS TA buses 21-24 through MUX 41a and state machine 42.
The signals that desire access to these buses are the RSCK (resource
check) DAL and RSCK FC signals on bus 36, MMAP LW RD (longuard read) DAL
signal output from MMAP 69, LOCK LW RD DAL signal output from LOCK 71, the
CPIO LW RD DAL signal output from CPIO 73, the IREQ/SNIT LW RD DAL output
from IREQ/SNIT 75, and the METL REFILL DAL signal output from MEMC/DBEC
77. Resource check logic 67 controls access to these buses via the output
lines coupled through state devices 67a and 67b and the ARB MUX SELECT
signal output from resource check logic 67.
The outputs from state device 67a on line 61 and 85 are for controlling
access of E-BUS TA bus information onto bus 36. The outputs from state
device 67b on lines 83 are for causing selected DAL information from MMAP
69, LOCK 71, CPIO 73, IREQ/SNIT 75, and MEMC/DBEC 77 to be input to MUX
41a, for causing status updates for MMAP 69, LOCK 71, CPIO 73, IREQ/SNIT
75 and MEMC/DBEC 77, and changing the internal states of any of these
blocks.
FIG. 5 is a more detailed block diagram of the scheduling logic 66 of FIG.
4. As stated, the scheduling logic includes as major elements port select
logic 65 and MUX 37a. The output of the port logic 49 on bus 63 is input
to scheduling logic 66. This input includes the port DAL signals, the port
FC signals, the port "snoopy hit" signals, and the port CMD VALID (command
valid) signals. The selection of which of these signals will be output
from port logic 49 is determined by validity logic 57.
Referring to FIG. 5, lines 87 of bus 63 carry the port "snoopy hit"
signals. These signals are inputs to priority encoder 89 and OR gate 91.
The output of priority encoder 89 is input to MUX 403. The output of OR
gate 91 is input to port select generator 93.
Lines 96 of bus 63 carry the DAL and FC signals. These signals are the
inputs to MUX 37a. The FC lines signals are also input to OLD FC MUX 95.
Lines 97 of bus 63 carry the port CMD VALID signals. These signals are
inputs to barrel shifter 99. The output of barrel shifter 99 is input to
priority encoder 401. The 4-bit output of priority encoder 401 is one of
the inputs to MUX 403. This 4-bit output is also input to left shift one
block 405. The output of left shift one block 405 is one of the inputs to
MUX 407. MUX 407 has state device 409 disposed at its output. The output
of state device 409 feeds back as the second 4-bit input to the MUX 407
and as a control input to barrel shifter 99.
The first 4-bit input to MUX 403 is a feed back signal from state device
411. This is the last input to MUX 403. The 4-bit output of MUX 403 is
input to state device 411. The cycle after the output from MUX 403 is
input to state device 411, it is provided at the output of the state
device. The 4-bit output of state device 411 is also input to the
selection inputs of OLD FC MUX 95 which has as inputs the FC signals from
lines 96 of bus 63.
The output of MUX 95 on line 419 is the OLD FC signal. This is an input to
port select generator 93 along with the output of OR gate 91 and two other
inputs. These two other inputs are the SCHD GRANT signal on line 85a and
SNOOPY HIT SHADOW signal on line 85b. Both of these signals are output
from state device 67a of arbitrator 51. These signals are for controlling
access of the E-BUS TA buses to bus 36.
The first output of port select generator 93 is the selection input of MUX
403. The second output is input to the selection input of MUX 407. The
control of these two MUXes determines the content of the output from MUX
37a on bus 36 and what the 4-bit SCHD ID signal on line 86 will be. The
output of MUX 403 is input to the selection input of MUX 37a whose output
is bus 36.
Referring to FIGS. 4 and 5, the operation of the scheduling logic shown at
FIG. 5 will now be discussed. Assuming the system is activated and
awaiting operating instructions, the port CMD VALID signals on the lines
97 of bus 63 are input to barrel shifter 99. This is the initial action
because the first thing that must be determined is which commands and data
are valid since only those ports having valid commands and data can be
granted access to the bus 63. Hence, each port CMD VALID signal is
evaluated to determine if it has the proper state indicative of valid
commands and data.
Assuming that all four ports have valid commands, priority encoder 401
prioritizes the ports with the highest priority being output first from
the priority encoder on line 413 as the "current port" signal. This is
also input to left shift one block 405. The output of the left shift one
block is the next port in the sequence. So, the output of the left shift
one block is the "next port" signal, which is input to MUX 407. The other
input to MUX 407 through state device 409 is a feed back signal. This
signal also connects to the control inputs to barrel shifter 99. Hence,
the signal will cause the barrel shifter to point to the port associated
with this signal. The signal that usually is at the feed back loop is the
"current port". This is true until changed by the selection of the "next
port".
As an example, assume that the priority encoder 401 determines that port
"0" should have access to bus 36 first. The 4-bit output of priority
encoder 401 is input to,left shift one block 405 and, as such, will shift
left one block to indicate the next port which according to a normal
sequence would be port "1."
The output of left shift one block 405 is loaded into the second input to a
MUX 407. The first input to MUX 407 is the current port, which is port
"0," and is the present output of MUX 407 and latched in state device 409.
This signal is fed back to an input of MUX 407. The state device continues
to feed back port "0" until the port "0" information has been fully
transmitted. This is controlled by port select generator 93 continuing to
select the feed back input until port "0" has completed placing its data
on bus 36.
When port "0" has completed its transmission, port select generator 93
selects the second input to MUX 407 which is the output of left shift one
block 405. This will now provide the "next port," port "1," at the output
of MUX 407. On the next cycle, the "next port" signal will be output from
state device 409 and fed back to the first input to MUX 407.
When this value designating port 1 is output from state device 409, it is
also input to the barrel shifter 99. The new port designation signal
advances the barrel shifter by one, so long as the "next port" in the
normal sequence order has a valid port CMD VALID signal. If the next port
in sequence is not valid, the barrel shifter advances to the next valid
port.
The output of the barrel shifter 99 is input to priority encoder 401 which
now provides an output representative of the new port. As such, the newly
selected port becomes the "current port" and a new "next port" is selected
in the above described manner. This method of operation would continue
with each port having its turn in round robin fashion.
The output from port select generation 93 that is input to the selection
input of MUX 403, usually selects the "current port" input for output from
that MUX. This "current port" output will select its signals for output
from MUX 37a on bus 36. It is only when other events take place that the
other inputs to MUX 403 are selected for output as will be described.
Now that the method by which a port is given access to bus 36 has been
described, the operation of scheduling logic 66 will be discussed.
Each command is usually followed by at least one word. This word may be an
address, or data (in the case of a refill). This address or data may be
followed by additional data (in the case of a write command), a refill
command, or a SWAP command (a combined read and write command).
Once a port is given access to the bus, it must continue to be given access
until it is finished transmitting its commands or data onto bus 36. For
example, in the case of a SWAP command, the port must have continuous
access to send the SWAP command, a read address, a write back command, a
write address, and then the write data. During the time that the data and
commands are being sent, FC changes states according to what is on the DAL
lines. If it is a command, it has one state and the other state if it is
not a command.
The purpose of the MUX 403 is to select between a "previous port", a
"snoopy port", and the "current port". As stated, it is only when
predetermined events take place that the "previous port" or "snoopy port"
inputs to MUX 403 are selected. The method of selecting the output of MUX
403 will now be discussed.
The output of MUX 403 is input to the selection inputs of MUX 37a. This
determines which port is granted access to bus 36. Normally, the output of
MUX 403 is the "current port"; hence the "current port" is selected at MUX
37a. The "current port" is also input to state device 411. On the clock
cycle after the "current port" is input state device 411, with the output
therefrom on line 417. This output is input to the selection inputs of OLD
FC MUX 95 and fed back as the "previous port" put to MUX 403.
After passage of one cycle, the information being transmitted on the port
selected at MUX 37a is data or addresses, and not a command. Accordingly,
the FC signal will change states. This new state will be input to port
select generator 93. This will cause the SCHD MODE SELECT (scheduling mode
selector) output of the generator to have a bit pattern that will select
the "previous port" input to MUX 403 which is latched in state device 411.
The "previous port" value will remain as the output of MUX 403 until the
state of the FC signal on line 419 changes signifying the end of data and
the presence of a new command. It is only then that port select generator
93 will change its selection signals to select the "current port" rather
than the "previous port." This action ensures that data transmission is
complete before another command is placed on bus 36.
In the meantime, in response to the change in state of the FC signal on
line 419, the "next port" value is selected at MUX 407. This is done by
port select generator 93 changing which output the selection signals
selects to be output from MUX 407. Once selected, the "next port" signal,
through state device 409, is fed back to MUX 407 and barrel shifter 99.
Barrel shifter 99 then selects the next valid port, which now becomes the
"current port" on line 413. The scheduling logic 66 now awaits the next
change in the state of the selected FC signal for repeating these actions.
As an example of the operation of scheduling logic 66, the following is
provided.
During normal operations, without a "snoopy hit," when the "current port",
e.g., port "0", is selected and coupled through MUX 403, this "current
port" signal makes the selection of the "current port" DAL and FC at MUX
37a. On the next clock cycle, this port designation, i.e., port "0", is
available at the output of state device 411. The output of state device
411 selects the corresponding port FC signal to be output from MUX 95.
Thus, if port "0" is the current port, the FC bit for port "0" will be
output from MUX 95 and fed back to port select generator 93.
During the first cycle, which contained a command, the FC bit, for example,
may be a logic "1" value. On the second cycle, when other than a command
is transmitted, it will change to a logic "0" value.
When the port "0" FC signal switches, this changed value is input to port
select generator 93. In response to this change, port select generator 93
will select the "previous port" input that is output from state device
411. Hence, the output of MUX 403 is the "previous port" input. This all
results in a holding period so that all of the port "0" information can be
transmitted. Once the FC signal changes states | | |
