Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent
4319323
Ermolovich , ; et al.
March 9, 1982
Title
Communications device for data processing system
Abstract
A communications device transfers process data between a data processing system and an external device at high speed. The communications device receives command signals from a user process program in the data processing system and from the external device. The communications device generates physical addresses in the data processing system with respect to which process data is to be transferred, the physical addresses being generated in response to virtual addresses supplied in the commands. The communications device and the external device also each include apparatus for signalling the other that data is being transferred at too rapid a rate to be processed, or that data is temporarily not being transferred, to prevent data being lost and an error being sent to the data processing system.
Inventors:
Ermolovich; Thomas R.
(Lexington,
MA
)
, Stewart; Robert E.
(Stow,
MA
)
, Leonard; Judson S.
(Acton,
MA
)
, Cutler; David N.
(Nashua,
NH
)
Assignee:
Digital Equipment Corporation
(Maynard,
MA
)
Appl. No.:
137525
Filed:
April 4, 1980
Current U.S. Class:
711/100
Field of Search:
364/2MSFile
U.S. Patent Documents
3710324
January 1973
Cohen et al.
3893084
July 1975
Kotok et al.
3999163
December 1976
Levy et al.
4044334
August 1977
Bachman et al.
4104718
August 1978
Poublan et al.
4177510
December 1979
Appell et al.
4232366
November 1980
Levy et al.
4236206
November 1980
Strecker et al.
Other References
IBM System/370 Principles of Operation-GA22-7000-6 Seventh Edition, Mar. 1980-IBM Corp..~
Primary Examiner:
Springborn; Harvey E.
Attorney, Agent or Firm:
Cesari and McKenna
Claims
What we claim as new and desire to secure by Letters Patent of the United States is:
1. A communications device for connecting an external device, that transfers process data, and a data processing system that includes a memory including a plurality of addressable storage locations for storing privileged operating system programs including privileged addressing parameters, and a non-privileged user process composed of a user process program, a comman buffer for storing commands including addressing information and a data buffer for storing process data to be transferred to or from the external device, the memory locations assigned to the user process being identified by the privileged addressing parameters, said data processing system further comprising a central processor for processing the operating system and the user process programs, and communications device comprising:
A. interfacing means that connect to the memory and to the central processor for transferring information, including commands and process data, with the memory and the central processor,
B. command interpretation means connected to said interfacing means including
(i) means for storing privileged addressing parameters for the user process;
(ii) means for processing information from the memory corresponding to commands from the user process, and
(iii) means for translating the addressing information from the commands into translated physical addresses,
C. address generating means connected to said interfacing means and to said command interpretation means for receiving the translated physical addresses from said command interpretation means and for generating valid physical addresses of locations in the memory that correspond only to the physical addresses of the user process,
D. process data path means connected to said interfacing means and the external device for transferring process data between the interfacing means and the external device, and
E. memory reference means connected to said interfacing means, said address generating means, said command interpretation means and said process data path means for initiating transfer of information between a location in the memory identified by said address generating means and one of said address generating means, command interpretation means and process data means whereby user process commands and process data are transferred directly between the user process and the external device independently of the operating system programs.
2. A communications device as set forth in claim 1 in which the external device includes means for transferring commands including addressing information to said communications device, said communications device including means for receiving commands from the external device, and said command interpretation means further including means for processing the commands from the external device and means connected to said address generating means for translating the addressing information from the external device into translated physical addresses.
3. A communication device as set forth in claim 1 in which the communications device includes a control register that in one state enables said communications device to commence transferring commands, the central processor under control of the user process placing said control register in the one state.
4. A communications device as set forth in claim 1 in which said command interpretation means further includes means for enabling said interfacing means to retrieve unprocessed commands from the command buffer and returning processed commands to the command buffer.
5. A communications device as set forth in claim 4 in which the command buffer includes a first queue comprising commands that have not been processed and a second queue comprising commands that have been processed, each of the first and second queue including header means for identifying a command in the queue, said command interpretation means enabling means including means for altering the header means of said first queue when retrieving a command to identify the next command in the queue, and for altering the header means of said second queue when returning the processed command to the command buffer to identify the last command returned to the command buffer.
6. A communications device as set forth in claim 1 in which said command interpretation means further includes means for verifying that the translated physical addresses correspond to memory locations assigned to the user process.
7. A communications device as set forth in claim 1 in which said address generating means includes a buffer means for storing translated physical addresses from said command interpretation means, and counter means for retrieving the translated physical address from said buffer means and generating a series of physical addresses from the translated physical address, said command interpretation means being responsive to the translated physical address from said buffer means for translating a new translated physical address for storage in said buffer means.
8. A communications device as defined in claim 1 wherein said memory reference means further includes a first counter means for counting the number of bytes of process data transferred between the user process and said communications device and a second counter means for counting the number of bytes of process data transferred between the external device and said communications device, each command including a value defining the number of bytes to be transferred between the user process and the external device, and said command interpretation means including means for storing the value in both said first and second byte counter means prior to a transfer of process data.
Description
TABLE OF CONTENTS
Cross References to Related Patents and Patent Applications
Background of the Invention
Summary
Brief Description of the Drawings
Description of an Illustrative Embodiment
A. General Discussion
1. Data Processing System
2. Communications Device
3. Operation of Communications Device
4. Application of Communications Device
a. Generalized External Device
b. Interconnected Data Processing System
B. Specific Description
1. Data Paths
2. Basic Operations
3. Data Processing System Transfers
4. Command Interpreter and Control Interconnect
5. Address Generation
6. Process Data Path
7. Memory Reference Controller and Address Generator
C. Operation
CROSS REFERENCE TO RELATED PATENTS AND PATENT APPLICATIONS
U.S. Pat. No. 3,710,324 issued Jan. 9, 1973 for a DATA PROCESSING SYSTEM and assigned to the same assignee as the present invention.
U.S. Pat. No. 3,999,163 issued Dec. 21, 1976 for a SECONDARY STORAGE FACILITY FOR DATA PROCESSING SYSTEM and assigned to the same assignee as the present invention.
U.S. patent application Ser. No. 954,453 filed Oct. 25, 1978 for a CENTRAL PROCESSOR UNIT FOR EXECUTING INSTRUCTIONS OF VARIABLE LENGTH and assigned to the same assignee as the present invention, which is now U.S. Pat. No. 4,236,206.
U.S. patent application Ser. No. 954,601 filed Oct. 25, 1978 for a BUS FOR A DATA PROCESSING SYSTEM WITH OVERLAPPED SEQUENCES and assigned to the same assignee as the present invention, which is now U.S. Pat. No. 4,232,366.
BACKGROUND OF THE INVENTION
This invention generally relates to digital data processing systems and, more specifically, to the communication of data between a digital data processing system and an external device connected to that system.
Conventionally, a data processing system includes a plurality of interconnected data elements, usually comprising a central processor, memory, secondary storage devices, and input-output devices, plus programs for controlling the operation and interaction of these data elements. A VAX11/780 data processing system that is manufactured and sold by Digital Equipment Corporation, the assignee of this invention, is one specific embodiment of a data processing system in which the central processor, memory, secondary storage devices and input-output devices connect in parallel on an internal bus. This system is described in U.S. patent application Ser. Nos. 954,453 and 954,601 and in several publications, including publications titled: VAX11/780
Architecture Handbook (1977), VAX11/780 Hardware Handbook (1978), and VAX11/780 Software Handbook (1977), all published by Digital Equipment Corporation.
In this data processing system, as in many others, certain programs control the operation and interaction of the data elements and they constitute an operating system. More specifically, the operating system is an integrated collection of service routines, or programs, for supervising the sequencing of programs by the data processing system. These programs perform various debugging, input-output, accounting, compilation, and storage-assignment tasks, and process scheduling. Of particular interest with this patent application are the functions that are known as "input-output driver", or "I/O driver", routines. An I/O driver routine is a routine that initiates, in a data element such as an input-output driver, requests for transferring data referenced in a program to or from that input-output data element in response to input-output requests. As input-output requests are generated, they are placed in a queue and are subsequently processed according to the relative priority of the user program that issues them. The requests are issued to channels which have been previously associated with particular data elements. In addition, I/O driver routines process errors and interruptions. Each secondary storage device and each input-output device will have an I/O driver routine that pertains to that particular device.
Other programs are called "application" or "user" programs. They operate on "process data" to solve specific problems. They also interact with the operating system to transfer information among the data elements. In the following discussion, the process data is maintained in a "process data buffer". The phrase "user process" then encompasses the area in memory that contains the user program and the process data buffer.
The VAX11/780 data processing system, and other systems, are typically characterized by diverse types of external devices that are connected to an interconnecting bus in addition to the memory and central processor. One is an input-output adapter that couples the interconnecting bus to a plurality of input-output devices such as teletypewriters, etc. A secondary storage bus adapter couples the bus to various secondary storage devices that typically include disk and tape drive units. In the VAX11/780 data processing systems, these adapters enable transfers of data between a particular device and the memory at an effective rate that is less than the maximum potential data transfer rate. More specifically, in the VAX11/780 the maximum potential data transfer rate is 13.3 megabytes per second. Various restrictions imposed by the data elements reduce this rate. Thus the potential effective data transfer rate that might be reached during transfer between the device and the memory is
1.5 megabytes per second. Interrupt latency and other delays required for the operating system to initiate a request reduce the actual effective rate even more.
Two related problems contribute to the difference between the maximum potential data transfer rate and the low actual effective transfer rate: namely, (1) requirements for physical addresses to be calculated by address calculation routines in the operating system and (2) limitations in the adapter's capability to form addresses. For example, in the VAX11/780 data processing system, the data elements operate with virtual addresses. For example, a data element might have a capability generating
18-bit virtual addresses in a system that requires a 30-bit address to specify a physical memory location address. A physical address must therefore be calculated before a device can transfer any data, and an address calculation routine in the operating system is required to perform the calculation.
These calculations are further complicated by the segmentation of virtual memory into contiguous virtual memory pages. While successive virtual memory pages are contiguous, there is no guarantee that the corresponding page locations in physical memory will be contiguous. Therefore it is necessary to recompute the physical address of the beginning of a page each time a page boundary is crossed. Each such calculation involves a number of operations other than merely calculating the physical address. For example, it is necessary to assure that a virtual address in a user process corresponds to a location that is assigned to that user process.
Other processing must be interrupted so that the address calculation routine can be processed. This requires processor time and may require a significant amount of bus time, especially if the address calculation routine does not reside permanently in the random access memory and has to be transferred from a secondary storage device. As will be apparent, the repeated use of the operating system for overhead functions, such as address calculations, can reduce the overall rate of data transfers that may be attained by a user to a rate that is less than element the rate at which the data can transfer.
The driver routines for such data elements also reduce the effective data transfer rate. They include various messages that must be sent before a data transfer can occur. For example, the driver routine for a secondary storage device must transfer starting addresses, byte counts, commands for reading or writing, track and sector addresses, and other information before the data transfer can commence. Each of these information transfers may require one or more bus cycles that preclude the transfer of the user's process data.
Under such situations data may be lost or the user must reduce the rate at which the data is generated. Such losses or reductions can become unacceptable in many applications. For example, there are a number of scientific applications for data processing systems in which sensors for an experiment generate information at very high rates and in which the loss of data or a reduction in data would reduce the accuracy of the results of the experiment.
SUMMARY
Therefore, it is an object of this invention to facilitate the transfer of information between an external device and memory in a data processing system.
Another object of this invention is to provide a greater effective rate of data transfer between an external device and memory in a data processing system.
Still another object of this invention is to provide for direct communications between a user process that is resident in a data processing system memory and an external device.
Yet another object of this invention is to provide greater access for an external device to a memory in a data processing system.
Still yet another object of this invention is to provide a user process with far more capability to effect data transfers.
These objects are attained by utilizing a data element, called a communications device, to connect an external device to the interconnecting bus of the data processing system that also connects to the central processor and to the memory. The operating system transfers to the communications device, information that allows the determination of physical addresses of those memory locations that contain a user process by the communications device. This allows the communications device to generate physical addresses of locations in the memory that correspond only to the physical addresses of the user process without further utilization of the operating system. Information from the user process, including process data, moves between the user process and the external device through a memory reference controller. The memory reference controller routes the information accordingly to transfer information between the external device and either the user process program or the process data buffer. Direct transfers of data between the external device and the data processing system memory are made independently of operating system routines.
This invention is pointed out with particularity in the appended claims. The above and further objects and advantages of this invention may be better understood by referring to the following description taken in conjunction with the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a basic block diagram of a data processing system that is adapted to transfer data between an external device and memory in accordance with this invention;
FIG. 2 depicts various functions in the interconnection of the communications device between a data processing system and an external device;
FIG. 3 is a more detailed block diagram of a user process that is shown in FIG. 2;
FIG. 4 is a chart that depicts the general sequence that occurs among the user process, communications device, and external device in accordance with this invention;
FIG. 5 is a block diagram that depicts communications devices constructed in accordance with this invention that interconnect two data processing systems;
FIG. 6 depicts the relative positions of FIGS. 6A through 6R that provide a functional description of the various transfers that may occur between the communications devices shown in FIG. 5 and their respective data processing systems;
FIGS. 7A through 7D depict the organization of four different command packets that are useful in understanding the description in FIG. 6;
FIG. 8 is a block diagram of a specific embodiment of a communications device constructed in accordance with this invention;
FIG. 9 is a block diagram of the interface 40 shown in FIG. 8;
FIG. 10 sets forth the organization of FIGS. 10A through 10E, FIGS. 10A through 10E constituting a logic diagram of circuitry shown in FIG. 9;
FIGS. 11A through 11H constitute a timing chart of reference timing signals that are utilized in the circuitry shown in FIG. 9 and subsequent figures;
FIG. 12 depicts the oganization of certain registers that are found in FIG. 8;
FIG. 13 depicts certain registers that are found in the local store shown in FIG. 8;
FIGS. 14A and 14B constitute a detailed block diagram of the command interpreter shown in FIG. 8;
FIG. 15 comprises a logic diagram of a portion of the control block shown in FIG. 14A;
FIG. 16 comprises a logic diagram of other portions of the circuitry shown in FIG. 14A;
FIG. 17 comprises a logic diagram of branch decoding logic shown in FIG. 14A;
FIG. 18 comprises a logic diagram of control interconnection circuitry shown in FIG. 14B;
FIG. 19 comprises a detailed block diagram of the process data path shown in FIG. 8;
FIG. 20 comprises a logic diagram of data interconnection circuitry shown in FIG. 19;
FIGS. 21A through 21D comprise a logic diagram of circuitry in the silo control shown in FIG. 19;
FIGS. 22A and 22B are truth tables that is useful in understanding the operation of the circuitry shown in FIG. 21C;
FIGS. 23A and 23B comprise a logic diagram of circuitry in the data interconnection control shown in FIG. 19;
FIGS. 24A and 24B are truth tables that is useful in understanding the operation of the circuitry shown in FIG. 23B;
FIG. 25 comprises a detailed block diagram of the timing control circuitry that is shown in FIG. 19;
FIGS. 26A and 26B constitute a detailed block diagram of the memory reference controller and address generator shown in FIG. 8;
FIGS. 27A through 27F comprise a logic diagram of circuitry in the control sequencer shown in FIG. 26B;
FIGS. 28A and 28B truth tables that is useful in understanding the operation of the circuitry shown in FIG. 27B;
FIGS. 29A and 29B shows another truth table that is useful in understanding the operation of the circuitry shown in FIG. 27B;
FIGS. 30A and 30B are truth tables that is useful in understanding the operation of the circuitry shown in FIG. 27C;
FIGS. 31A through 31D comprise a logic diagram of circuitry in the control sequencer shown in FIG. 26B;
FIGS. 32A and 32B constitute a detailed logic diagram of circuitry shown in FIG. 26A;
FIG. 33 constitutes a detailed logic diagram of other circuitry shown in FIG. 26A;
FIGS. 34A-34D shows a flow diagram that is useful in understanding certain phases of the operation of the circuitry shown in FIG. 8;
FIGS. 35A and 35B shows a flow diagram that is useful in understanding other phases of the operation of the circuitry shown in FIG. 8;
FIG. 36 is a flow diagram that is useful in understanding still other phases of the operation of the circuitry shown in FIG. 8; and
FIGS. 37A through 37D constitute a detailed flow diagram that is useful in understanding certain of the operations in FIG. 34.
DESCRIPTION OF AN ILLUSTRATIVE EMBODIMENT
A. General Discussion
1. Data Processing System
Referring to FIG. 1, a data processing system to which this invention applies comprises, as basic elements, a central processor 10, memory 11 and I/O units. A synchronous backplane interconnection (SBI) 14 interconnects the central processor 10, memory 11 and I/O units in parallel.
The central processor 10 comprises an operator's console 15, an SBI interface and memory cache circuit 16, an address translation buffer circuit 17, an instruction buffer circuit 18 and a data path and internal register circuit 19. The SBI interface and memory cache circuit 16 provide the necessary interfacing circuitry for transferring information over the SBI 14 to the memory 11 and I/O units. The circuit 16 receives all data from the memory and all address translations from the buffer circuit 17. It includes an associative memory, or cache. Any time data is written into the cache memory in the circuit 16 from the data path and internal register circuit 19, that data is also written into a corresponding location in the memory 11.
This specific embodiment of the central processor 10 operates with virtual addresses. The address translation buffer circuit 17 converts the virtual addresses to physical addresses which the memory cache circuit 16 uses either to determine whether it contains data from the corresponding location or to initiate a transfer from the corresponding actual location in the memory 11. The instruction buffer circuit 18 includes, as described later, means for storing instructions, or portions thereof, as they are retrieved either from the cache memory directly or from the memory 11.
The operator's console 15 serves as the operator interface. It allows the operator to examine and deposit data, halt the operation of the central processor 10 or step it through a sequence of program instructions. It also enables an operator to initialize the system through a bootstrap procedure and perform various diagnostic procedures on the entire data processing system.
In FIG. 1, the illustrated memory 11 comprises two memory controllers 20A and 20B. Each memory controller connects to a plurality of memory arrays. Specifically, memory controller 20A connects to memory arrays 21A while memory controller 20B connects to memory arrays 21B.
Several types of I/O units are shown. An I/O bus adapter 22 interconnects various input/output (I/O) devices 23, such as teletypewriters, to the bus 14. The interconnection, operation and transfer of signals between the I/O bus adapter 22 and the I/O devices 23 is disclosed in U.S. Pat. No. 3,710,324.
Another one of the I/O units comprises a secondary storage facility for the data processing system. It includes a secondary storage bus adapter 24 and a plurality of disk drives 25. The interconnection of the secondary storage bus adapters 24
and its respective disk drives 25 is disclosed in the foregoing U.S. Pat. No. 3,999,163.
U.S. patent application Ser. No. 954,601 describes the interactions of these data elements over the SBI 14. For purposes of the following discussion, it will be helpful to summarize these interactions and to define specific terms including the definition of data items, or groups, which this specific embodiment of the invention can process. The basic, or most elementary, information group is a byte. A byte includes eight bits in this data processing system. A word comprises two bytes. A "longword" comprises two consecutive words or four consecutive bytes while a "quadword" comprises two consecutive longwords, i.e., four consecutive words or eight consecutive bytes. Any transfer of information over the SBI 14 involves a longword.
The SBI 14 is time-division multiplexed and includes signal paths for carrying information and control signals. Each unit that connects to the SBI is called a nexus. The specific system shown in FIG. 1 includes six nexuses. A nexus is defined further in terms of its function during an exchange of information. At least two SBI transactions are necessary to exchange information between two nexuses. During a first transaction, one nexus, as a transmitting commander nexus, transmits command and address information to all the nexuses. This nexus is called a transmitting nexus because it is driving the SBI 14 and a commander nexus because it has transmitted the command and address information. During this transaction all nexuses, including the transmitting nexus, are receiving nexuses. However, only one receiving nexus will respond to the address information. That nexus is a responder nexus and it transmits a confirmation of receipt of the command and address information at a fixed interval after the commander nexus transmits that information. Thus, should the central processor 10 need to retrieve data from the memory controller 20A, the central processor 10 becomes a commander nexus and transmits a read command and an address to which the memory controller 20A will react initially as a receiving nexus and then as a responder nexus.
After some interval, the memory controller 20A will be prepared to send the retrieved data to the central processor 10. As described in U.S. patent application Ser. Nos. 954,453 and 954,601, it seeks control of the SBI 14. When it gains control, the memory controller 20A becomes a transmitting responder nexus and transfers the requested data onto the SBI 14 for transfer to the central processor 10. During this transaction, the central processor 10 is a receiving commander nexus.
Similar transactions occur for any information exchange between any two nexuses, although the memory controllers normally function only as responder nexuses and the central processor unit normally functions only as a commander nexus.
2. Communications Device 26
In accordance with this invention, one nexus that connects to the SBI 14 is a communications device that also connects to an external device 27. The external device may comprise any number of different data elements. In one application, the external device 27 will comprise an array processor or special laboratory test equipment. In still another application, the external device 27 will comprise another data processing system as shown in FIG. 1 with the connection to the communications device 26 being through another communications device of like construction. Such an interconnection provides a multiple processor data processing system.
FIG. 2 depicts, in functional form, the communications device 26 of this invention and its interconnection to the external device 27 and to specific data elements in the data processing system: namely, the central processor 10 and the memory 11. Two blocks are shown in the memory 11. An operating system depicted as block 30 comprises an I/O driver 31 for a secondary storage bus adapter 24 shown in FIG. 1 and an I/O driver 32 for the communications device 26. The memory 11 contains another block 33 that represents a user process that includes a user process program 34 and a process data buffer 35. Although the representation in FIG. 2 depicts the operating system 30 and the user process 33 as each being stored in a separate, unitary block of contiguous memory locations, it will be apparent that no such restriction is necessary and normally does not occur. Each can be stored on a plurality of noncontiguous blocks of storage locations, and each block contains an equal number of physical storage locations.
The I/O driver 32 for the communications device comprises instructions and data that represent pointers to page tables in "privileged" memory areas and lengths of pages reflecting the size of a memory area for a user process. A "privileged" memory area is one that is not normally available to user process programs or data elements; its access is normally limited to the central processor when it is processing the operating system, or even specific routines in the operating system, that are known to be correct. In accordance with one aspect of this invention, however, the central processor 10 processes the I/O driver 32 to transfer such privileged information to the communications device 26.
During use, the central processor 10 processes instructions from the user process program. This program may include instructions that call various routines in the operating system. For example, if information is required from a disk, an instruction in the user process program calls the I/O driver 34 and thereafter that driver initiates a transfer of information from locations defined by the programmer in the process data buffer to the secondary storage bus adapter. Likewise, the central processor 10 would process another instruction in the user process program to call the I/O driver 32 thereby to transfer information to the communications device 26.
The communications device 26 and the external device 27 operate in response to "commands" that are received either from user process 33 or even from the external device 27 when it is capable of transmitting such commands. These "commands" are contained in "packets" of information. Normally the user process program command will contain such "command packets" in the form of literals. The communications device 26 processes the information in a command packet after it transfers the information from the user process program 34 in the memory 11. The communications device 26 responds to certain commands by initiating transfers of process data between the process data buffer 35 and the external device 27 through the communications device 26. Both transfers of commands and process data occur directly between the memory 11 and the communications device 26, so it is not necessary for the user process program to call any routines in the operating system 30 to effect those transfers.
Now referring to the communications device 26 in more detail, an interface 40 connects to the memory 11 and to the central processor 10 by means of the SBI 14. The interface sends information to and receives information from both the central processor 10 and the memory 11, and this information may be interpreted as addresses, commands or process data. An address generator 41 also connects to the interface 40. It includs an input address circuit 42 that generates a virtual input address and a privileged control parameters circuit 43 that receives various information for converting the virtual input addresses into physical addresses. These privileged control parameters are transferred to the address generator 41 by the I/O driver 32 for the communications device 26, usually from a privileged portion of the operating system. An address converter 44 utilizes the information from the input address circuit 42 and the privileged control parameter circuit 43 for generating a physical address. Part of the information transferred to the privileged control parameters circuit 43 prevents the address converter 44 from producing physical addresses of locations that are not properly associated with the user process.
A command interpreter 45 that processes commands connects to the interfacing means and to the external device 27 through a control interconnection 46. The command interpreter 45 can transfer information to the external device 27 to effect its operation through the control interconnection 46. The external device 27 may also be capable of sending commands through the control interconnection 46 to the command interpreter 45. Thus, either the user process or the external device 27 may control the operation of the communications device 26.
A process data path 47, including a buffer 50, connects to the interface 40 and through a data interconnection 51 to the external device 27. The process data path 47 transfers process data between the process data buffer 35 and the external device 27 during a process data transfer.
A memory reference controller 52 connects to the interface 40, the address generator 41, the command interpreter 45, and the process data path 47. The controller 52 routes information received from the user process to the appropriate ones of the address generator 41, the command interpreter 45, and the process data path 47. Also the controller routes information from any of the address generator 41, command interpreter 45, and process data path 47 through the interface 40 to the user process
33.
3. Operation of Communications Device 26
Typically, a user process initiates the operation of the communications device 26 by calling the I/O driver 32. The I/O driver 32 establishes various initial conditions and transfers privileged control parameters to the circuit 43 in the address generator 41. Thereafter, the communications device 26 transfers command packets from the user process program 34 through the interface 40 to the command interpreter 45 independently of the operating system 30. Certain commands are interpreted by the command interpreter 45 to establish subsequent operations within the communications device 26. Other commands pass through the command interpreter 45 to establish subsequent operations within the external device 27.
Typically a command packet includes (1) links to addresses of previous and next command packets, (2) control information such as the size of the packet and a number of status words in the packet, (3) a command message, (4) the virtual address of the beginning of the process data buffer with which the first item of process data is to be transferred, (5) the number of bytes of process data to be transferred, (6) the residual number of data bytes to be transferred between the process data path 47
and the memory 11, and (7) locations for a number of status words that will reflect the operating status of the communications device 26 and the external device 27 after the command packet has been processed.
As each command packet is processed, the command interpreter 45 and memory reference controller 52 transfer the virtual address to the input address circuit 42 in the address generator 41. Thereafter, the address generator 41 utilizes the privileged control parameters in the circuit 43 to produce, independently of the operating system, a physical address of a location in the process data buffer 35. The command interpreter 45 also may respond to the control message to initiate a transfer and the transfer will thereafter occur between the external device 27 and the process data buffer 35. The interface 40 combines the data and the addressing information to produce the necessary sequence of signals to effect the transfer over the SBI 14. Thus, the communications device 26 becomes a commander nexus and fully controls the transfer. Moreover, the transfer of process data also occurs independently of the operating system 30. Thus, the I/O driver 32 only transfers the necessary addressing and other initializing information to the communications device 26. This reduction in the use of the operating system enables a higher rate of overall transfer of processed data to be effected between the external device 27 and the process data buffer
35. In the application to a VAX 11/780 data processing system, transfer rates should increase from 1.5 megabytes per second to about 6 megabytes per second.
4. Application of the Communications Device 26
A general description of a typical application for the communications device 26 will be helpful to an understanding of the detailed structure of the communications device 26 shown in FIGS. 1 and 2. This discussion includes a description of the preliminary operations that must occur in the system before the communications device 26 is utilized. Then the discussion turns to a typical interchange of information between a typical external device 27 and a memory 11. After this generalized exchange of information is discussed, a complete transfer or sequence of operations in which the external device 27 comprises a second data processing system will be discussed.
As previously stated, the data processing system depicted in FIG. 1 utilizes virtual addressing. Thus, any user of the system writes programs utilizing virtual addresses which the operating system normally converts to physical addresses. Processes for converting virtual addresses to physical addresses are well known in the art. If an operator wishes to utilize the communications device 26 and produce transfers between the user process 33 and the external device 27, the operator must define the user process base. FIG. 2 depicts two basic areas of the user process 33: namely, the user process program 34 and the process data buffer 35. The operator further divides the user process program 34 into various instructions for controlling the user process.
This further division is depicted in FIG. 3. The operator must define a command packet. A typical command packet 55 comprises a block of locations in the user process program 34 beginning at a predetermined virtual address. In this particular example, the address is designated symbolically as "CP(i)". Each command packet allows a predetermined direct communication to occur between the user process 33 and the external device 27. Operations in response to the command packet 55 begin when the user process 33 transfers the user's command packet to an input queue 56. This transfer is produced when the address CP(i) is transferred to a location at the "head" of an input queue 56, which comprises a block of memory locations in the user process program 34. As described more fully later, once the communications device 26 processes a command packet, it transfers the command packet back to the user process program 34 again by transferring its virtual address to a termination queue 57 in the user process program 34. Thus the operator must define a block of virtual addresses that will constitute the input queue 56 and a block of virtual addresses that will define the termination queue 57. The number of locations in each queue, as well as in a free queue 60, will depend upon the particular requirements on the user process program 34.
Each command packet 55 may initiate a control function or a data transfer function with the external device 27. When a command packet initiates a data transfer, there must be a corresponding process data buffer associated with that command packet in an area of the memory that has heretofor been identified as process data buffer 35 and is identified from here as a data block 35. In FIG. 3, a process data buffer 61 identified by symbolic address VA(i) corresponds to the command packet 55 at symbolic address CP(i). Other process data buffers 62, 63 and 64 are also shown as defining a group of process data buffers VA(i-1) through VA(i+2). Moreover, the user process program 34 would contain a command packet associated with each of the process data buffers 62, 63, and 64 in addition to the command packet 55.
Now referring to the command packet 55, which resides in a command block, each command packet in the user process program 34 comprises a forward link 65 that is a long word and that is at the initial location of that command packet. This forward link 65 enables the communications device 26 to ascertain the location of a next command packet in the input queue 56 and allows the user process program to ascertain the location of the next command packet in the termination queue 57. More specifically, the virtual address of a next command packet in sequence equals the sum of the virtual address for the forward link 65 plus the value stored in the forward link. Thus the value of the forward link is an offset number to the next command packet. The command packet also includes a longword that is a backward link 66 that is used in an analogous process to define the address of a predecessor command packet. As described more fully later, when the communications device 26 begins to process a command packet, it manipulates these links.
A control word 67, that also is a long word, comprises several fields. A PKT CTRL field contains two subfields. A first subfield defines three basic interruption states that control the conditions under which the communications device 26 will interrupt the user process program 34. In a first, or unconditional, state, an interrupt is enabled whenever the command packet is placed on the termination queue 57. In a second, or termination queue empty, state, an interruption will occur only when the command packet is inserted on the termination queue and the termination queue is empty. In a third, or no-interrupt, state, no interruption will occur when the command packet is placed on the termination queue. The second subfield comprises and SLE bit that is set to disable any error messages from being generated whenever a data transfer over the data interconnection 51 terminates before all the data bytes are transferred.
Still referring to FIGS. 2 and 3, the next two fields in the control word 67 are a CIS field and a COMMAND field. The CIS field controls the transfer of signals onto the control interconnection 46 that are used in conjunction with data transfers. In a first state of the CIS field no transmission of signals occurs over the control interconnection 46. In a second state, the command interpreter 45 is enabled to transfer the contents of the COMMAND field to a command register in the external device 27. This state is normally used when the COMMAND field will initiate a data transfer. A third state of the CIS field enables the command interpreter 45 to transmit the COMMAND field as in the previous code to the external device 27 and then to transmit a device message. This allows commands that require more than one byte of information to be transferred. In a fourth state of the CIS field the command interpreter 45 transmits the COMMAND field, a byte field, and a device message to the external device. This state is used when the external device 27 is a data processing system because the device message field will contain the virtual address of the buffer block in the data processing system memory that constitutes the external device 27.
The COMMAND field defines a number of specific commands that effect data transfers or other functions. A READ DEVICE command specifies that the communications device 26 will transfer data from the external device 27 to a designated process data buffer in the data block 35. A READ DEVICE CHAINED command performs a similar function except that the communications device 26 immediately transfers control to subsequent READ DEVICE and READ DEVICE CHAINED command packets that will perform a corresponding data transfer to another process data buffer automatically, assuming the subsequent command packet is in the input queue 56 shown in FIG. 3. If a series of READ DEVICE CHAINED commands are inserted in the input queue 56, the last command in sequence will be a READ DEVICE command.
There are three commands for transferring information to the external device 27. A WRITE DEVICE command and a WRITE DEVICE CHAINED command perform similar functions to the READ DEVICE and the READ DEVICE CHAINED commands except that data is transferred from a process data buffer in the data block 35 to the external device 27. A WRITE DEVICE CONTROL MESSAGE command causes the communications device 26 to transfer a control message from the command interpreter 45 over the control interconnection 46. The control message is contained in a device message field of the command packet that is described later.
A SET RANDOM ENABLE command and a CLEAR RANDOM ENABLE command control an internal random enable flag. There are three potential sources of commands. One source of commands is the user process program 34. The I/O driver 32 is a second source, but is limited to an ABORT command or a CLEAR HALT command. As previously indicated, the external device 27 may also transfer a command packet to the communications device 26. The SET and CLEAR RANDOM ENABLE commands control whether the communications device 26 will respond to commands from the external device 27.
A NO OP command is sent from the user process program 34 to the communications device 26 to produce a response, but no data transfer.
A SET HALT command halts further operation of the communications device 26.
Still referring to the command packet 55 in FIG. 3, a LOG LENGTH field in the control word 67 specifies a maximum number of status bytes that can be logged into the command packet in a log area 70. The status bytes represent the contents of predetermined registers in the external device 27 that are transferred over the control interconnection 46.
A DEVICE MESSAGE LENGTH field in the control word 67 defines the number of bytes in a device message field 71. This field 71 contains information that is to be transferred to storage and control registers in the external device 27. One such message, for example, will contain the address of a data buffer in the external device.
After the control word 67, the command packet 55 contains a byte count longword 72. This longword indicates the number of bytes that are to be transferred to or from the corresponding process data buffer.
A next location in the command packet 73 contains a data buffer virtual address. In the case of the specific command packet 55, for example, the storage location 73 will contain a virtual address corresponding to the symbolic address VA(i). Two residual byte counts are stored as sequential in locations 74 and 75. A memory residual byte count in location 74 indicates the number of data bytes that are yet to be transferred between a process data buffer in the data block 35 and the buffer 50 in the process data path 46. An external device residual byte count in location 75 indicates the number of data bytes that remain to be transferred between the external device 27 and the buffer 50. Residual byte count information is only stored in locations 74 and 75 for READ DEVICE, READ DEVICE CHAINED, WRITE DEVICE, and WRITE DEVICE CHAINED commands and certain diagnostic commands. The residual byte count fields in command packets received from the user process are zero. These fields are loaded by the communications device following a transfer. If, following a transfer, the residual byte count fields are not both zero, a length error has occurred.
A device status longword 76 is stored in the command packet following the external device residual byte count longword 75. The device status longword 76 contains the status of the communications device 26 after the communications device processes a command packet. Specific items concerning status will be described later. For purposes of description, however, the least significant bit position in the status longword 76 is a success bit that indicates the successful processing of a command packet without error. If an error were to occur, other bit positions in the device status word 76 identify that error.
a. Generalized External Device
With this understanding of the organization of the operating system 30, the user process 33, and the functional organization of a communications device 26 at the level shown in FIGS. 2 and 3, it will now be helpful to describe a representative sequence of interactions between and operations performed by each of the operating system 30, the user process program 34, and the communications device 26. This sequence is outlined in FIG. 4. During the discussion, however, reference will be made to elements that are depicted in FIGS. 2 and 3.
The first action in any sequence normally will occur with the formation of a command packet 55 in step 80. The command packet 55 can be formed two ways. First, instructions in the user process program 34 can transfer literals into successive locations thereby to construct the command packet 55. Alternatively, the programmer might actually form the command packet within the user process 34.
Operations in response to the command packet 55 are initiated by another instruction in the user process program 34 that transfers the virtual address of the forward link 65 (i.e., the symbolic virtual address CP(i)) to the head of the input queue 56 (step 81). In step 82, the user process program 34 executes an instruction that transfers signals over the bus 14 through the interface 40 to the memory reference controller 52 shown in FIG. 2. This message is in the form of a command and sets one bit position, designated as a GO bit position, to initiate operations.
When the GO bit is set, control passes to the communications device 26. Specifically, the memory reference controller 52 retrieves the appropriate portions of the command packet 34 directly from it in the user process program 34 (step 83). The command interpreter 45 processes the control word 67 (step 84) and transfers the COMMAND field to the external device 27 if that is appropriate (step 85). As previously indicated, transfers to the external device are controlled in response to the CIS field in the control word 67. If such a transfer is appropriate, the external device receives the portions (step 86) and initiates an operation in response to that command (step 87).
If the COMMAND field of the control word 67 defines a data transfer operation, the data transfer operation begins as shown by steps 90A and 90B. More specifically, step 90A represents the transfer between the external device 27 and the buffer 50
in the process data path 47; step 90B represents the transfer between the buffer 50 and the process data buffer in the data block 35 in the user process 33. With respect to FIG. 3, if the command packet 55 is being processed, the process data buffer 61
is utilized in the transfer.
After the transfer is completed, the communications device 26 determines the status of response to the command and stores that status in the status word location 76 of the command packet (step 91). Then the memory reference controller 52
transfers the address of the command packet to the end, or "tail", of the termination queue 57 in the user process (step 92). In step 93, the communications device interrupts the user process 33.
Interruptions to the user process program 34 are made directly through the operating system 30. Step 94 represents the I/O driver response to the interruption that initiates a response in the user process program 34 in step 95. The effect, however, is that the user process is interrupted and performs an interruption service routine. The transaction is completed when the user process removes the command packet from the termination queue and processes the status longword 76.
The previous description of the control word 67 in FIG. 3 discusses several data transfer commands including commands that produce "chained" and "unchained" data transfers. Moreover, the communications device 26 also can perform "command chained" operations. Command chaining comprises the transfer of the initial addresses of a succession of command packets, such as command packet 55 in FIG. 3, to the input queue 56. The communications device 26 then processes these successive command packets in sequence without further interference from the operating system 30 or the user process program 34. Data chaining operations require command chaining operations. Data chaining operations allow successive data transfers to successive data buffers, again without further use of the operating system.
All these operations including variations on the basic sequence shown in FIG. 4 can be explained by considering transfers during a typical data processing system. The best example can be presented when the external device 27 is another data processing system as shown in FIG. 5.
b. Interconnected Data Processing Systems
FIG. 5 depicts two data processing systems: data processing system 100A to the left of FIG. 5, and data processing system 100B to the right of FIG. 5. Each element in FIG. 5 utilizes a reference numeral that designates a corresponding element in FIG. 2, with the addition of a letter suffix "A" to designate elements that are associated with the data processing system 100A and distinguish them from elements in the data processing system 100B. For example, the two central processors are designated with reference numerals 10A and 10B respectively. Moreover, the data processing system 100B including its communications interface 26B constitutes an external device 27A for the data processing system 100A including the communications device 26A. Similarly, the data processing system 100A including its communications device 26A constitutes an external device 27B for the data processing system 100B and the communications device 26B.
FIG. 5 also includes a data source 101 that connects to the SBI 14A. This may comprise an inputoutput device or a secondary storage facility or, depending upon the expected data transfer rates, even another communications device and its associated external device. For purposes of this explanation, it is assumed that the data processing system 100A retrieves data from the data source 100 and assembles this data into a form which permits its efficient processing. In such an application, the data processing system 100B then could be adapted to perform a few, specific functions. For example, the data processing system 100B might include a Fortran compiler for processing data.
In such an application, the user process program 34A includes instructions for transferring the assembled data from a process data buffer in the data block 35A through the communications devices 26A and 26B to a process data buffer in the data block 35B associated with the requested program to be processed by the data processing system 100B. Moreover it is assumed, for purposes of this description, that a user process program 34B in the data processing system 100B includes instructions for transferring additional data back to the data block 35A and for indicating to the data processing system 100A that the processed data has been returned successfully. This enables other portions of the user process program 34A to utilize the processed data.
The transfers of control among the operating system, the user processes, and the communications devices is depicted in FIGS. 6A through 6R.
FIGS. 6A through 6R have a positional relationship as shown in FIG. 6. FIG. 6A and other vertically aligned figures (FIGS. 6C, 6E, . . . ) depict operations in the data processing system 100A while FIG. 6B and other vertically aligned figures (FIGS. 6D, 6F, . . . ) depict operations that occur within the data processing system 100B. The operations occur in a time sequence vertically as shown. Initially it is assumed that the communications device 26A in inactive while the communications device 26B is active. It is also assumed that the central processor 10B is not processing either the operating system 30B or the user process program 34B.
Referring to steps 101 through 104 in FIG. 6A, the user process 33A initiates operations through the communications device 26A. In step 101 the central processor 10A begins to process instructions in the user process program 34A and assemble data in the process data buffer 35A. The appropriate time to transfer the data to the process data buffer 35B for processing in the data processing system 100B is established in step 102. In step 103, the user process 33A establishes the virtual addresses of command packets and of process data buffers that correspond to those command packets. Once this preparatory information has been assembled, the user process 33A, in step 104, calls the I/O driver routine 32A for the communications device
26A.
The operating system 30A responds to this call by processing instructions outlined in steps 105 through 110. Many of these steps may have been performed earlier. In step 105, the operating system 30A transfers all necessary pages in the user process 33 to the memory 11A. The user process 33, or various portions of the user process 33, normally reside in a secondary storage facility such as a disk drive 25 (FIG. 1). The operating system 30A normally retrieves only those pages on which it is presently operating or expects to operate. Prior to a data transfer through the communications device, however, all process data buffers and command packets, such as those shown in FIG. 3, must be available in the random access memory 11 (FIG. 1). A number of conventional procedures are available for assuring that these portions of the user process are accessible in the memory 11.
Each user process program 34 includes a predetermined number of virtual memory addresses. In effect, each user process will have associated with it a particular virtual machine that can be defined in terms of its memory size. In step 106, the operating system 30A determines whether the virtual addresses that will be defined by the user process correspond to valid addresses for that user process. In one embodiment, the user process program 34 contains starting virtual addresses and literals corresponding to the length of the virtual memory. The operating system 30 utilizes this information to ascertain that all the virtual addresses lie within the virtual memory address space assigned to the particular user process 33.
Next, the operating system 30A transfers several items of control information to the privileged control parameter circuit 43A. This information includes starting virtual addresses and lengths for each of the data blocks and command blocks, a system virtual address, mapping constants, and other information. In addition, the operating system 30A normally ascertains whether each page in the data block is capable of performing reading or writing operations. When step 107 has been completed, the address generator 41A has the capability of transmitting physical addresses directly onto the SBI 14A through the interface 40A in response to the information that the operating system 30A has transferred to it in step 107. Thus, the addresses can be generated without further use of the operating system.
When these, and other optional, operations have been completed, the operating system 30A terminates its operation by transferring a CLEAR HALT command to the communications device 26A in step 110. The communications device 26A responds to the CLEAR HALT command by becoming active. Specifically, the communications device 26A enters a RUN LOOP operation and scans for "events", an "event" representing a transfer of a command packet to the communications device 26A either from the user process
33A or from the user process 33B through the communications device 26B. In addition, the operating system 30A transfers control back to the user process 33A and in step 112 the user process 33A begins a series of operations that will produce interactions with the communications device 26A.
Specifically, in step 112 the user process 33A determines the status of the communications device 26A by forming a NO OP command packet that is shown in FIG. 7. As previously indicated, the NO OP command packet produces no response between the communications device 26A and the external device 27A, in this case the communications device 26B. However, it does cause the communications device 26A to return a device status longword to the user process 33A. The contents of the forward and backward links are described generally later. The byte count is ignored by the communications device when the command is NO OP. The data buffer virtual address and residual byte count words have no meaning. The status longword is initially cleared. The control word fields are all cleared except for the command field, which has a hexadecimal value of eight [i.e., 8(16)] the value of the command field of a NO OP command packet. Once the user process 33A forms this NO OP command packet, it transfers a pointer to the NO OP command packet to the head of the input queue 56A in the user process program 34A. Then the user process 33A executes an instruction which transmits a message to a control register in the communications device 26A which sets a GO bit. The user process 33A enters a WAIT state in step 113 during which no further action occurs within the user process 33A.
As previously indicated, the communications device 26A was placed in the RUN LOOP operating sequence in response to the CLEAR HALT command. It therefore tests for an ABORT command from the operating system 30A, incoming commands from the external device 27A, specifically the communications device 26B, and incoming commands from the user process 33A that set the GO bit. In step 114 of FIG. 6C, the communications device 26A senses that the user process 33A has set the GO bit; and then tests to determine whether a command packet has been received. Specifically, in step 115 the communications device 26A obtains the pointer to the NO OP command packet from the head of the input queue 56A and converts this pointer into a physical address thereby to transfer appropriate portions of the NO OP command packet into the communications device 26A. The command interpreter 45A responds to the NO OP command by testing the status of the external device 27A (i.e., the data processing system 100B) and forms a status longword for the NO OP command packet. If, as assumed, the communications device 26B is in the RUN LOOP operating mode, a signal on the control interconnection 46 indicates that the communications device 26B is operating. The communications device 26A forms a status longword in the command packet and, in step 117, inserts a pointer to the command packet on the termination queue 57A in the user process program 34A.
In step 120, the communications device 26A interrupts operations on the SBI 14A. The interruption occurs because the INTERRUPT CONTROL subfield in the control word establishes an unconditional interruption state that automatically generates an interruption each time a pointer to the command packet is placed on the termination queue 57A. After the interruption is requested, the communications device 26A reenters the RUN LOOP operating sequence in step 121 to await some subsequent event.
The operating system 30A initially processes the interruption (step 122) and transfers certain information concerning the interruption back to the user process 33A. In step 123 the user process 33A begins to process the user program at a predetermined location. The use of the operating system 30A to respond to an external interruption and then to vector operations to a particular position in a user program is well known.
When the user process 33A responds to the interruption, it retrieves the pointer to the NO OP command packet that is contained in the termination queue 57A to remove the NO OP command packet from the termination queue 57A (step 124). It then tests the status longword in step 125 to determine whether the operations in response to the NO OP command were successful.
Assuming a successful operation, the user process 34A then prepares to initiate a data transfer to the user process 33B. First, the user process 33A informs the user process 33B of the type of transfer it will perform, the virtual address of the base of user process 33A's buffer with respect to which the transfer will occur, and the number of bytes to be transferred. Specifically, in step 126 the user process 33A forms a WRITE DEVICE CONTROL MESSAGE command packet. FIG. 7B depicts a typical WRITE DEVICE CONTROL MESSAGE command packet. The packet control subfield establishes the unconditional interruption state and a state for suppressing length errors. The CIS field is ignored for this command. The COMMAND field has a value of of "04" corresponding to a WRITE DEVICE CONTROL MESSAGE command. The control word also specifies the length of the DEVICE MESSAGE, which is here assumed to be "k". The BYTE COUNT, VIRTUAL ADDRESS, and the two RESIDUAL BYTE COUNT fields have no meaning and the status longword is cleared. The DEVICE MESSAGE follows and contains "k" bytes represented by the "k" in the MESSAGE LENGTH field of the control word. The information in the DEVICE MESSAGE indicates to the data processing system 100B that the process data buffer 62A contains data to be processed in accordance with a particular function that is within the capability of data processing system 100B. Specifically, the DEVICE MESSAGE identifies the type of transfer that user process 33A will perform, with process 33B, the virtual address of user process 33A's buffer, and the number of bytes to be transferred, in consecutive longword fields.
Now referring to FIG. 6E, the user process 33A transfers the pointer of the command packet shown in FIG. 7B to the input queue 56A program 34A in step 127. In step 130 the user process 33A sets the GO bit in the communications device 26A thereby to transfer control to the communications device 26A.
In step 131, the communications device 26A leaves the RUN LOOP operating sequence established in step 121 and transfers appropriate portions of the WRITE CONTROL MESSAGE command packet directly from the command block of the user process program
34A so that the command can be decoded in the command interpreter 45A. Specifically, these portions include the COMMAND field, the MESSAGE LENGTH field, and the DEVICE MESSAGE field. The command interpreter 45A transfers this information across the control interconnection 46 to be received by the command interpreter 45B as an external command.
While the operating system 30A, the user process 33A, and the communications device 26A are operating as shown through step 130 in FIGS. 6A, 6C, and 6E, the communications device 26B is in the RUN LOOP operating sequence as shown in FIGS. 6B, 6D, and 6F. These last three figures also depict an apparent inactivity by the user process 33B and operating system 30B. There is no activity with respect to the external device 27B, namely the data processing system 100A and communications device 26A. However, it is possible for both the user proces 34B and operating system to be active in connection with other tasks. Thus, the data processing system 100B, as well as the data processing system 100A, may operate in a multi-processing mode in appropriate circumstances and applications.
The communications device 26B is in a RUN LOOP operating sequence and it accepts the transferred portions of the WRITE DEVICE CONTROL MESSAGE command packet in step 133 of FIG. 6F. Now both communications devices 26A and 26B perform different and independent operations simultaneously and require the utilization of their respective operating systems and user programs as shown in FIGS. 6E through 6H.
Referring specifically to FIG. 6E, the communications device 26A reads the status from the communications device 26B over the control interconnection 46 (step 134) and forms a device status longword for the WRITE DEVICE CONTROL MESSAGE command packet (step 135). In step 136 the communications device 26A transfers a pointer to the command packet onto the termination queue 57A. The communications device 26A also interrupts the data processing system 100A, as previously described with respect to the NO OP command packet, in step 137 and returns to the RUN LOOP operating sequence.
The operating system 30A services this interruption (step 140) and transfers operations back to the user process program at step 141. In step 142 (FIG. 6G), the user process program 34A retrieves the pointer to the WRITE DEVICE CONTROL MESSAGE packet from the termination queue 57A and, in step 143, tests the status word to determine whether the transfer to the communications device 26B was successfully accomplished. If the transfer is successful, the user process 33A is done until a subsequent data transfer has been completed.
While steps 134 through 143 are being processed, the communications device 26B responds to the receipt of the external command. Specifically, the device 26B processes the command and device message length fields and transfers the device message to a command packet that is formed in a free queue 60B obtained from the user process program 34B (step 144). Then the communications device 26B forms a status longword indicating the presence of the device message (step 145) and, in step 146, inserts a pointer to the command packet on the termination queue 57B in the user process program 34B. In step 147, the communications device 26B interrupts the data processing system 100B and enters the RUN LOOP operating sequence.
The interruption response of the data processing system 100B is analogous to the response of the data processing system 100A. Specifically, the operating system 30B services the interruption in step 148 and vectors further operations to a predetermined location in the user program 34B in step 149 (FIG. 6H). The user process program 34B removes the pointer to the command packet from the termination queue 57B in step 150 and tests the status longword in step 151. The status word indicates the receipt of the command from the external device 27B (i.e., the communications device 26A). In step 152, the user process tests the command field and, in step 153, determines the need to transfer process data from the process data buffer 62A to a corresponding process data buffer 62B.
The transfer of process data can now occur. In step 154, the user process program 34B forms a READ DEVICE command packet in a random access format (FIG. 7C) that will enable the communications device 26A to respond. It contains forward and backward links. The PKT CTRL field is zero, indicating an unconditional interruption state and a suppression of length errors. The CIS field has a value of "3", indicating that the COMMAND CONTROL field, the byte count field and device message field are to be transmitted to the COMMAND register in the external device 27B (specifically, the command interpreter 45A in FIG. 5). The COMMAND field, which was obtained from the command longword in the DEVICE MESSAGE field in the WRITE DEVICE CONTROL MESSAGE command packet from user process 33A, has a value "0" corresponding to the READ DEVICE command. The LLA field, the length of the LOG AREA is zero, as this command does not involve a LOG message. The LDM field, the length of the DEVICE MESSAGE is four. The BYTE COUNT field, which was obtained from the respective field in the DEVICE MESSAGE in the WRITE DEVICE CONTROL MESSAGE command packet from user process 33A, has a value "n". The virtual address of the user process 33B's data buffer 62 in FIG. 3 into which the data from user process 33A will be transferred is included after the byte count. Both the memory and external device residual byte counts are also set to "0".
The device message field contains the virtual address of user process 33A's data buffer with respect to which the transfer will occur, which was obtained from the respective longword in the DEVICE MESSAGE field in the WRITE DEVICE CONTROL MESSAGE command packet from user process 33A.
Following the basic sequence in FIG. 4, the user process 33B transfers a pointer to this command packet to an input queue in the user process program 34B (step 155). Then the user process 33B uses step 156 to transfer a control word to the memory reference controller 52B in the communications deviche GO bit.
In step 157, the communications device 26B transfers the READ DEVICE COMMAND packet in FIG. 7C directly from the user process program 34B to the memory reference controller 52B in the command interpreter 45B. When the COMMAND field that defines the READ DEVICE operation is decoded, the command interpreter 45B uses step 158 to transfer the command in a random access format over the control interconnection 46. Command interpreter 45B also transfers the virtual address from the DEVICE MESSAGE field and the byte count from the READ DEVICE command packet to command interpreter 45A. This enables the transfer of process data from the process data buffer in the data block 35A through the process data path 47A, the data interconnection 51, and the process data path 47B to a designated process data buffer in the data block 35B.
When the command interpreter 45A receives the READ DEVICE COMMAND, the virtual address and the byte count, in step 159 (FIG. 6I), the communications device 26A utilizes the information in the address generator 41A to determine that the READ DEVICE COMMAND packet is properly identified. This enables the transfer of process data to begin.
In step 161, the memory reference controller 52A responds to the command in the command interpreter 45A and address information in the address generator 41A to begin transferring process data from the process data buffer in the data block 35A. The address for each data item is generated by the address generator 41A and so is independent of the central processor 100A including the operating system 30A. Moreover, the memory reference controller 52A routes the retrieved data from the SBI 14A to the buffer 50A in the process data path 47A. When the buffer 50A contains data at its connection to the data interconnection 51, the process data is transferred onto the data interconnection 51 along with control signals which then transfer the data into the buffer 50B.
The communications device 26B processes the READ DEVICE COMMAND by sensing the presence of incoming process data at the connection between the buffer 50B and the interface 40B, thereby to begin transferring data through the interface 40B and the SBI 14B into the process data buffer in the data block 35B (FIGS. 6I and 6J). The address of each location in this process data buffer 35B is identified by the address generator 41B. Each time a data longword is transferred, the memory reference controllers 52A and 52B update or alter their residual byte counts. The memory residual byte count is altered each time a transfer occurs between the process data path buffer and the memory; whereas the external device residual byte count is altered each time a transfer occurs over the data connection.
When all the data has been transferred, the byte counts will be zero. The communications device 26B then forms a status longword indicating the successful completion of the transfer in step 162 (FIG. 6J). As previously indicated, a pointer to the READ DEVICE command packet with the new device status longword is then transferred to a termination queue in the user process program 34B. This causes the communications device 26B to interrupt the operation of the data processing system in step
164, whereupon the operating system 30B services the interrupt in step 165 (FIG. 6R). Once the interruption has occurred, the communications device 26B begins the RUN LOOP operating sequence and awaits the occurrence of the next event.
After the operating system services the interruption, the user process program 34B in FIG. 5 uses step 166 (FIG. 6L) to begin processing of a user program that is determined by the interruption. That user process program removes the READ DEVICE command packet from the termination queue in step 167 and tests the device status longword in step 168. This completes the operations for transferring the process data to the data processing system 100B. In step 169, the user process 33B processes the data in the data block 35B in accordance with the program or function that had been requested in the WRITE DEVICE CONTROL MESSAGE command packet. The results would be stored in another process data buffer in the data block 35B, assuming, for example, that the results are to be returned to the data processing system 100A. It is assumed that this process data buffer has an initial virtual address VA(b) and that "n" data bytes will be transferred.
In step 170, the user process 34B forms a WRITE DEVICE command packet in a random access format as shown in FIG. 7D. The PKT-CTRL field again has a zero value to provide an unconditional interruption state and to suppress length errors. The CIS field has a value of "3". The command interpreter 45B responds to this CIS field by transmitting the COMMAND field, the BYTE COUNT field, and the DEVICE MESSAGE field to the command interpreter 45A. The COMMAND field has a value of "2", indicating a WRITE DEVICE command. The byte count word contains the value "n2". The data buffer virtual address contains "VA(b), which is the address of the first location of the data to be transferred in the data block 35B. The residual byte counts are set to zero. A zero value is in the device status longword. The LDM field in the control word contains a value "4" that indicates that the DEVICE MESSAGE field contains "4" bytes. With this WRITE DEVICE COMMAND packet, the device message would be the virtual address of the command of the process data buffer in the memory 11A, VA(i-1).
Once this command packet is formed and the GO bit is set (steps 171 and 172), the functions of which have been described previously, the communications device 26B retrieves the WRITE DEVICE COMMAND packet directly from the user process program
34B and decodes that packet in step 173. In step 174 in FIG. 6N, the communications device 26B enables the command interpreter 45B to transfer the command field, the byte count, and the device message to the command interpreter 45A over the control interconnection 46. In addition, the memory reference controller enables the transfer of the virtual address into the address generator 41B and enables a data path from the memory 11B through the SBI 14B, the interface 40B, and the process data path 47B to the data interconnection 51.
When the command interpreter 45A in the communications device 26A receives the control information in step 175 of FIG. 6M, the communications device 26A uses the DEVICE message to define the virtual address of the data buffer to receive the information. If the information were to be stored in the process data buffer 62, the DEVICE message would include the virtual address VA(i-1). The address generator 41A uses the privileged control parameter circuit 43A to determine the validity of this virtual address. In step 177, the communications device 26A enables the address generator 41A to produce physical addresses of the process data buffer 64 and enables a data path from the data interconnection 51 through the process data path 47A and the interface 40A over the SBI 14A to the process data buffer 62 in the data block 35A.
Then the transfer occurs. Specifically, data is transferred from the data block 35B into the buffer 50B. It is also transferred from the buffer 50B through the data interconnection 51, into the buffer 50A and from the buffer 50A to the memory
11A. As will be apparent, this transfer, like the prior transfers, occurs without any intervention of either the operating system or the user program.
Once the transfer is complete, the communications device 26B determines the status of the communications device 26A (step 179 in FIG. 6N) and forms a device status longword indicating a successful completion in step 180 (FIG. 6P). A pointer to the WRITE DEVICE command packet is transferred into the termination queue in the user process program 34B in step 181. As previously indicated, this transfer initiates an interruption of the data processing system 100B in step 182, whereupon the communications device 26B shifts back into a RUN LOOP operating sequence.
In response to the interruption, the operating system 30B services the interrupt in step 183, so the user process program 34B begins to process the user program at a predetermined location in step 184. This program removes the WRITE DEVICE command packet from the termination queue in step 185 and tests the status longword including the status of the communications device in steps 186 and 187. The device 26B then forms a WRITE DEVICE CONTROL MESSAGE command packet that is analagous to the command packet shown in FIG. 7B. This packet includes a DEVICE message that indicates that the transfer of the results has occurred. Once the packet is formed, it is placed on the input queue in step 189 and the GO bit in the communications device 26B is set in step 190. Then the communications device 26B removes the WRITE DEVICE CONTROL MESSAGE command packet from the input queue in step 191 and transfers it through the command interpreter 45B over the data control interconnection 46 to the command interpreter 45A.
As previously indicated, operations then commence in both the communications device 26A and 26B simultaneously. Referring first to the continued operations in the communications device 26B as shown in FIG. 6R, the status from the communications device 26A is received over the control interconnection 46A in step 193 and this status is then transferred into a device status longword that is formed in step 194. The command packet is then placed on the termination queue in step 195 to initiate an interruption of the data processing system 100B in step 196. When this occurs, the communications device 26B has completed all activity in connection with the transfer and returns to the RUN LOOP operating sequence.
In step 197, the operating system 30B services the interrupt and transfers operation back to the user process program in step 198. At this point, the user process program 34B transfers to step 199, wherein the status longword is obtained and tested in step 200. Assuming that all the transfers have been properly performed, the user process 33B is then completed and the data processing system 100B returns to other operations or awaits the receipt of a next command from the data processing system 100A.
When the transfer over the control interconnection 46 occurs in step 192 of FIG. 6R, the command interpreter 45A receives the DEVICE message in step 201 of FIG. 6Q, decodes the command, and forms a command packet in a free queue in the user process program 34A in step 202. This includes the formation of a status longword indicating the presence of a device message in the free queue in step 203. Then the command packet is placed on the termination queue in step 204 to effect an interruption in step 205. This completes the operation of the communications device 26A, and it shifts back to a RUN LOOP operating sequence. As a result of the interruption, the operating system services the interrupt in step 206. The user process program then utilizes steps 207 through 209 to remove the command packet from the termination queue, and test the status word and the status of the log area to then determine that all processes have been completed and that the results have been stored in the process data buffer 35A.
An analysis of FIG. 6 illustrates the advantages of the communications device 26A and the reason it greatly facilitates the transfer of information from an external device to memory. First, the communications device controls all the data transfers between the external device and memory and nearly all transfers between itself and the memory. Once an address generator has received the privileged address information, it can generate addresses without any further intervention by the operating system with its attendant transfers over the SBI. Consequently the operating system is used on only a limited basis for servicing interruptions. This portion of the operating system is relatively compact and, in proper circumstances, can be stored in the memory 11A during such a transfer in order to further minimize transfers with secondary storage systems and the memory. Fourth, each transfer occurs independently of the operations in the central processor 10A or 10B. All this greatly reduces total number of transfers over the SBI 14 of the operating system or of other programs which are in the nature of "overhead" transactions as opposed to transactions involving the transfer of process data. Thus, once the data is ready to be transferred, the transfers occur without any significant overhead and the effective rate is, therefore, increased.
B. Specific Implementation
FIGS. 2 and 5 depict communications devices with functional elements, and the foregoing description sets forth a typical use of the communications devices that are constructed in accordance with this intention. With an understanding of this general structure and operation as background, the following description and the remaining drawings disclose a specific embodiment of a communications device that operates in accordance with the functions that have been described previously. This particular embodiment utilizes microprogramming techniques for controlling various data paths that exist within the communications device. The microprogramming control portions of the communications device, therefor, include circuits for performing multiple ones of the particular functions that are set forth in FIGS. 2 and 5.
FIG. 8 depicts the data paths that are incorporated in this specific embodiment. Dashed lines on FIG. 8 generally depict the position of the functional blocks that are shown in FIGS. 2 and 5. It is believed that the best understanding of the construction and operation of this specific embodiment can be attained by first describing the data paths and then describing various basic operations that involve the communications device and the response of the communications device to some specific commands. More particularly, the basic operations for transferring information between the communications unit and the SBI 14, the basic operation of the controller, and the specific operations of the communications device in connection with addressing, and communications over the control interconnection 46 and data interconnection 51 are discussed. An ABORT command, a NO OP command, and a WRITE DATA command, and variations of the WRITE DATA command for command and data chaining are described in detail.
1. The Data Paths
Still referring to FIG. 8, the communications device includes an SBI interface 40 which connects between SBI 14 and an interconnecting bus, designated SBUS 303, and includes transceiver circuits 301 and 302 that connect to the SBI 14. SBUS drivers 304 and 305, SBUS receivers 306, and a multiplexing circuit 307 in the interface 40 transmit and receive signals from the SBUS 303. More specifically, direct communications between the SBI 14 and the SBUS 303 are provided through the SBUS drivers 305 while signals from the SBUS receivers 306 are coupled through the multiplexer 307 back to the transceivers 301 and 302.
A data and control circuit 308 also connects to the transceivers 301 and 302. It establishes paths for various information, primarily control information, that is to be received from and transferred to the SBI 14. Specifically the data and control circuit 308 connects to address logic circuit 310 and command register 311. Signals from the transceivers are also coupled to a data rate register 312 and to a DCR WRITE decoder 313. The DCR WRITE decoder controls a DCR register 314 that provides another input to the multiplexer 307. The data rate register 312 connects to a data rate counter 315 that also provides an input to a multiplexer 307. The other input to multiplexer 307 is an instruction state register (ISR) 316.
The controller 300 connects, as described more fully later, to a microprocessor 317 that includes a microsequencer 318. In one specific embodiment, the microsequencer 318 comprises an AM2909 microprogram sequencer sold by Advanced Micro Devices, Inc., of Sunnyvale, Calif. The microsequencer provides address signals to a writeable control store (WCS RAM) 320. The writeable control store 320 contains microinstructions. Transfers to and from the writeable control store 320 are monitored by a microword register and WCS parity circuit 321. A microword register in the circuit 321 provides various signals that enable transfers to and from other registers based on the microinstructions provided by the writeable control store 320.
A data path circuit 322 comprising, in one embodiment, multiple microprocessor slices such as AM2901 four-bit, bipolar microprocessor slices that also are sold by Advanced Micro Devices, receives address and control information from the writeable control store 320 and the microword register in the circuit 321 and also processes information from a local store 323.
The command interpreter 45 from FIG. 2 comprises a control interconnect circuit 324 that receives signals from the data path circuit 322 through a driver 325. A FLAG 0,1 and STATE register 326 provides signals that are used by both the command interpreter 45 and the address generator 41.
An input multiplexer 327, that is also part of the microprogram slice, receives signals from the output of data path circuit 322, from the local store 323, from the control interconnect circuit 324, and from the microword register in the circuit
321.
The writeable control store 320 transfers the microinstruction through a writeable control store write (WCS WRT) latch 330. More specifically, the microinstructions are coupled from the SBI 14 through the transceivers 301 and 302, the SBUS driver 305, and SBUS receivers 331 to the input of the WCR WRT latch 330. The address in the writeable control store 320 is provided by the microsequencer 318 as described more fully later. Specific addresses may be provided based on certain conditons in the communications device.
A local store address register 332 receives signals from the output of the data path circuit 322 and provides address signals to the local store 323. Information from the microprocessor control 317 can also be transmitted to the S BUS 303
through microprocessor address drivers 333 and data drivers 334.
The address generator 41 includes an SBI address counter 335 and an SBI address lookahead register 336. An S BUS driver 337 couples a selected output from a multiplexer 340 to the S BUS 303. The address counter 335 provides one input to the multiplexer 340.
The memory reference controller 52 receives signals from SBUS receivers 341 that also connect to the SBI address lookahead register 336. A control random access memory unit 342 also receives information from the receivers 341 and transmits information onto the S BUS 303 either through the multiplexer 340 and drivers 347 or through an SBUS mask driver 343. The controller 52 also includes a byte count look ahead counter 344 that receives a byte count from the SBUS receivers 341. An SBI byte counter 345 tracks transfers between the process data path 47 and the SBI 14. A DDI byte counter 346 tracks byte transfers between the external device and the process data path 47.
The process data path 47 conveys data that is received from the SBI 14 through the interface 40, including SBUS receivers 350, to the data interconnection 51. Specifically, a byte rotator 351 and receiver latches 352 in the process data path couple the data to the data interconnection 51 along with various control signals. Data from the external device is coupled from the data interconnection 51 through a transmitting register 353 and into a silo memory 354. A silo control 355, an output address register 356, an input address register 357, and a silo byte count circuit 358 control the transfer of process data into and out of the silo memory 354. Process data is transmitted from the silo memory 354 through a byte rotator 360 and an SBUS driver circuit 361 to the S BUS 303. An SBUS mask driver 362 is also connected to the S BUS 303 and operates in response to signals from the silo control 355.
When information is being transferred into the silo 354, a predetermined sequence occurs. Circuitry including an out-of-sequence control circuit 363, an OSEQ HW latch 364 and an OSEQ LW latch 365 drive the SBUS driver 304 during these operations.
2. Basic Operations
There are certain basic operations that occur in the communications unit shown in FIG. 8 during the operations that are outlined with respect to FIG. 6. Some transfers involve command packets and process data; other transfers involve control information. Examples of the later types of transfers include the steps of transferring the microcode into the WCS memory 320 under the control of the operating system. The transfer of a CLEAR HALT command in step 110 in FIG. 6A is an example of a transfer to a control area of the communications device. At various times, information in any of the control registers, such as the data and control register 308, information from the microsequencer 318, or from the latch 330 might be involved. Analogous information can be transferred to and/or from the byte counters 345 and 346, the control random access memory 342, the address lookahead register 336, and the local store address register 332.
3. Data Processing System Transfers
Each of the foregoing transfers involves a transfer with other components or elements in the data processing system over the SBI 14. Such a transfer occurs through the SBI interface 40. FIG. 9 shows a detailed block diagram of interface 40
including SBI transceivers 370A, 370B and 370C. As described in the foregoing U.S. patent application Ser. No. 945,061, each transfer involves a number of signals, including transfer request signals, information signals, parity signals, tag signals, identification signals, fault signals and confirmation signals. Each SBI transfer requires two or three sequences of transaction intervals which are defined by timing signals transmitted over preassigned conductors in the SBI. SBI transceivers 370A receive parity and information signals from the the SBI 14. SBI transceivers 370A also transmit information and associated parity signals onto the SBI 14. SBI transceivers 370B similarly receive and transmit the ID signals, tag signals and mask signals from and to the SBI 14. Signals from the transceivers 370B are received in a mask decoder 372, a tag decoder 373 and an ID comparator 374. SBI transceivers 370C transmit and receive fault and confirmation signals to and from the SBI 14. A clock decode circuit 371 decodes clock signals from the SBI 14 to generate clocking signals that are depicted in FIG. 9.
As further described in the foregoing U.S. Patent Application, each transfer sequencecomprises a discrete number of bus cycles during which different functions occur. If the user process or operating system controls the transfer, the central processor is a commander nexus, and, after gaining access to the SBI 14, it issues a command/address word that identifies a data transfer function and the address to which or from which the data is to be transferred. If a write transfer is to be performed, one or two successive sequences are used to transfer the data from the commander nexus. If the command is a read command, the responder nexus will issue the data in one or two sequences that follow, usually after some delay. Both the read and write operations can produce the transfer of one or two longwords in succession.
FIGS. 10A thorugh 10E depict a portion of FIG. 9 in greater detail. FIG. 10D depicts the connection of the SBI 14 to the interface 40. Specifically, incoming signals from the SBI 14 are applied to an input of transceiver circuits 370 and to a clock circuit 371 in FIG. 10E. The clock circuit receives the PCLK, PDCLK, and TP signals from the SBI 14 as shown in FIGS. 11A, 11B, and 11C. In response, the clock circuit 371 generates a number of signals. With respect to the operation of the circuit in FIG. 9, a DAR COUNT CLK signal, that is shown in FIG. 11D, and T0 through T3 signals, shown in FIGS. 11D through 11H, are important. The T0 through T3 pulses in sequence define a bus cycle. Each nexus as a transmitting nexus places information onto the SBI 14 beginning with a T0 pulse and receives, or latches, the information on the SBI 14 during a T2 pulse. Thus each time the clock circuit 371 issues a T2 pulse, all the other signals on the SBI 14 are received by the transceivers
370 and coupled to various circuits in the interface 40. Various parity circuits are coupled to a parity generator 372. TAG signals are coupled to a tag decoder circuit 373. ID signals are coupled to a comparator 374. The information signals are coupled to an amplifier and data drivers 375. Various CNF, FAULT, and INTERLOCK signals are coupled to a bus control circuit 376. The received SBI information signals are coupled to drivers 375 and an address and function checking circuit 376 and a buffer 377. A bus control circuit 380 receives CNF, FAULT, and INTERLOCK signals. Arbitration signals and interruption request signals are coupled to other portions of the communications device as described later.
The decoder 373 in FIG. 10D decodes the incoming TAG signals to indicate the nature of the signals in the information path. This information may be READ data, WRITE data, an interruption summary request, or command/address information. When the TAG signals identify the information on the SBI as read data or write data, the information signals contain a longword of data. When the TAG C/A signal is asserted, four high order bits of the information define a function and the remaining 28 bits define an address. The address and function checking circuit 376 receives the address signals when the decoder 373 in FIG. 10D asserts the TAG C/A signal.
The communications device shown in FIG. 8 comprises a number of addressable locations that define hardware registers and various memory locations. Four sets of such locations are important and each of these four sets is identified by two bit positions in the address space. A first set comprises a number of hardware registers and they are shown in FIG. 12. A DEVICE COMMAND register DCR 381 comprises a thirty-two bits. Each bit or group of bit positions in the DEVICE COMMAND register 381
has meaning as shown in FIG. 12. A reference control field establishes a number of operations. These are established when a write operation loads new contents into the DCR register. During read operations, this same field can be retrieved and when it is, the bit positions have meanings that are shown in the reference block. The specific use of the DCR register 381 is described later.
Other hardware registers in the first set of memory locations include a utility register 382 that stores a data rate for controlling the transfer rate over the data interconnection 51 in FIG. 8. As described later, the control receives address information in the microsequencer 318 and write information in a WCS WRITE latch 330 during the loading of microcode into the communications device shown in FIG. 8. These two registers, namely the WCS ADDRESS register 318 WCS WRITE latch 330 can be addressed in this set of locations. A silo address counter 358, the SBI byte counter 345 and DDI byte counter 346 are also included. A number of other registers can be used for control and they are generally designated by reference numeral 383.
When the transceivers 370 receive any of the addresses in this set of locations, , circuitry including the address and function checking circuit 376 and a latch 384 coact to identify the specifically addressed register.
The second set of addresses establishes locations that are used by the user process. When one of these locations has been identified, an AND gate 385 asserts a SEL USER SPC signal to indicate that the selection of user space. The other two sets of memory locations define specific addresses in the local store 323 that is shown in FIG. 8. The particular meaning of some of these locations is depicted in FIG. 13. The previously described device status longword is located at a base address and is identified by reference numeral 387. The other identified locations are used to store various addressing information that the address generator 41 in FIG. 8 uses in converting virtual addresses to physical addresses.
The information also received from the SBI 14 includes a MASK field. This information is received in a decoder 390. During a COMMAND/ADDRESS or WRITE DATA transfer, the MASK bits define specific bytes in a longword. When the TAG signals identify the information as being READ data, the MASK specifies the integrity of that data. That is, it indicates whether the data is correct, has a one bit error that has been corrected, or contains an uncorrectable error. Thus the decoder 390
generates a READ DATA or CRD (CORRECTED READ DATA) signal, a VALID RD DATA signal when either of the prior two signals is asserted and an RDS signal whenever the READ DATA or CRD signals are asserted and the TAG READ DATA signal from the decoder 373 is asserted.
Throughout the description of FIG. 6, references were made to setting a GO bit in the communications device. This process is initiated by generating a COMMAND ADDRESS function for a write operation that identifies a location in a user control address, namely register zero in the user control space. When this occurs, the address and function checking circuit 376 (FIG. 10E) enables a AND gate 391 so that on the next T1 pulse and T2 pulse flip-flops 392 and 393 are set successively thereby to assert an EN GO signal. During a subsequent write operation, the TAG WRITE DATA from the decoder 373 in FIG. 10D and a PAR OK signal from the parity generator 372 energizes an AND gate 394 in FIG. 10E which energizes another AND gate 395 if a stable halt condition does not exist. When the command is to set the GO bit, the "0" bit position in the data contains a "ONE". Thus, the next T1 pulse sets a flip-flop 396 as the "ONE" in the zero, or least significant bit position of the information in the WRITE DATA is asserted to energize an AND gate 397. When the flip-flop 396 sets, the GO signal shifts to an asserted state and initiates a sequence of events in the communications unit shown in FIG. 8 as described later.
Information is routed to a number of different locations within the communications device over the S BUS 303 through the drivers 375 (FIG. 10D) when an ENABLE SBUS signal is asserted. The ENABLE SBUS signal is generated each time the clock circuit 371 asserts the T3 pulse. Referring specifically to FIG. 10B, a FROM SBI signal energizes an AND gate 400 when an AND gate 401 is not energized. The AND gate 401 is energized only after the communications device has experienced read data from two different requests coming back out of order and subsequently the out of sequence read data has arrived. Thus the received S BUS signals are placed on the S BUS 303 during each S bus cycle.
It is, of course, also possible to transmit signals from the communications device in FIG. 8 onto the SBI 14. There are a number of sources of such signals. As shown in FIG. 10D, each T0 pulse loads the information on the S BUS 303 into a latch
402 that then generates REC SBUS signals. A multiplexer 403 receives the REC SBUS signals at an A input and signals representing a number of error conditions, SIGNAL IN signals, and signals from the DCR register 381 at a B input. The data rate signals from the data rate register 382 in FIG. 10E are coupled to the C input and INTERRUPTION SUMMARY READ signals from a latch 404 in FIG. 10C are coupled to the D inputs. These signals are selectively coupled to the information signals portion of the transceiver 70 in response to OUT MUX 1 and OUT MUX 2 signals from OR gates 405 and 406 in FIG. 10C. During an INTERRUPTION SUMMARY READ signal, an ISR signal energizes both OR gates 405 and 406 thereby to couple the signals at the D input to the output of the multiplexer 381. If a COMMAND ADDRESS word identifies the DCR register and a reading operation, an AND gate 407 is energized while an AND gate 410, that is energized when a UTILITY REG signal is asserted, is deenergized. This asserts the OUT MUX
1 signal and selects B input. When the AND gate 410 is energized, the C input is selected. When neither is energized, it is assumed that the information is from the user space and the A input of the multiplexer 381 is selected as the signal source. Other circuitry in the system then causes the data to be transmitted onto the bus. Along with this information is SBI ID information from a multiplexer 411 in FIG. 10A. It issues XMIT ID signals that correspond to ID switches 412, or to the RECEIVED ID signals in the latch 413.
The communications device includes circuitry for implementing two separate transaction sequences over the SBI, that can be overlapped. Each includes a separate identification on the SBI 14, here referred to as ID1 and ID2. When a unit responds to a read from the communications device, it returns the ID, either ID1 or ID2, that was transmitted with the READ command and address. Comparator 374 receives the ID and asserts MY ID1 to enable AND gate 414 or MY ID2 to enable AND gate 415. If MY ID1
is asserted, and a READ PENDING 1 signal from the memory reference controller is asserted, AND gate 414 enables AND gate 416. If the parity is satisfactory, and VALID RD DATA is asserted from MASK Decoder 390, AND gate 416 will asset an ID1 RD OK signal, which is received in the memory reference decoder.
4. Command Interpreter and Control Interconnect
The command interpreter 45 that is shown in FIG. 8 utilizes the microprocessor 317. FIGS. 14A and 14B illustrate this microprocessor 317 including the microsequencers 318 and data paths 322 and the circuitry associated with the command interpreter 45 of FIG. 8.
When an EN SBUS RCVR signal from a flip-flop 480 on FIG. 15 enables an SBUS latch 331, a FROM SBI signal from the clock decode circuit 371 (FIGS. 9 and 10E) loads the information signals from the S BUS 303 into the latch 331. A Data Bus 425, which in one specific embodiment includes 32 data lines, transfers signals from the latch 331 to the control 300, shown in more detail in FIG. 15.
With reference to FIG. 15, signals from certain of the data bus lines are received in a latch 430, enabled by the REG SEL signal from command register 311 shown on FIG. 9, when clocked by the T1 clocking pulse. The outputs of latch 430 and the complemented REG SEL signal energize a decoder 431. The REG SEL signal, when asserted, indicates a transfer with one of the registers shown in FIG. 12. A WRITE PENDING signal conditions the "D" input of a flip-flop 432, clocked by a T2 clocking pulse; and the flip-flop 432 provides a third selection input to the decoder 431. The output of the decoder 431 is fed to a network of AND gates, including AND gate 434, which is enabled when a WCS VALID signal, from a flip-flop 465 on FIG. 16, is deasserted. The output of AND gate 434 in turn enables AND gate 435, which is then energized when a WCS ADR REG 00 signal from a flip-flop 476 on FIG. 16, is not asserted. The AND gate 435 generates a WRT WCS D (31:00) signal that conditions the set input of a flip-flop 436 clocked by the T1 clocking pulse, to produce an EN LOW LATCH signal for latch 330 on FIG. 14A. The output of AND gate 434 also enables the AND gate 437 to be energized when the WCS ADR REG 00 signal is asserted thereby to generate a WRT WCS D (39:32). This signal conditions a set input of a flip-flop 438, also clocked by the T1 clocking pulse, to produce an EN HIGH LATCH signal. The output of AND gate 434 also conditions the set input of a flip-flop 440 which is clocked at time T2, to assert an EN WRT DATA signal. The signals from flip-flops 436, 438 and 440 provide enabling inputs to latch 330, shown on FIG. 14A.
AND gates 442 through 444 also receive signals from the decoder 432. AND gate 442 is enabled by the T1 signal to assert a WRT UTILITY T1 signal. AND gate 443 is enabled at time T2 to produce a WRT UTILITY REG signal. AND gate 444, also enabled by the T2 signal, generates a WRT WCS ADR REG signal.
The output signal from flip-flop 432, the stage of latch 430 that receives the Data Bus line 08, and the REG SEL signal all condition an AND gate 445 to assert a USER WRT LS signal. This signal provides one enabling input to OR gate 446, which is also enabled by an UP READ DATA signal from an OR gate 882 on FIG. 27C, and an LD LS DATA signal from OR gate 458 on FIG. 16. The output of OR gate 446 enables an AND gate 447, which is clocked by T1, to assert a WRT LS signal.
Still referring to FIG. 15, control 300 also includes an OR gate 448 that is enabled by a WRITE CODE 1 or a WRITE CODE 0 signal from Flag 0 of flag register 326. WRITE CODE (0,0) and (0,1) refer to writing operations on the S BUS 303, while WRITE CODE (1,0) refers to writing operations of the SBI Byte Count register 345 and WRITE CODE (1,1) refers to writing operations of the DDI Byte Count register 346. A complemented signal from the OR gate 448 provides one enabling input to AND gate
449, which is energized by the UP DATA EN signal. When the AND gate 449 is energized, an OR gate 450 generates an EN DATA DRVRS signal. With reference to FIG. 14A, the assertion of the EN DATA DRVRS signal conditions an AND gate 451 to be set in response to a TO SBI signal from the SBI interface 40 thereby to convey signals through the drivers 334 to the S BUS 303.
The OR gate 450 is also energized by a GRANT signal from memory reference controller 52 or by AND gate 452 which senses the coincidence of an ADR LATCH 08 signal from latch 430, the USER WRT LS signal and the REG SEL signal from command register
311. The REG SEL signal when asserted indicates a transfer with one of the registers shown in FIG. 13.
As previously stated, the Data Bus 425 has thirty-two lines. However, in this specific embodiment there are forty lines between latches 330 and writable control store 320, and the microprogram code for each step in the microprogram is forty bits wide. The latch 330 contains forty stages, and an EN LOW LATCH signal enables the lower thirty-two stages to latch the signals from and to the corresponding lines of the Data Bus. An EN HIGH LATCH signal enables the upper eight stages to receive the signals on eight selected lines of the Data Bus and to place those signals on the upper eight lines to the WCS 320. Address signals from latches 330 are preliminarily received in microword register 321A and parity generator 321B. The outputs from the microword register 321A provide various signals for directing information over the Data Bus 425 to and from the various registers and stores shown on FIGS. 14A and 14B, that is, it establishes the sequence of register transfers that the communications device utilizes to perform its various functions. An R DEST decoder 453, a portion of which is shown in FIG. 16, provides additional loading and clocking signals.
With reference to FIG. 16, four lines connect the microword register 321A to the R DEST decoder 453. Three of the four lines connect to the select (SEL) input of decoders 454 and 455. A T0 clock pulse also connects to energize the decoder 454. The fourth line from microword register 321A provides an enabling signal for decoder 455, and its complement provides an enabling signal to decoder 454. Thus, when decoder 454 is enabled, one of the state registers, the flag registers, or the C DATA register is clocked. If decoder 455 is enabled, one or more of several signals are produced that are required to access the local store address counter 332 and the local store 323. One signal is an LD LSA local store address register loading signal from decoder 455 that energizes an OR gate 456 to produce an LD LS local store loading signal. A second input to OR gate 456 is provided by AND gate 457 which is energized when a SEND HALT signal is asserted if the REG SEL is not asserted. An LD LSD local store data load signal and an LD LSD/LSA+1 signal from decoder 455 enable OR gate 458 to assert an LD LS DATA signal. The LD LSD/LSA+1 signal enables the local store to load the next second longword in an extended read transfer operation over the SBI in the next subsequent storage location in the local store. An LSA+1 signal and the LD LSD/LSA+1 signal from decoder 455 also energize an OR gate 459, which conditions the set input of a flip-flop 460, which in turn is clocked by the T2 signal. When the flip-flop 460 sets, an OR gate 461 generates an LS CEP signal. A UP READ DATA signal constitutes a second input to the OR gate 461. An OR gate 462 enabled by either clocking signal T2 or a WRT LS signal from AND gate 447 on FIG. 15 provides a CLK LS signal. The two remaining outputs of decoder 455 generate an UP INIT signal and a SHF IN ZEROES signal.
The microword register also includes circuitry for detecting parity errors as shown on FIG. 16. The signals from the WCS lines are received in a parity generator and decoder 321B, which is clocked by the T2 clock signal, to determine if a parity error has occurred. If a parity error is detected, a WCS PAR ERR signal is asserted. The WCS PAR ERR signal conditions a flip-flop 463 to be set by the T2 clock signal thereby to energize an OR