 |
Claims  |
|
|
We claim:
1. A data hub for controlling data flow between a plurality of data
source/destination units interconnected to the hub via control signal
lines and via parallel address/data signal lines, the source/destination
units having addressable memory locations, the data hub being responsive
to at least one pair of address pointer input control signal words, to a
word count input control signal word and to a channel enable input control
signal word provided by a master source/destination unit, said input
control signal words being indicative of one or more scheduled data signal
word transfers to be effected by the hub from one or more memory locations
within a data SOURCE/destination unit used as a channel source unit in a
channel enabled in the data hub by the channel enable input control signal
word, the one or more scheduled data transfers to be effected by the hub
from the SOURCE/destination unit to one or more memory locations within an
enabled channel data sorce/DESTINATION unit used as a destination unit,
the first of the one or more channel source unit memory locations
indicated by a source address pointer input control signal word and the
remainder by a number of sequential increments or decrements of the source
address pointer input control signal word equal to the word count, the
first of one or more destination memory locations indicated by a data
transfer destination address pointer input control signal word and the
remainder by a number of sequential increments or decrements of the
destination address pointer control signal word equal to the word count,
the data hub comprising:
storage means, for temporarily storing data transferred from the enabled
channel data SOURCE/destination for later transfer to the enabled channel
data source/DESTINATION; and
control means, responsive to the source and destination address pointer
input control signal words, to the word count and to the channel enable
input control signal words, for providing a source data transfer request
output signal to the enabled data SOURCE/destination unit and for
subsequently receiving, in return, a source bus grant signal from the
enabled data SOURCE/destination unit, said control means responsive to
said source bus grant signal for providing said source address pointer
input control signal word an an output signal to said enabled data
SOURCE/destination unit, said storage means concurrently receiving and
temporarily storing source data signal word from a memory location within
the SOURCE/destination unit as indicated by said source address pointer
output control signal word, said control means then providing a
destination data transfer output request signal to the data
source/DESTINATION unit and subsequently receiving, in return, a
destination bus grant signal from the data source/DESTINATION unit, said
control means responsive to said destination bus grant signal for
providing said destination address pointer input control signal word as a
destination address pointer output control signal word to said data
source/DESTINATION unit and concurrently providing a transfer of said data
signal word from said storage means to a memory location within said
source/DESTINATION unit as indicated by said destination address pointer
output control signal and, said control means incrementing or decrementing
the source and destination address pointer output signals and decrementing
the word count signal and cyclically repeating the transfer of data from
the enabled channel's data SOURCE/destination unit to the data
source/DESTINATION unit until the word count signal equals zero.
2. The data hub of claim 1, wherein said control means is further
responsive to asynchronous incoming direct serial data signal word
transfers to said storage means and to asynchronous serial data transfer
request signal words from selected ones of said plurality of data
source/destination units, and wherein said control means, in response
thereto,
categorizes scheduled data signal word transfers in a low priority transfer
category, asynchronous incoming direct serial data signal word transfers
in an intermediate priority transfer category, and asynchronous serial
data transfer request signal words in a high priority transfer category,
said control means providing prioritized data transfer request output
signal words in keeping with said priority categories, and wherein said
control means is responsive to said high priority asynchronous serial data
transfer request signal words from a high priority data source/destination
for providing an enable signal which permits said high priority data
source/destination to immediately transmit/receive data signal words
directly from/to another data source/destination, said control means also
responsive to said intermediate priority asynchronous incoming direct
serial data signal word transfers to said storage means for effecting said
intermediate priority asynchronous incoming direct serial data signal word
transfers after all transfers represented by high priority asynchronous
serial data transfer request signal words are completed by providing a
destination bus request signal to an intermediate priority data
source/DESTINATION unit used as a destination unit and for subsequently
receiving, in return, a destination bus grant signal from said
intermediate priority data source/DESTINATION unit, said control means
providing a data signal word transfer from said storage means to a memory
address within said intermediate priority source/DESTINATION unit after
said destination bus grant signal has been provided, said control means
also responsive to said low priority scheduled data signal word transfers,
for effecting the one or more low priority data signal word transfers
after all transfers associated with high priority asynchronous serial data
transfer request signal words and all intermediate priority data signal
word transfers are completed.
3. A data hub for handling a plurality of data transfers between a
plurality of data source/destination units, comprising:
storage means, for temporarily storing signals transferred from a data
source/destination; and
control means, responsive to a source address pointer input signal, to a
destination address pointer input signal, to a word count input signal and
to a channel enable input signal, each input signal provided by a master
source/destination unit, said control means storing said address pointer
signals and said word count signal in said storage means, said input
signals being indicative of one or more scheduled data transfers to be
sequentially effected in a series of data transfer cycles equal in number
to the magnitude of said word count signal, said control means enabling a
channel indicated by said channel enable signal, said hub effecting data
transfer cycles from memory locations within a data SOURCE/destination
unit in said enabled channel as indicated by said source address pointer
input signal and said word count signal, to memory locations within a data
source/DESTINATION unit in said enabled channel, as indicated by said
destination address pointer input signal and said word count signal, said
control means, for each of said data transfer cycles:
(1) providing a source data transfer request output signal to said data
SOURCE/destination and
(2) subsequently receiving, in return, a source bus grant signal from said
data SOURCE/destination, said control means responsive to said source bus
grant signal for
(3) providing said source address pointer input signal as an output signal
to said data source, said storage means receiving and temporarily storing
source data from a memory location within said SOURCE/destination as
indicated by said source address output signal, said control means then
(4) providing a destination data transfer output request signal to said
data source/DESTINATION and subsequently receiving, in return, a
destination bus grant signal from said data source/DESTINATION, said
control means responsive to said destination bus grant signal for
(5) providing said destination address pointer input signal as an output
signal to said data source/DESTINATION and providing a data transfer from
said storage means to a location within said source/DESTINATION as
indicated by said destination address output signal.
4. The data hub of claim 3, wherein said control means is further
responsive to asynchronous incoming direct data transfers to said storage
means for storage therein and to asynchronous transfer requests from
selected ones of said plurality of data source/destination units, and
wherein said control means priorities said scheduled data transfers as low
priority, asynchronous incoming data transfers as intermediate priority,
and asynchronous transfer requests as high priority, said control means
providing prioritized data transfer request output signals in keeping with
said priority order, and wherein said control means is responsive to said
high priority asynchronous transfer request signals from a high priority
data source/destination for providing an enable signal which permits said
high priority data source/destination to immediately transmit/receive data
from/to another data source/destination, said control means also
responsive to said intermediate priority asynchronous incoming direct data
transfers to said storage means for temporary storage therein and for
effecting said intermediate priority asynchronous incoming direct data
transfers after all tasks represented by high priority asynchronous
transfer request signals are completed by providing a destination bus
request signal to an intermediate priority data source/DESTINATION unit
and for subsequently receiving, in return, a destination bus grant signal
from said intermediate priority data source/DESTINATION unit, said control
means providing a data transfer from said storage means to an address
within said intermediate priority source/DESTINATION unit after said
destination bus grant signal has been provided, said control means also
responsive to said low priority scheduled data transfers, for effecting
said low priority scheduled data transfers after all transfers associated
with high priority asynchronous transfer request signals and all
intermediate priority data transfers are completed. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
TECHNICAL FIELD
This invention relates to multiple processor and to distributed processor
systems, and more particularly to means for transferring data between
distributed processors and between multiple processors.
BACKGROUND ART
Multiprocessor system architectures for distributed processing often employ
shared common memory between processors. This may be accomplished in a
multiprocessor system using multiport memories, or architectures including
cross bar switches, a time-shared common bus, or a dual-bus structure.
A multiport memory system employs separate buses between each memory module
and each processor. Each processor bus is physically connected to each
memory module. Each memory module is multiported, each port accommodating
one of the buses. Each memory module may have internal control logic to
determine which port will have access to memory at any given time. Memory
access conflicts are resolved by assigning priorities to each memory port.
High transfer rates can be achieved because of the multiple paths between
processors and memory.
A multiprocessor cross bar switch architecture provides switched cross
points placed at intersections between processor buses and memory module
paths. Each switch point has control logic to set up the physical transfer
path between a processor and memory. The control logic examines the
address that has been placed on the bus to determine whether its
particular module is being addressed and also to resolve multiple requests
for access to the same memory module on a predetermined priority basis.
In a multiprocessor time-shared architecture, a number of processors may be
connected through a common path to a memory unit. In such a system only
one processor can communicate with the memory at any given time. Transfer
operations are controlled by the processor that is in control of the bus
at any given time. Any other processor wishing to initiate a transfer must
first determine the availability status of the bus, and only after the bus
become available can the processor address the memory unit to initiate the
transfer. The system may exhibit memory access conflicts since one common
bus is shared by all processors. Memory contention must be resolved with a
bus controller that establishes priorities among the requesting units. The
time-shared architecture is disadvantageous because when one processor is
communicating with the memory, all other processors are either busy with
internal operations or must be idle waiting for the bus.
A more efficient architecture than the time-shared common bus
multiprocessor architecture is a dual-bus multiprocessor organization in
which a number of local buses are each connected to a local memory and to
one or more processors. System bus controllers associated with each local
bus are used to link each local bus to a common system bus. In most
designs, the devices connected to the local bus are available to the local
processors only. Memory connected to the common system bus is shared by
all processors. The system may be configured to permit devices attached to
the local bus to be accessed by processors on other local buses. Only one
processor can communicate with the shared memory and any other common
resources through the system bus at any given time. The other processors
on the local buses are kept busy communicating with their local memory and
local devices. Although such a system qualifies as a multiprocessor
system, it can also be classified more correctly as a multiple computer
system. This is because when a processor, memory, and other devices are
connected together on a local bus the local group constitutes a computer
system in its own right.
For safety reasons many systems are organized in a redundant fashion having
multiple computers operating independently. Other redundant systems permit
semiautonomous operation of distributed processors and provide that a
failed processor or related device can be severed from the system without
catastrophically degrading overall system operation.
Distributed multiple processor systems must operate semiautonomously to
obtain maximum efficiency. To acheive near independence despite their
interconnected communication links they must utilize some means of
transferring data between distributed processors which avoids processor
overhead. This may be acheived to some degree by using multiport memory
units having physically isolated address and data input buses for each
port. Hand-shaking between processors provides the necessary control for
transferring data between processors using the multiport memory unit as an
intermediary. Although the use of shared memory provides a degree of
addressing freedom, only one processor is allowed access to the memory at
any given point in time. This restriction may not be acceptable for some
system design requirements, i.e., it may not be acceptable to deprive a
processor of free access to memory.
A partial solution to the problem of system requirements not permitting the
"wait" states dictated by shared memory is the use of a first-in-first-out
(FIFO) buffer between processors. In this way no processor is deprived of
immediate access to memory and freedom of data flow is therefore ensured.
Data may be input and output at two different rates and the output data
are always in the same order in which data entered the buffer. For
bidirectional flow FIFO buffers may be employed in both directions.
However, the freedom of addressing acheived with shared memory is lost in
the FIF buffer solution.
In addition to the individual advantages of the shared memory and FIFO
buffer approaches described above, both approaches still suffer, despite
the isolation provided by additional memory, from a certain lack of
processing independence which is most desirable. In the case of a shared
memory the denial of access to a processor at any given time results in
undesirable wait states which decrease system efficiency. In the case of
CPU buffered by FIFOs the information which may be provided by shared
addressing is not available. I.e., while a CPU can control the position
assignment of data when writing into a FIFO, it has no control of the
assignment of data when reading from a FIFO. In other words, the reading
CPU may have to read data of no present interest before getting to the
stored position of present interest.
The desirability of providing more efficient processing for distributed
processors becomes more important as the complexity of the system
increases. As the number of processors increases and the
intercommunication requirements become more complex, the disadvantageous
opportunities for creating undesirable wait states also increase. Thus, a
means of increasing processing efficiency while maintaining or increasing
relative semi-autonomous operation is needed.
DISCLOSURE OF THE INVENTION
The object of the present invention is to provide a keystone building block
for use in linking processors which functions as a modular multiport data
hub for facilitating and effecting data transfers between processors with
high efficiency.
According to the present invention, a control processor or master CPU and
an associated memory together may exchange data with one or more
distributed devices, which may include other processors having similar
associated memory units, by linking the control processor and its
associated memory to each of the other devices and their associated
memories, if any, with a modular multiport data hub. After initialization
by the master CPU, the data hub may generate data transfer requests at the
behest of the master CPU to one or more of the linked devices. Upon
generation of one or more requests the data hub initiates a request for a
data transfer to the device designated as a data source by the master CPU.
The generation of a request by the hub to the designated data source
initiates a direct memory access cycle. It is the prerogative of the data
source to continue processing, or relinquish control to the hub.
Instruction processing of the data source is undisturbed. Once the hub has
obtained the required data from the data source it will then store the
data and attempt to transfer the data to a designated destination unit at
the convenience of the destination unit. Thus, the hub will inform the
destination unit that it has data ready for transfer and will wait until
the destination unit decides that it is convenient to accept the data.
Once the destination unit signals the hub that it should proceed with the
transfer, the destination unit may resume executing any unrelated program
which requires immediate attention while the hub is granted direct access
to the destination unit's associated memory. Depending on the particular
processor used at the destination, it may be required to wait during the
transfer until it is complete before returning to normal program
execution. The hub may include plural parallel format data channels only
or combinations of parallel and serial format channels.
In further accord with the present invention, each of the channels may have
a programmable priority established within the hub which permits the
arbitration of competing data transfer requests from the various devices
associated with each of the channels. Thus, if one or more transfer
requests are received by the hub from separate channels having different
assigned priorities, the device having the highest priority will be
granted transfer access first while the competing channel's or channels'
request(s) will be put in a request queue and each will be granted
transfer access after all higher priority transfers have been effected
according to the programmed transfer priorities. The priority scheme may
be structured so as to permit interruption of lower priority transfers in
progress when a higher priority transfer request occurs. Such a lower
priority transfer can be resumed after the higher priority transfer has
been effected.
In still further accord with the present invention, a maskable interrupt
line may be provided in the hub which is reprogrammable to be responsive
to a selected combination of independent interrupt conditions.
In still further accord with the present invention, the multiport data hub
according to the present invention may be used as a keystone element in
the construction of distributed processor systems. Its use as a modular
building-block-like device as a hub for interfacing between multiple
processors provides a versatile construction element which provides highly
desirable independence between distributed subsystems. Thus, a
multiplicity of processors may be interfaced to a modular multiport data
hub and a plurality of modular multiport data hubs may be linked to each
other in constructing a complex distributed processor system having
numerous multiprocessor subsystems. Each modular multiport data hub
functions as a data transfer focal point in an overall system having
numerous such data transfer focal points.
Thus, the modular multiport data hub, according to the present invention,
is a modular building-block-like device which constitutes a data hub which
may be replicated as often as required in the construction of distributed
processor systems in particular and which may also be used for more
limited purposes in multiple processor applications. It combines the
addressing independence of shared bus systems such as dual port RAMs with
the freedom of information flow of FIFO architectures by implementing a
multi-channel interface device, each channel having a DMA structure. Data
may be transferred between distributed processors with very little
processor overhead.
These and other objects, features and advantages of the present invention
be will become more apparent in the light of the following detailed
description of an exemplary embodiment thereof as illustrated in the
accompanying drawing.
BRIEF DESCRIPTION OF DRAWINGS
FIGS. 1A & 1B, arranged as shown in FIG. 1, are an illustration of a
distributed processor system having a plurality of modular multiport data
hubs, according to the present invention, utilized as keystone building
blocks;
FIG. 2 is an illustration of a system is which a pair of redundant systems
are each designed using two data hubs;
FIG. 3 is another illustration of a redundant system using two data hubs in
each subsystem;
FIG. 4 is a simplified block diagram illustration of a modular multiport
data hub, according to the present invention;
FIG. 5 is a simplified block diagram illustration of a multiport data hub,
according to the present invention, which is capable of transferring data
between a plurality of parallel and serial channels;
FIGS. 6A & 6B, arranged as shown in FIG. 6, are a simplified block diagram
illustration of a multiport data hub, according to the present invention,
having only two ports for interfacing with two subsystems;
FIGS. 7A & 7B, arranged as shown in FIG. 7, are a simplified illustration
of two flowcharts which are illustrative of the steps executed within the
multiport data hub of FIGS. 6A & 6B;
FIG. 8 is a flowchart illustration of the steps executed in a typical
subsystem CPU while at the same time showing the steps executed in the
multiport data hub, according to the present invention;
FIGS. 9A & 9B, arranged as shown in FIG. 9, are a simplified block diagram
illustration of an embodiment of a modular multiport data hub, according
to the present invention;
FIG. 10 is a timing diagram showing some typical waveforms for a serial
transfer using the hub of FIGS. 9A & 9B;
FIG. 11 is a timing diagram for illustrating the sequence of events within
the data hub of FIGS. 9A & 9B during a Manchester transmitter transfer;
FIG. 12 presents a number of waveforms showing some of the timing
relationships involved in transferring data between the CPUs within
subsystems 1 & 2 of FIGS. 9A & 9B. The timing shown illustrates a one word
block transfer;
FIG. 13 illustrates some of the timing relationships between signals
involved in transferring data in FIGS. 9A & 9B from subsystem 1 to
subsystem 2;
FIG. 14 shows the timing of a one word block transfer in FIGS. 9A & 9B from
subsystem 1 to subsystem 2; and
FIGS. 15A & 15B are an illustration of word definitions for the data hub of
FIGS. 9A & 9B. FIGS. 15A & 15B illustrate the lower and upper bytes of
each word, respectively.
BEST MODE FOR CARRYING OUT THE INVENTION
FIGS. 1A & 1B are an illustration of a distributed processor system having
a plurality of modular multiport data hubs 10 according to the present
invention. Each hub interfaces with a plurality of data source/destination
units 12 each of which may be any one or more of a variety of devices
including processors with dedicated memory, I/O controllers, I/O devices,
interface devices, and many others. The data source/destination units 12
may even include entire systems which could, for example, be exact
replicas of the system shown in FIGS. 1A & 1B. Such a redundancy scheme
would be used for insuring data integrity. Data links 14 are used to link
each data source/destination 12 with an associated modular multiport data
hub 10. These links 14 may be serial or parallel, synchronous or
asynchronous.
A modular multiport data hub 10, according to the present invention, is
intended as a building-block unit for the construction of multi-processor
systems, particularly distributed processor systems. However, it should be
borne in mind that the data hub of the present invention may also be used
in multiple processor systems. The data hub 10 may be used by a system
designer as a keystone element which transfers data between source and
destination with little or no source/destination processor overhead. A key
feature of the hub design is that it does not require the sharing of
memory between data sources and data destinations. This permits much of
the overhead demanded by previous systems to be eliminated.
FIG. 2 is an illustration of a system 20 in which a pair of redundant
systems 22, 24 are each designed using two data hubs 26, 28 and 30, 32.
The two systems 22, 24 are able to communicate with one another via two
separate serial data links 34, 36. Thus, data hub number 1 26 is serially
linked via link 34 to data hub number 3 30. Similarily, data hub number 2
28 is serially linked via serial link 36 to data hub number 4 32. In
general, any of the devices within system 22 may communicate with any of
the devices within system 24 via either of the serial data links 34, 36.
In practice, however, only selected units within a given system will
normally communicate with other selected units in another system. In the
system architecture of FIG. 2, each hub 26, 28, 30, 32 interfaces via
parallel links 38, 40, 42, 44, 48, 50, 52, 54 with a pair of local buses
56 and 58, 56 and 60, 62 and 64, and 64 and 66, respectively.
Each of the local buses 56, 58, 60, 62, 64, 66 interfaces with a group of
devices 68, 70, 72, 74, 76, 78. Each group shown in FIG. 2 contains a CPU
and a memory unit (MU). Each of the CPUs and MUs are numbered in FIG. 2
assuming that the associated local bus is similarily numbered. In other
words, data hub number 1 26 links local bus number 1 56 and local bus
number 2 58 along with hub number 3 30. Thus, CPU number 1 may transfer
data from its MU number 1 via local bus number 1 56, parallel link 38, and
data hub number 1 to any of the other devices in the system 20.
Similarily, in FIG. 3, still another redundant system 80 is illustrated
having redundant subsystems 82, 84 illustrated. The chief differences
between the systems illustrated in FIGS. 2 and 3 are that additional
serial data links 86, 88 exist between hubs 1 and 2 and hubs 3 and 4,
respectively, and also there is no sharing of local buses between hubs in
the same subsystem. Of course, it should be understood that the system
architectures illustrated in FIGS. 1A & 1B, 2, and 3 are merely several
architectures out of a wide variety of architectures which may be
constructed using a modular multiport data hub according to the present
invention.
FIG. 4 is a simplified block diagram illustration of a modular multiport
data hub 10 according to the present invention. The multiport data hub
shown in FIG. 4 is a dual port data hub and is presented with only two
ports for the sake of simplicity. It should be understood, however, that
the inventive concept disclosed herein embraces a plurality of ports
within the data hub and the inventive concept is not restricted to dual
port data hubs.
The multiport data hub 10 of FIG. 4 is shown interfacing with System A 90
and System B 92. Both System A and System B have a CPU 94, 96 and an
associated memory unit 98, 100. Each System's CPU communicates with its
associated Memory Unit via data, address, and control buses indicated
generally by a single bus line 102, 104. Each of the buses 102, 104
communicates with the multiport data hub 10 separately at separate ports.
Thus, there is no sharing of memory between System A and System B.
Handshaking control lines 106, 108, and 110 are provided between System A
and the multiport data hub. Similarily, handshaking lines 112, 114, and
116 are provided between System B and the multiport data hub. It should be
understood that the three handshaking control lines between the hub and
each CPU could be reduced to two handshaking lines between the hub and
each of the CPUs. This will depend upon the handshaking philosophy
required by the individual CPUs.
It should also be understood that the multiport data hub illustrated in
simplified form in FIG. 4 is not, as mentioned above, restricted to merely
a dual port implementation nor is it restricted to merely parallel
interfacing. Each hub can be individually configured, limited only by bus
bandwidth considerations, to include a large number of parallel channels
along with numerous serial channels, as shown in FIG. 5. Bus bandwidth is
the maximum transfer rate allowed on a given memory system. For example, a
memory unit system having 100 nanosecond access memory devices has a bus
bandwidth of 10 Megahertz. This limits the total number of channels to
that transfer rate. The overall system can communicate at the bandwidth of
the slowest memory unit within the system. Thus, in FIG. 5, a multiport
data hub 10 is capable of transferring data between N parallel channels
and Z serial channels. In other words, the multiport data hub according to
the present invention may be modularized in a wide variety of
architectures.
FIGS. 6A & 6B are a simplified block diagram illustration of a multiport
data hub 10 having only two ports interfacing with two subsystems 120,
122, as in FIG. 4, except that FIGS. 6A & 6B are slightly more detailed
than FIG. 4. Each subsystem 120, 122 interfaces with the multiport data
hub 10 via local buses 124, 126, respectively. Each subsystem includes a
CPU 128, 130 and a memory unit 132, 134.
The multiport data hub 10 of FIGS. 6A & 6B are shown having two channels
136, 138 each of which communicates with both local bus number 1 124 and
local bus number 2 126. Channel A 136 receives parallel information on
line 140 from local bus number 1 124 and provides that same information on
line 142 to local bus number 2 126. In general, the data received on line
140 will be identical to the data supplied on line 142 while the addresses
may or may not be identical. Channel B 138 receives data from local bus
number 2 126 on line 144 and provides that same data at the same or a
different address on line 146 to local bus number 1 124. Thus, Channel A
and Channel B may be characterized as uni-directional parallel data
channels. It should be understood, however, that Channel A and Channel B
could be combined into a single bi-directional channel according to the
present invention. Separate channels may be provided in order to enhance
the transfer rate independence of subsystem 1 120 and subsystem 2 122.
Each channel 136, 138 of the multiport data hub is divided into a receive
section 148, 150 and a transmit section 152, 154. The various receive and
transmit sections include word count registers 156, 158, 160, 162, buffer
registers 164, 166, 168, 170, and address registers 172, 174, 176, 178.
The multiport data hub 10 includes a request flipflop 180 associated with
Channel A and a similar request flipflop 182 associated with Channel B.
Also, a memory address register 184 is associated with Channel A while a
similar memory address register 186 is associated with Channel B. The data
hub 10 also includes a control unit 188 and a status register 190.
Each of the subsystems' 120, 122 CPUs' 128, 130 include an address register
192, 194, a buffer register 196, 198, and a request flipflop 200, 202.
Each of the subsystems' 120, 122 memory units 132, 134 includes a buffer
register 204, 206 and a memory unit 208, 210. A transfer of data between
subsystem number 1 120 and subsystem number 2 122 will be more easily
understood when described in connection with the flow charts of FIGS. 7A
and 7B.
FIGS. 7A & 7B are an illustration, by way of simplified example, of two
flowcharts which may run concurrently within the multiport data hub 10 of
FIGS. 6A & 6B. Beginning after a start step 200, in FIG. 7A a
determination is first made in a decision step 202 as to whether request
flipflop A 180 of FIGS. 6A & 6B are equal to one or not. If it is not, no
request has been made by any unit for access to subsystem number 1's local
bus 124. Therefore, a negative answer will cause the program to loop
continuously from step 202 back again to ask the same question again as
indicated by a line 204. If a request has been made for local bus 124 a
step 206 is next executed in which the multiport data hub 10 actually
requests local bus number 1 124. A step 208 next determines whether access
has been granted by CPU number 1 128. If not, the program continuously
loops through step 208 as indicated by a line 210 until access to the
local bus is granted. Once access is granted a step 212 is next executed
in which the Channel A receive address register 172 transfers its contents
to memory 1 address register 184. Channel A receive address register 172
would have received its contents from either CPU 1 or CPU 2 depending on
which is the CPU in control of the system transfers. A step 214 is next
executed in which the contents of memory space 1 208 at the addressed
location is transfered to memory 1 buffer register 204 and then transfered
to Channel A receive buffer register 164. The request flipflop A is then
set equal to zero in a step 216, request flipflop B is set equal to one in
a step 218, and local bus 1 124 is released in a step 220. The program
then loops back to step 202 as indicated by a line 222.
As soon as request flipflop B is set equal to one in step 218, the change
is detected in a step 224 as shown in FIG. 7B. Previous to the detection
in step 224 of a change to a state equal to one, the program shown in FIG.
7B would have been looping repeatedly through step 224 until a request is
detected. After detection, a step 226 is next executed in which the data
hub 10 requests access to local bus 2 126. A decision step 228 is next
executed in which a determination of whether access to the CPU bus has
been granted or not is made. If not, a continuous loop indicated by a line
230 is executed repeatedly until access is granted. Once granted, a step
232 is next executed in which the contents of Channel A transmit address
register 174 are transfered to memory 2 address register 186. In the next
step 234, the data contained in the Channel A transmit buffer register 166
is transfered to the memory 2 buffer register 206 and then into the proper
address at memory space 2 210. The transmit buffer register 166 would have
received its contents from the receive buffer register 164 under the
control of the control unit 188. Similar transfers between the other
blocks within the receive and transmit sections will also have occurred
prior to any transfer. The request flipflop B is then set equal to zero in
a step 236. The contents of the transmit word count register 158 is then
decremeted by one in a step 238 and the bus 2 126 is then released in a
step 240. A decision is then made in a step 242 as to whether the transmit
word count register is equal to zero or not. If not, request flipflop A is
set equal to one in a step 244 and the steps following step 202 of the
FIG. 7A are then repeatedly reexecuted until all words have been
transfered.
If the word count register in step 242 of FIG. 7B was found to be equal to
zero, the CPUs are then informed in a step 246 that the transfer is
complete. A step 248 is then executed to determine whether the maskable
interrupt has been enabled by the master CPU. If the interrupt is enabled
a designated CPU is interrupted in a step 250 and a return is made to step
224. If the interrupt was not enabled the program returns immediately to
step 224 without interrupting any CPU. Of course, it will be understood
that the flow program can be implemented using a state machine.
A simplified flowchart in FIG. 8 shows the sequence of events in a CPU in a
typical subsystem and at the same time the sequence of events taking place
in the multiport data hub. One may imagine an imaginary timeline running
from the top of the figure to the bottom. In this case, the CPU is the
control CPU and it first sets up the channels in the data hub for a data
transfer in a step 300. The data hub responds by starting channel activity
in a step 302. Meanwhile, the CPU is free to execute any unrelated
programs as shown in a step 304. When the channel determines that it needs
or has data for transfer in a step 306 it will set request flipflop A
equal to 1 in a step 308. The CPU periodically executes a step 310 to
determine whether a request exists or not. If not, a return is made to
executing any unrelated programs in step 304. If so, the CPU determines in
a step 312 whether it is busy or not. If so, a return is made to execute
any unrelated programs in step 304. If not, the CPU sets its request
flipflop equal to 1 in a step 314 and at the same time, depending on the
particular implementation, determines whether it will wait for the
transfer to be complete. If the particular processor implementation does
not require the CPU to wait for the transfer to be complete, the CPU
determines in a step 316 that it is unnecessary to wait for the transfer
to be complete and a step 318 is next executed in which the CPU request
flipflop is set equal to zero again. If, because of the particular
processor implementation, it is necessary to wait for the transfer to be
complete before proceding to execute any unrelated programs, the CPU will
determine in step 316 that a wait for a transfer is required and a step
320 will next be executed in which a determination is repeatedly made as
to whether the transfer is complete or not. If not, step 320 is reexecuted
repeatedly as indicated by a line 322 until the transfer is complete. Once
the transfer is complete step 318 is next executed where the CPU request
flipflop is reset to zero and control is once again returned to step 304
and unrelated programs may continue to be executed by the CPU.
After the CPU request flipflop was set equal to one in step 314, the data
hub, which will already have been waiting in a step 324 for the CPU
request flipflop to be set equal to one in step 314, will next execute a
step 326 in which the data transfer is effected between the hub and the
CPU. After the transfer is complete, the data hub will set its request
flipflop A equal to zero again in step 328 and this will signify to the
CPU in step 320 that the transfer is complete.
FIGS. 9A & 9B are a simplified block diagram illustration of an embodiment
of a modular multiport data hub 10 according to the present invention. The
particular embodiment illustrated in FIGS. 9A & 9B has two serial
input/output ports and two parallel input/output ports. Subsystem #1 is
the master CPU in this embodiment. The hub shown in FIGS. 9A & 9B could be
used in the architecture of FIG. 3, for example. There, each hub
interfaces with two serial data links and two parallel data links. It
should be understood, that the particular embodiment shown in FIGS. 9A &
9B which, as pointed out, may be used to advantage in the architecture of
FIG. 3, is merely one of a large variety of internal structures which
could be selected for particular embodiments of the modular multiport data
hub according to the present invention. The embodiment shown in FIGS. 9A &
9B should be understood therefore as merely illustrative of an embodiment
for a particular system architecture using the teachings of the present
invention.
The structure of the two parallel input/output ports of the particular
embodiment of FIGS. 9A & 9B include a separate data bus 350 and a separate
address bus 352 at a first parallel port and a multiplexed data/address
bus 354 at a second parallel port. The address output from the hub 10 to
subsystem #2 on lines 354 at the second parallel port must be latched
externally before data is sent out or received over those same lines.
Of course, it will be understood that the peculiarities of the particular
address, data, and control line structures disclosed herein (in connection
with FIGS. 9A & 9B) which link the hub to its satellite subsystems, hubs,
etc., are mere expedients dictated by the circumstances of the particular
embodiment shown. Therefore, many other data transfer linking structures
are contemplated to be within the scope of this invention and those
disclosed herein should in no way be construed as limiting the scope of
this invention.
The multiport data hub 10 of FIGS. 9A & 9B are shown interfaced to two
additional multiport data hubs 10a, 10b with which it communicates via
serial lines 360, 362, 364, 366, MIL-STD-1553 remote terminal interface
(1553 RTI) 368, a subsystem number 1 370 and a subsystem 2 372, these last
two being similar to the subsystems shown in FIGS. 6A & 6B. Both
subsystems numbers 1 and 2 include a CPU unit and a memory unit (not
shown). As mentioned, subsystem #1 is the master in this embodiment.
The particular embodiment of the modular multiport data hub 10 according to
the present invention pictured in FIGS. 9A & 9B handles data transfers of
six types. Transfers take place between the multiport data hub 10 and
subsystem number 1 370, the two data hubs 10a, 10b via two Manchester
transmitter/receiver pairs 374, 376 and 378, 380, the 1553 RTI 368, and
subsystem number 2 372. The following prioritized DMA transfers are
possible in the embodiment illustrated:
1. Transfer from/to the 1553 RTI to/from subsystem number 1.
2. Transfer from hub number 3 10b to the subsystem number 1's memory.
3. Transfer from hub number 2 10a to subsystem number 1's memory.
4. Transfer to hub number 3 10b from subsystem number 1's memory.
5. Transfer to hub number 2 10a from subsystem number 1's memory.
6. Transfer from/to subsystem number 1's memory to/from subsystem number
2's memory.
The DMA requests are asynchronous to the control logic contained in a
control block 382. The requests for each transfer are prioritized in the
above order where number 1 is the highest priority and number 6 the
lowest. Each of the six transfers may be individually disabled by a mask
word written by the data transfer control (master) CPU, in this case
within master subsystem #1. Sixteen-bit address buses 352, 354 provide a
full 64K addressing space on both the subsystem number 1, the 1553 RTI,
and the subsystem number 2 buses.
The master CPU programs the hub to provide address pointers, word counts,
and to enable the desired channels for data transfers. FIGS. 15A & 15B
show word definitions for various sixteen-bit words transferred over the
data lines 350 of FIGS. 9A & 9B in conjunction with read and write decode
instructions sent over the address lines 352 from subsystem 1 to the hub.
In the case of the data lines, the sixteen-bit words are sent to various
reoisters within the hub. In the case of the read and write decodes, a
read decode is signaled to the hub by an IOR signal on a line 331
occurring in conjunction with a chip select (CSB) signal on a line 333 and
a write decode is signaled by a IOW signal on a line 335 occurring in
conjunction with the chip select signal. To program the hub, subsystem #1
first writes the address pointers to the appropriate registers within the
hub using the appropriate write decode. Then subsystem 1 initialzes the
proper word count register, again using the appropriate write decode.
Finally, the desired channels are enabled by subsystem 1 using write
decode 9.
1553 RTI TRANSFER DESCRIPTION
In preparation for a transfer, the 1553 RTI 368 will assert a request line
384. This request has the highest priority of all of the possible six
types of transfers. The data hub 10 will respond to this request if all
the following are satisified:
1. DMA channel 1 is enabled.
2. The current DMA cycle has completed, i.e., the hub is not currently
servicing another channel.
3. MTC from subsystem number 1 goes low, i.e., a memory toggle clock signal
on a line 386.
Referring now to FIG. 10, a timing diagram showing some typical waveforms
for a 1553 RTI transfer (external request DMA cycle) are shown. In FIG.
10(a) is illustrated a waveform 388 illustrative of a 12 MHz signal on a
line 390 in FIGS. 9A & 9B. FIG. 10(b) is an illustration of a memory
toggle clock (MTC) signal waveform 390 illustrative of the signal on the
line 386 from subsystem number 1's CPU. When MTC is high, DMA transfers
are permitted. When MTC is low, the individual subsystem CPUs are
| | |
