CA1170739A - Network access device - Google Patents

Abstract

ABSTRACT OF THE DISCLOSURE

A network access device (NAD) is comprised of a data set for coupling to a data communication trunk, a trunk control unit (TCU) connected with the data set, a trunk control interface (TCI) connecting the TCU to an internal data bus, an internal memory, a microprocessor control and a device interface for connection to a computer or some computer peripheral device. The data set pro-vides for two-way communication from the data trunk to the TCU. Various net-work access devices connected to the data trunk communicate with one another.
Every normal communication between NADs includes a concurrent, predictable state change in both NADs. The response to a message from one NAD to another includes information concerning what occurred upon receipt of the message. Various latches, sequencers, microprocessor logic and registers provide for functions according to various input and output states of response.

Description

t3 ~

High performance computer systems operating at modern, high-speed data rates must provide for complex communication protocols when connected in a net-work pattern. This invention relates to the system or device which provides for connection between a computer device oE some sort ancl a network system. The type of computer device which may be connected through a network access device according to the present invention may consist of a computer mainframe, a computer main memory3 or any accessory or peripheral device conventionally used with a computer system.
Typical prior art communication devices for interconnecting computer devices with network systems primarily provide for sending messages, receiving messages and acknowledging receipt of the message. The present invention pro-vides for a higher level of logic beyond that of acknowledgment of messages.
l~e present invention provides for a message response protocol which indicates the type o actlvity or action taken upon receipt o~ a message.
Included in each network access device (NAD) is at least one data set, one trunk control unit (TCU) and one trunk control interface (TCI). There may be several data set and trunk control unit combinations, however, all connected to a single trunk control interface within the network access device.
Each trunk control unit is connected through a data set to the data trunk or to various data trunks so that a network system involving'several data trunks may be employed. Each trunk control interface is connected to a bus system which is connected with a computer mainframe, a main memory or some computer device interface.
Both the trunk control unit and the trunk control interface depend on microprocessor control for various functions and a controlware memory for providing instructions to the microprocessor.
T~e trunk control interface coordinates, transmits and receives , '~ .~

'`7~ 3 operations between trunk control units and an internal buffer memory.
The trunk control interface enables the selected trlmk control unit to deliver incoming messages to the buffer memory and issues commands to a selected trunk control unit to transmit a message on the data trunk.
The trunk control interface responds to microprocessor commands by returning status and interrupt signals which signify the passage of messages between the buffer memory and the trunk control unit. A trunk control unit is enabled for message receiving by the trunk control interface and a received message may be passed to the buffer memory by way of the trunk control interface.
A trunk control unit in the transmitting enabled condition may transmit a message coming from memory. A trunk control interface may be enabled in the transmit and receive mode simultaneously and if a contention situation occurs, the receive mode prevails.
The trunk control unit interfaces a bit serial trunk data set or modem ~modulator - demodulator) to the bit parallel trunk control interface.
The trunk control unit performs data trunk level protocol functions and ensures that a response message is always returned to a correctly received command message. The trunk control unit is always synchronized to the data trunk for transmitting command messages. A trunk control unit is enabled to receive ~20 messages by the trunk control interface and will pass the received messages to the trunk Fontrol interface and ~1~ if a response message, release the data trunk and (2) if a command message, wait for a microprocessor slgnal by way of the trunk control interface to send a response message. If a slgnal to send a response message is not forthcoming, the trunk control unit w;ll generate and send an errar response message.
The data~network operates on a time slot system. A trunk control unit when it is enabled to transmit a command message must wait for its

2 -.

particular time slot on the data trunk before it ccm transmit~ If a commandmessage for the particular access device appears on the trunk before the transmit slot time, or appears on another trunk enabled for receive, it is accepted by the trunk control interface and the transmit command is discarded. The network access device microprocessor then must resubmit the transmit message if it is still appropriate.
Command messages are accepted from the data trunk by the trunk con-trol unit and passed to memory through the trunk control interface. After transferring the message into memory, the trunk control interface interrupts the microprocessor control. The trunk control unit and trunk control interface wait for the microprocessor to provide a send response signal. The trunk control unit holds the data trunk active while waitin~ for this signal. The microprocessor control determines the proper response message and signals the trunk control intereace to send that response.
The trunk control unit will always return a respense message to a command message correctly received and addressed to it. The response message normally originates in microprocessor memory, but can originate within the trunk control unit when the trunk control unit is not enabled for reception by the trunk control interface, when the trunk control unit is enabled but the trunk control interface is busy, and when the interval timer times out without a send response signal from the microprocessor. The response status message indicates which of these conditions exist. A command message can be sent from a trunk control unit only during the transmit time sIot. If however, a command message arrives before the transmit time, on any of the enabled receive trunks, then the hardware will perform the receive and discard the transmit message.
There are three different modes of communication between pairs of network access devices. Each mode is tallored to a specific work function to

- 3 -~:
,, .. ,, ~.,., . ~ . . -, . - -- ~ ' .: ~: : ~
, .. . .
- ~ :

:: :

7';3~3 effectively use the data trunk and network access device resources. Each command message and response message always occur in pairs.
The first mode of operation consists of one command-response message pair. A control message is directed to the device and has a meaning or function defined by a higher level protocol or a flow control message is directed to the network access device processor.
The second mode is a two command-response message set used for transmission of data. The first command identifies the data path and the buffer size required. The receiving network access device returns an acknowledged signal and enters the data streaming mode if the data transfer is permissible.
The sending network access device then immediately translllits the data and a closing acknowledgment is returned at which time both network access devicos exit the data streaming mode. If the receiving network access devic~ cannot accept data, it will return a negative signal and remain in a non-data streaming mode. The data trunk is captured by the pair of network access devices until the fm al acknowledgment signal is returned.
The third mode is a special form of data transfer in which data trunk multiplexing is eliminated by capturing the data trunk in a streaming mode for the entire dùration of a large data transfer. Consequently, total trunk ~20 bandwidth is allocated to the path capturing the trunk. Two useful results ~` are obtained. First, the data path transfer rate is maximum since trunk loading has been eliminated and protocol usage of the trunk which lS a form of operating overhead is minimized. Secondly, all other network access devices on the data trunk have been suspended momentarily from use of the trunk.
Each message contains several blocks of information in coded fields.
Each message includes a header which will be explained in detail later.
Each message contains information defining the function of the

4 -. . - . , .

:: :
.
:, ~7~)~73g message and a message sequence number which is incremented for each message sent.
The body of the message is dependent upon the type of command message being sent.
For example response messages have no body contents to the message.
~ negative response message is generated by the microprocessor.
Such a message can be a response to any commcmd message. A negative response informs the sending unit of the command message tha~ the resources necessary to process the command are not available. The sending unit must not attempt another transmission of the same type ~mtil notified that it is allowed to do so. A NAK response message instructs the sending network access device to discontinue sending traffic destined for this particular ~mit. A ~AIINAK
response message instructs the sending NAD to hold all traffic dcstlnecl for the receiving NAD until a status change message is sent indicating that bufer resources are availabLe so that the rejected transmission may be retried. Thc status change message is ~mique in one respect. The status change message can be rejected the same way as any other command message but the sender of the status change message must wait a predetermined time period to retry the same message and not wait for its own status change message before retransmitting.
Due to the nature of this message the retry sequence is infinite.
A message transmission retry must occur when there is a message transmission abnormality. A transmission abnormality occurs when no response is forthcoming to the command message sent. The main reasons for a no response are: ~1) a non-existent network access device is addressedJ ~2~ the command message is garbled on the data trunk causing the destination field to address a nonexistent network access device or there is a check sum error at the receiving unit in which case no answer back i5 sent or (3) the command message is received correctly and a response message is transmitted but is garbled on the data trunk. When a transmission abnormality occurs~ the co~nmand message is ., .. . .
. ' ` , ' . ' ' " ~ ; , . ' - ' ' ~ '~ .

7. ~3 retransmitted using the same message sequence number up to a predetermined number of times until a response message is received. If a response message is never received after a number of retries, a fatal error has occurred in the sys tem .
at occurs in response to a fatal error depends on the type of command message sent. During the retry process, the microprocessor control willnot attempt to send any other command messages to the particular receiving unit.However, the particular sending unit will accept incoming command messages.
Every response message includes a status indication of the respond-ing network access device. One of these status bits may be a trunk controlinterface busy bit. This bit signals that, althougll the command message ~as received by the destination trunk control unit correctlyJ it could no-t be passocl onto the buffer memory. ~lence the response returned is likewise not from a microprocessor control but is generated in-ternally to the trunk control unit.
Since the network access device processor at the destination did not receive the command, the command must be retransmitted. Assuming that the remainder of the response status is correct, the command message would be queued for retry by the sending unit. The retransmissions will occur until accepted by the destination network access device or until a fatal error occurs. Other command ZO messages may be sent during the interval between transmission retries.
A destination fatal error signal may be transmitted indicating, for example, that the associated compu*er device is not operating or other similar fatal errors at a destination location. A command message is not retransmitted when a fatal error message is returned as the response message.
A fatal message error is one which is caused by a hardware error during the transmission of a trunk command response pair. These errors can be caused by network access device failures including the trunk control interface "~
.

.~ . . .
' ' :

3~

or the trunk control unit, data set fai]ures or of complete failure of thenet~ork access device. These are error conditions ~hich can be reportecl by the trunk control interface and trunk control unit llardware by status or interrupt messages. The fatal message errors are considered Eatal aEter the retry sequence occurs unsuccessfully a number of times.
If fatal error occurs while transmitting a user control message, the message is returned to the device via the control message queue. A status bit within the message header indicates the message could not be delivered. A
fatal error while transmitting data on an established data path causes the path to be terminated. All resources allocated to that data path are released ~md the device is notifiéd of the fatal error.
Each mqssage includes a header frame check sequencc (~CS) :im1necl:iately follo~ing the length of message field. The Ernme check sequence field serves to detect errors induced by the transmLssion data link and to validate the transmission accurac~. The frame check sequence results from a mathematical computation on the digital value of all binary bits in the frame following the frames synchronization sequence. The process is known as cyclic redundancy checking using a particular generator polynomial. The remainder value in the transmitter for the polynomial is initialized to all ones before a frame is transmitted. The binary value of the transmission is premultiplied by a predetermined factor and then divided by the generator polynomial. Integer quotient values are ignored in the transmitter since the complement of the resulting remainder value, high order bit first, is sent as the frame check sequence field. At the receiver the initial remainder is preset to all ones and the same process is applied to the serial incoming bits. In the absence of transmission errors, the final remainder is a predetermined value. The receiver will discard a message not having that predetermined remainder value.

.
, :

' '' , ' , Subsequent retransmission of the discarded message is under the control of error recovery procedures.
In accordance with one broad aspect of the invention there is provided a network access device adapted to be connected to a data trunk for trans-mitting and receiving messages from said data trunk and for interconnecting various computer devices to said data trunk, said network access device com-prised of: a data set for receiving and transmitting data into and out of the network access device for connection to a data trunk, a trunk control unit connected to said data set for bi-directional communication into and out of said trunk and for transmitting at least first and second types of com~ancl messages and for receiving at least first and second types of response messages, a first type of command message being generated by said tnmk control unit to indicate the status of said trunk control un:Lt and a first type of response message being used by said trunk control unit to control the status of said trunk control unit, a trunk control interface connected to said trunk control unit and having means for connection with at least one additional trunk control unit for buffering of data transmitted to and received from said trunk control unit, said trunk control interface being responsive to control signals to re-spond to said trunk control unit in a selected function from a group oE avai-: 20 lable functions, said available functions including receiving data from or transmitting data into said data trunk, a network access ~evice internal bus connected to said trunk control interface, a network access device processor operating as a microcode sequencer and issuing output control signals connected with said internal bus for controlling said trunk control interface and trunk control unit by generating addressed status and interrupt control signals to said trunk control interface and to said trunk control unit, said processor generating at least some of said addressed control signals in response to sig-nals received from said trunk control interface and said trunk control unit, , 8 ~ : :

:~ :

.
'.

'7. ~3 said processor also generating a second type of command message and recelving a second type of response message to control the network access device, a trunk control unit input bus connected to said trunk control unit and said data set to receive signals Erom said data set and which is accessed by a number oE tri-state drivers included in said trunk control unit each of which is controlled by said microcode sequencer logic and clock signals produced by said network access device processor and transferred by said trunk control interface to control access to said trunk control unit input bus at predeter-mined times according to said microcode sequence, an internal network access device memory connected with said internal bus, and a device interface con-nected with said internal bus for communication through said trunk, control interface to said trunk control unit and to said data trunk ~hrough said data set and having an output devlce chamlel aclapted for conneetion to an approprl-ate computer device~
In accordance with another broad aspect of the invention there is provided a network access device co~prised of: a data set adapted to be con-nected to a data trunk, trunk control unit means connected to said data set for bi~directional communication into and out of said trunk and for trans-mitting first and second types of command messages and for receiving response messages, and wherein for each command message sent as the response to a re-ceived message, the command ~essage provides status information about the network access device, a trunk control interface connected to said trunk con-trol unit for buffering of data, said trunk control interface having means for connection to at least one additional trunk control unit, and wherein said trunk control interface includes a control Iatch for receiving status infor-~ation from said trunk control unit with respect to the mode of operation of said trunk control unit, a network access device internal bus connected to said trunk control interface, a network access device microprocessor connected _ g_ .. . .
~: : ' ' : ~
.: .

73~

with said internal bus for controlling said trunk control interface and trunk control unit b~ generating addressed control signals to said trunk control interface and said time cont:rol unit, an internal network access device memory connected with said internal bus, and a devlce interface con-nected with said internal bus for communication through said trunk control interface to said trunk control unlt and to said data network through said data set and having an output device channel adapted for connection to an appropriate computer device.
The invention will now be further described in conjunction with the accompanying drawings, in which:
Figure 1 is a bIock diagram of a network access device acc:ording to the p:resent invention.
Figure 2 is a block dlagram showing the use of a network access device according to the present inventlon together with various computer devices in a data network.

:;

~ ~7~39 Figures 3A, 3B 3C and 3D represent a schematic block diagram of a network access device trunk control unit according to the present invention for Figures 3A, 3B and 3C are arranged in left to right order with Figure 3D beneath 3B.
Figures ~A and ~B are details of the block cliagrams of Figures 3A
through 3D.
Figures 3E and 3F schematically show the command and response message structure, respectively.
Figures 5A and 5B are detailed schematic diagrams of a portion of the device shown in Figures 3A through 3D and are to be seen in left to right orcler with Pigure 5A on the left.
Figures 6A and 6B are detailed showings of the device sllown on Figures 3A through 3D and to be taken in leEt to right order with Figurc 6A on the left.
Figures 7A, 7B, 7C and 7D are detailed showings of the device shown in Figures 3A through 3D and are to be taken with Figures 7A and 7B in left to right order on the top and Figure 7C and 7D in left to right order beneath Figures 7A and 7B.
Figures 8A and 8B are detailed showings of the device shown in Figures 3A through 3D with Figure 8A to be taken to the left of figure 8B.
Figure 8C is a detail of a portion of the device shown on Figures 3A
through 3D.
Figures 9A, 9B, 9C and 9D are detailed showing of the portion of the device shown in Figures 3A through 3D and are to be~taken with Figures 9A and 9B
on the top in left to right order with Figures 9C and 9D in left to right order beneath Figures 9A and 9B.

~ -.
~. ~
: :

;.
: , . , 3L~17~?3g ~ igures 10A, 10B 10C and lOD are detailed showings of portion of th~ device shown in Figures 3A through 3D and are to be taken with Figures 10A
and 10B in left to right order and Figures 10~ and 10C in leEt to right order beneath Figures 10A and 10B~
Figures llA, llB and llC are a detailed showing of a portion of the device shown in Figures 3~ through 3D with Figures llA and llB to be seen in left to right order with Figure llC placed below Figure llA.
Figures 12A, 12B, 12C, 12D and 12E represent a schematic block diagram of a trunk control interface device of the network access device shown in Figure 1 and are to be seen with Figures 12A and 12B in left to right order with Figure 12C below Figure 12A and Figure 12D below ~igure 12C, and Figure 12E to the right of 12C and below 12B.
Referring now to ~igure 1, a network access device 10 according to the present invention is shown connected with a data trunk 12. A network access device consists of at least one data set 14 connected between the data trunk 12 and at least one trunk control unit 16. Other data sets 18, 20 and 22 may be provided connected to the same or other da-ta trunks. Each of data sets 18~ 20 and 22 would be connected with its own trunk control unit 24, 26 or 28, respectively. Trunk control unit 16 is connected to a trunk control interface 30 as would be any other trunk control units in the same net~ork access device.
The trunk control interface 30 is connected to an internal data bus 32 which is connected to the network access device microprocessor 34, the buffer memory 36, a maintenance interface for diagnostic maintenance routines 38 and a device interface 4Q. Device interface 40 provides a data channel 42 to be connected to a computer mainframe, a computer memory or any peripheral or auxilliary equipment to be associated with a computer system.

.. .
..

,~
,,., . :

, ' ':

~0~39 Referring to Figure 2, a plurality of network access devices accord-ing to the present invention are shown in various situa-tions to illustrate their use in a computer communication network system. A computer mainframe 50, which Y ~ ~ may illustratively be a Control Data Corporation CYBER~176 computer, may have several device channels 42 connected with a plurality of network access devices 52a, 52b, 52c, 52d and 52e. Each of network access devices 52a through 52d has at least two data sets and trunk control units. Network access device 52e is shown to have only one trunk control unit and one data set. Five data trunks 60, 62, 64, 66 and 68 are provided. Thus, the various network access devices 52a through 52d are connected to a pair of data tr~mks as shown in Figure 2.
All of network access devices 52a through 52e are connected to data trunk 60, for example, while only network access device 52a has a connection to data trunk 68.
A network access device 70 having two tr~nk control units is shown connected to data trunks 60 and 68 and connected with a mass memory disk storage system by means of a device interface 72 with disk storage units 74, 76, 78 and 80. Similarly the network access device 82 is connected with data trunks 60 and 66 and to a second device interface 84 for the same unit comprised of disk drives 74, 76, 78 and 80.
To represent a similarJ but separate, combination network access devices 86 and 88 are connected respectively with interfaces 90 and 92 and with a disk system comprised of disks 94, 96, 97 and 9~. Finally, a network access device 99 may be connccted with a special purpose station 95 which may have any predetermined described function. Thus, the various network access devices according to the present invention can facilitate a variety of intercommunications between the various devices shown connected to the data network and to other devices which may be located elsewhere but not shown on the data ne~work. It is ~r~de M~k 12 -, ~
- ~

7~7~

possible ~or example for disc 94 to communicate through interface 90 network access device 86 through data trunk 64 to network access device 52c and to computer mainframe 50. ~lowever, the same network access device 86 may also set up a communication link with computer mainframe 50 by means of data trunk 60 and network access device 52e. The possibilities are obviously too numerous to be described but should become apparent by inspection of the drawing and proper reflection.
Referring generally now to Figures 3A, 3BJ 3C and 3D, a block schematic diagram of the tr~mk control unit is shown. Referring now to Figure 3B, the data communications trunk ~trunk 12 in Figure 1), is shown schematicallyby numeral 100 connected to data set 101. The data set or modem 101 supplies serial data on data trunk 102 to the serial to parallel interface logic Ull:it 103. Clock data is provided from the data set to tlle interface logic unit 103 on bus 10~.
Control signals are provided on buses 105 and 106 from the data set 101 to the logic unit 103. Bus 106 conveys the channel active signal indicating that there is activity on the data channel and the Data Ready signal is providedon bus 105 to indicate that data is to be conveyed into the interface logic , unit.
Logic unit 103 takes serial clock data provided on bus 104 and generates various clock signals provided to further logic units in the trunk control as to be described later. The logic unit 103 assembles serial data in 8 bit bytes for transmission to further elements of the system as will be described further.
The FCS clock 107 is used to run the FCS register 120 for both generating and checking. The FCS clock unit is also used for clocking data bits into the TCU data memory input buffer 121. The byte clock on bus 108 is ,~ .
~,` ' , ~1707;3~

used to control the byte input holding register 123 which assembles for the first time the serial data bits into the 8 bit bytes.
The PRO~I clock 109 and the test clock 115 are the t~Yo clocks that run the trunk control unit sequence ~it 124 as shqwn on Figure 3A. The channel active signal 111J from logic unit 103, the Data Ready signal 113, the byte clock lOS and the clear to send signal 114 are all connected as inputs to the test multiplex switch 130. The output of switch 130 is connected by bus 131 as an input to the PROM 124. The logic unit 103 produces a channel active signal 111 which is sent through test MUX 130 to the TCU microcode. The micro-code then realizes that a message is to be received off the data tr~mk and theunit 103 causes the clock to the sequencer to be stopped ~mtil the first zero of the sync byte character is detected by ~mit 103.
Once the first zero of the sync character is detected by ~mlt by 103, the TCU sequencer in Figure 3A is provided clock signals again ~Yhich causes the TCU sequencer to be in bit sync with the data coming off the trunk. AS the sync character comes into unit 103J it is then put into byte form at unit 123.
From the holding register i23 the data goes to an input bUs 140.
On this input bus a logical unit decoder 141 determines whether the proper sync character is on the line at that moment. The output 142 of decoder 141 is fed into the test MUX unit 130 for the TCU microcode to test. The output of the decode of the sync byte decoder is 142. The TCU microcode then tests the output of that decoder and if the valid sync character has been detectedJ
microcode will allow the TCU to begin looking at the rest of the message which is coming from the data trunk. As the data is converted into ~ bit bytes at register 123, the bytes are placed on the TCU input bus 140 which also feeds parity generator 146 through bus 145. The parity generator generates odd parity for each 8 bit byte. The output of the parity generator runs to both the input .
.
- : . - . : .

~ ,' ' ' ' " -,- , ' ' ' ~ 7V~3S~

buffer of the TCU 121 and also to an upper byte parity register 1~7. The clock which stores each byte of data i~to memory 121 comes rom AND gate 148.
The input buffer memory~l21 is also used to assemble 8 bit bytes into 16 bit words. First the upper 8 bits of a word are written into buEFer memory and then the lower 8 bits and the two parity bits for each byte are written into buffer 123. This necessitates the upper byte parity register 147 which holds the parity of the upper byte until the lower 8 bits are written into memory buffer 123. The clock from AND gate 14~ also on bus 149 is used to increment the input counter 150 which is the address of the input buffer memory location which the data word is to be written into. The clock bus 149 is also -used to increment the worcl counter 1~1 whlch is use~l to tell llow many ~Yords have been put into the input buffer. TCU input bus line 1~0 also clrives a set of drivers at 1~3. Ihese drivers then drive a large bus 1~ which colmects to various decoding and logic units. The first byte Eollowing the sync character which has previously been discussed is the destination address. The destination address is compared in compare logic unit 160 against the TCU address switches 161. If the output of logic compare unit 160 is brought into the TCU test MUX 130 on line 162 and if the TCU address does compare, then this signifies that the message being received off the trunk is for this designated TCU and thus the rest of the message will be received.
If the output of compare unit 160 indicates that the message was not to this TCU, the ~CU will receive the rest of the header portion of the message to pick up the resync parameters which will be described later on.
This is necessary for the trunk contention scheme which is used.
The next byte of data whlch comes onto the input bus from drivers 143 is the function code. This f~mction code is loaded by the TCU sequencer into register 17Q. The outputs of 170 are then decoded b~ decoder 171 into the 8 ; ' '~`

," ~ '' , ' '' ' ' .
: , ~17()~;~g possible f mction decodes. lhe TCU sequencer looks not at each of the ~-mction codes individually, it looks at them in groups determined by whether data or an information field is to follow this header field or not.
The next two bytes following ~he function code are access code bytes.
They again come through drivers 1~3 and come into a compare network 181 on bus 1~0. The function of the access decoder is to match the access code switches 182, 183, 184 and 185 against the two access code bytes which are received from the trunk.
The access code switches 182 and 183 are connected through tr;-state buffer 186 to be used to compare against the Eirst access code whicll is received.
Access code switches 184 and 185 go through buffer 187 to the compa:re unit 181 to compare against the lower or second access code which is received from the trunk. Tf either of these compares of the two bytes are negative~ the TCU wlll not consider this message to be for it.
The next byte to be received off the trunk is the resync parameter which is loaded by the TCU sequencer into register 1~5. It is held there until the TCU has received the complete header portion of the message. If the header has been received with no errors, the output of the resync parameter register line 190 is then loaded by the TCU sequencer into the contention counter 191.
The next byte is the source address. The source address is loaded by the TCU sequencer into what is called the FROM register 192. This specifies the address of the TCU which has sent this message. Multiplexer ~MU~) 193 which is connected to the input bus during this receive operation has been connecting each byte of the received data on bus 194 into the FCS checker 120.
Following the source address, the next two bytes of data received in the message are the length count of the information field. The length count : .

. . ~

~'7~ 3 is specified as the number of 16 bit words which is contained in the infor-mation field follouing this header field. The input bus whicll now contains the length bytes connects through hlU~ 193 into the bus 19~ and finally into the length counter. The first byte of the length count is the upper length byte and this goes into counter L95 while the second byte of the length of count is loaded into counter 196. Both of these counters are controlled and loaded by TCU microcode. The output of the length counters is bro~htinto comparator 197 which determines whether the length counter is at zero. The output of comparator 198 is brought into the test MUX 130 and is used by the TCU microcode to deter-mine if an information field is to follow this header field because a lengthfield of zero is permitted.
The final two bytes within the header field are the FCS bytes for the header. As these bytes come in on bus L~ ancl go througl~ MUX :L93 and on ~ to bus 19~, they enter the FCS checker 120. After both PCS bytes have been ; clocked into the FCS checker, the output of the checker is brought into the TCU
test MUX. The output of FCS checker 120 is line 199. If the output of the checker indicates that the header has been received correctlyJ the TCU microcode will then load the resync parameter register 1~5 into the contention counter 191 as previously stated. It will also go on to accept any data field which may follow the header message.
If the TCU, upon receiving a message~ detects that the function code indicates that data is to be sent to the memory of the network access device, the TCU will request to connect up to the trunk control interface. After this connection is made, data from the input buffer is fed through tri-state drivers 205 to the bi-directional data bus 206 to the TCI. The bi-directional data bus 206 is an 18 bit path, 16 bits of data with two odd parity bits.
The purpose of the added sync bytes is to allow the receiving TCU

-: . .
- -:

:~'~73g time to reset the FCS generator checker and also to allow microcode control timefor housekeeping. The two sync bytes are no-t put into the buffer memory of the TCU.
FollotYlng the sync bytes which are stripped out by the receiving TCU, the data field which follows is enabled into the input buffer 121 and the information also flows through MUX 193 on to bus 194 and into the PCS checker 120. Thus, as the data is input into buffer 121, it is also being checked on checker 120.
The TCU sequencer monitors the output of the length counter 198 to determine when all of the data in the information field is receivccl. The TCU sequencer is also monitoring any error conditions wl~ich may be connected with the data transfer; it will abort the data transfer any time any of these abnormal conditions are ound. These error lines are lines 200 and 201. As ; the data information field is received in input buffer 121, the TCU sequencer is monitoring each byte and decrements the length counters through AND gate 202 which drives line 203 for each 16 bits of information field which are received.
For each 16 bits of data transferred to the TCI on bus 206, the output counter 207 is decremented. Thus the input counter 150, output counter 207 and word counter 151 are used to control the input buffer 121 in a circular manner.
After the length counter has counted down to zero indicating all of the data has been received, the TCU then must check the FCS characters for the received data field. This is done in a similar manner as checking the header FCS. Thus the two bytes following the data field come through MUX 193 onto bus 194 and into the FCS checker 12Q. After those two bytes are clocked intG checker 120, the output 199 indicates to the TCU microcode whether the data field has been received correctly. If during any portion of receiving the message the TCU has found an error condition, the TCU will terminate the 1~0~;39 transfer at that point and will transmit a hardware response message back to the sending TCU to indicate the status of the transfer cmd to convey as much in~or-mation about the error as possible. Assuming that the message has been received properly and the data has flowed from the TCU input buEfer 121 out through the bi-directional bus 206 through the TCI and then stored into the NA~ memory, the processor then interrogates the received message and will send back a response to the message received. Thus, this text will now describe how a message is transmitted back onto the data trunk.
Data comes from the memory of the NAD through the TCI bus 206 and into the TCU output buffer 210. This again is an lS bit wordJ 16 bits o~ data with two odd parity bits. The TCU sequencer handles setting up the transeer to the TCU which sent the original command message. The TCU sequencer brings up the signal send request line which is signal 211 telling the clata set to send a preamble onto the trunk. The serial parallel logic 103 is used to send all ones to the data set which is a marking condition on the trunk. When the data set 101 has sent this preamble, a signal clear to send line 212 is returned.
Clear to send line 212 informs the TCU sequencer that it may begin sending the message. The first byte of data to be sent out is the sync byte character.
This byte originates out of the PROM register 220. The output of register 220 is put on the TCU output bus 221 and is fed into the serial to parallel logic unit 103. This logic is also used as the parallel to serial logic and thus the sync byte which is loaded into the register is shifted out in serial fashion onto the send data line to the data set. Along with the send data signal line 213 the return clock line 214 is sent to the data set. This clock is generated in the TCU and is used by the data set 101 to determine the bit times of the data being sent.
The information which follo~s would now typically come from the NAD

,.. .

,~ ,~. . . - ~
-- - :

-/'V739 memory assuming this is a processor generated response. The data which has comefrom the TCI on bus 206 and w}lich was loaded into buffer 210 is now broken into eight bit bytes by the tri-state drivers at 225. Tri-state drivers 225 cause the upper ~ bits of the word from memory to be put on the TCU output bus 221 ~hile the output drivers 226 enable the lower 8 bits of ~he word from memory to be enabled onto the output bus 221. The first byte following the sync byte comes from the FROM register 192. The output of that register is connected to the output bus 221 and goes into the serial to parallel logic 103 and is sent serially to the data set 101. The output bus 221 is also connected through : 10 MUX 193 and onto bus 194 and into the FCS generator 120. '~lis log:Lc is now being used to generate the FCS for the header field which is belng sent.
The next byte of data EoLlowing the destination address which has come from the FROM register 192 is the response function byte. Ihis response function byte comes from the PROM register 220 and goes onto output bus 221 and again to logic 103 and out to the data set as well as going to the FCS
generator 120.
The next bytes to go out are the three status bytes, parameter 1, parameter 2, and parameter 3. These three status bytes are sent out as part of a response message.
The next byte of data following parameter 3 is the source address.
This comes from the TCU address register 161 and is enabled onto the output bus 221 and out to the data set.
Following the source address is the length field for the information field which is to be transmitted with this response message. A response message in which there is no data field will be discussed first. This is also called a hardware response which the TCU can generate independent of the rest of the NAD hardware. If the hardware response is to be sent, the length field is ... ~.. ~. ..... . .

3~

set to ~ero. The ~eros for the two bytes of length field come from the PROM
memory 220 and are enabled to bus 221 through the interface logic 103 and out to the data set. Following the length field is the FCS for the header field.
The two bytes of FCS are enabled onto the output bus from lines 230 and 231 ontobus 221 and through the interface logic 103 and out to the data set 101.
Following the FCS, assuming this was a hardware responseJ there will be no data field but the TCU will send two sync bytes following the header FCS
characters. This is to allow the receiving TCU logic time to process the information before the control signals from the data set terminate the transfer.These two sync characters are enabled out of the PROM memory 220 and onto the output bus 221 and are sent to the data set.
Now assuming the case of a response coming from the proccssor, tho header field will be sont as described previously from the first sync byte through the source address. Ilowever, the length field will now come from the NAD memory through the TCI onto bus 206 and into the output buffer 210. The upper byte of the length field is enabled through drivers 225 to output bus 221 and is loaded into the interface logic 103 to be sent to the data set. The lower length byte i5 enabled through drivers 226 to output bus 221 and is sent through interface logic 103 to the data set. These two bytes of length field also are enabled through MUX 193 to the length counter 195 - 196 and to the FCS
generator 120.
Following the length field the TCU again enables the header FCS
characters ~rom the FCS generator 120, lines 230 and 231 onto the output bus 221 to send these header FCS characters to the data set. Following the FCS
characters the TCU again sends two sync characters which originate from PROM
memory 220 onto ~us 22I and onto the data set.
Follo~ing that the information field i5 transferred. Prior to that _., ~ ~'0'~'3g transfer the ~CS register 120 is reset to all ones in order to generate the FCS
for the data field. Data will now come from the TCI onto bus 206 into the output buffer 210. The upper bytes will then be enabled onto bus 221 by driver 225 while the lower byte will be enabled onto bus 221 by driver 226. As each ~ bit byte of data is enabled onto the output bus 221, it is strobed into the inter-face logic 103 and sent to the data set. This data also goes through ~X 193 and into the FCS generator at 120 to generate the FCS for the data. In addition, length co~mters 195 and 196 are decremented for each 16 bits of data which are sent out. The TCU microcode monitors the output of OR gate 197 which is in line 198 to determine when the proper amount of data has been completely transferred. When all of the data has been transferredJ the TCU sequencer will enable the data FCS characters from the FCS generator 120 onto lines 230 and 231 to output bus 221. These bytes will be sent to the clata sct through the serial parallel logic at 103.
As data is put onto the output bus 221 rom drivers 225 and 226, the parity bits from the output buffer are also enabled onto the bus 221. The parity checker 240 thus is checking the odd parity for each of the 8-bit bytes which come rom the NAD memory. The parity check 240 is run through an AND
gate 241 which allows the TCU microcode to check only those bytes coming from the NAD memory itsel. Eight-bit bytes of data which come internal to the TCU do not have parity appended to them and thus there is no parity on bus 221 at those times. Also AND gate 241 has an input which allows the disabling of the parity check or diagnostic purposes. The output o AND gate 241 is then clocked at register 242 and the clock of the reg;ster 242 is the same as the clock which loads the serial to parallel register in the interface logic 103.
Thus if there is a parity error on the TCU output bus for the data which is loaded into the serial parallel register, then register 242 will indicate a .". j .

. ~.. ,~ .. ,~.. .

' ~ ~ ,JO'~3'13 parity error ~Yhich is line 2Q0. This parity error line 200 then feeds back into the TCU sequencer test MUX. If an error is detected during the data transfer the transfer will be immediately terminated by the T~U sequencer.
The next kind o~ message to be discussed is a command message to be transmitted onto the data trunk. This involves USillg some logic whicl prevlous-ly has not been described. In this kind of message most of -the data to be sent is coming from the NAD memory. Thus the data comes from the TCI onto bus 206 and through the output buffer 210 and through drivers 225 and 226. The first word which comes from the TCI will contain the destination address and the function field to be sent through the data set 101.
The next 16-bit word of data which comes into the output buffer will also be transferred to bus 229 into the access code generator 243. The access code generator 243 is also colmected via bus 188 to tri-state drivers l86 ancl 187. These tri-s~a~e drivers enable the access code switches 182 and L83 onto bus 188 when the upper access code is to be generated and enables switches 184 and 185 onto bus 188 when the lower or second byte of the access code is to be generated. The output of the access code generator 243 is then enabled to bus 221 which is then sent out through the serial parallel logic 1~3 to the data set.
As before, all information which is put on the output bus 221 is also sent through MUX 193 and into the FCS generating logic 120, Following the two access code bytes the TCU supplies the resync parameter and the source address. The resync parameter is taken from the TCU
parameter switches 246 and is enabled through drivers 244 onto the output bus 221. The TCU parameter switches are on bus 248. The source address comes from the TCU address register 161 and is enabled onto bus 249 and through buffer 245 to the output bus 221. This indicates which TCU has sent out this message. The information field length are the next two bytes and they will come from the NAD

. .

. - .

.

i'7073S~

memory through bus 206 tilrough buffers 210, 225, 226 and out to the output bus 221. When the length fleld of the header is on the output bus 221 being loaded into the serial parallel logic 103, it also goes through MUX 193 on-to bus 194 and is loaded into the length co~mters 195 and 1~6.
Following the length field which specifies how many 16-bit words will be sent following this header, are the FCS characters for the header. These two bytes are enabled as discussed before out of the FCS generator 120 and through lines 230 and 231 onto the output bus 221. Also following the header FCS will be two sync bytes which come from the PROM register 220. Following the two sync bytes, the information field comes from the TCI ~hrough the output buffer 210 and onto bus 221. As the information is put on bus 221 cmd loacled into the serial parallel logic register 1O3J it also goes to the FlCS generator logicto generate the FCS code for the data field. As the information field i5 being transferred, the length counter is decremented one time for every 16 bits of data being sent out.- Thus, when the line 198, which indicates length counter has reached zero, is detected by the TCU sequencer, it signals that the end of the information field has been detected. The TCU will then enable the data FCS bytes from generator 120 onto the output bus 221.
Following the data FCS by~es, there are two sync bytes which originate from PROM memory 220 onto bus 221. These bytes conclude the data command message transfer.
The TCU sequencer is made up of 48 bits from PROM memory 124 and each of the first 40 of the bits out of the PROM are strobed into a holding register 250. The output of this holding register hold one instruction. The output is, in part, used to address the next instruction which is to be executed.
These bits are used to generate controls for which hardware signal is to be tested to make hardware decisions. The output is also used to generate strobes ,.~, . . .. ~ .
.

~'7~7~39 to clock various registers and to generate enables to enable various registers to the output bus, for example.
One additional input to drivers 225 and 226 is a line 251. This line comes from a decode of the holding register 250. It is used to select when data from memory is to be enabled onto the output bus 221.
Figure 4B relates to Figure 3B AND gate 141. This is a detailed drawing of the valid sync bit detected gate.
Figure 4A relates to Figure 3B and is a detailed drawing of the input holding register 123 and the drivers 143. Figure 4A also relates to Figure 3C which is the parity generator 146 on Figure 3C. The output pins shown in Figure 4A constitute bus 144 shown on Figures 3B and 3C. ~ND gate 260 shown in Figure 4A, is the gate not shown on the clock diagra~ 3C but is usecl to disable passing the parity bit to the input buffer 121 for cliagnostic purposes.
The inputs to the input holding register 123, shown in the detailed drawing 4A, are froln the serial to parallel shift register contained within the interface logic lQ3 shown in Figure 3B. The clock inputs to this holding register also come from that logic and are clocked by the byte clock. Register 123 converts the data from serial into parallel. The output of this register is ZO input to the AND gate in Figure 4B, which is a valid sync detected gate. This gate determines if the first byte in the message received is a valid beginning of a messag~. Parity is generated at gate 146 to be put on the TCU input bus.
Drivers 143 drive the TCU input bus.
Figures 5A and 5B describe par* of the logic contained within the serial to parallel interface logic box 103 shown in Figure 3B. Figure 5A shows register 300 in which Data Ready, one of the signals from the data set, indicates that data is being received from the trunk Thls register delays the Data Re~dy ~. :

. ' - ' ' .
' '` ' ' ~' -.
.

3t7;~9 signal a various nu~ber of clock times at the outputs of this chip to provide control signals. One of the outputs goes into AND/OR gate 306 via signal path 305. When Data Ready has been detected, path 305 will go low causing gate 306 to output a one ~Yhich causes the ring counter comprised of flip-flops 309, 310, 311 and 312 to be clearecl.
The flip-flops 309, 310, 311 and 312 comprise a ring counter which is used to develop a timing chain from which all of the clocks for the TCU are developed. As described before, when Data Ready comes into the register 300, line 305 goes low which causes line 308 to go high which also causes OR gate 313 to output a low. This causes the ring counter to c:lear causing all o the Q sides of the flip-flops to become logical ones. AND gates 315 ancl 316 are used to insure that the ring counters are properly set during start up in power up sequences. The output of flip-EIop 312 is fed back around to the i AND gate 306 on line 317. This signal line 317 is what :is used to complete the r:ing of the ring co~mter. When Data Ready is detected, a one signal is started - to shift ~hrough register 301.
AND gate 304 has as its inputs line 318, which is a Data Ready signal, and the output of inverter 302 which is a delayed Data Ready signal. The out-put of gate 304 causes a clear signal to be generated to all of the flip-flops in the ring counter thus insuring that upon Data Ready being detected the ring counter is cleared. The output line 320 from register 301 finally becomes a one after seven clock periods. This enables the upper AND gate 306A of gate 306 to be enabled. This stops the ring counter and it waits for the signal labelled "delayed first zero" to come in from another section of the serial to parallel logic unit. The "delayed first zero" signal starts the clock ~Yhich causes the TCU sequencer to be in byte sync with the data coming in from the trunk. This is necessary because the TCU sequencer tests and manipulates the data from the ` , 07;~

trunk on a real time basis~
Once the "delayed first zero" signal is detectecl, AND gate 306A is made forcing line 308 to be a zero forcing line 314 to be a one. I~is causes thering counter to start operating once more. As the Q output line 325 of flip-flop 309 goes to a one, this signal goes to AND/OR gate 326. This posi-tive going edge is fed back around and comes into the clock input of flip-flop 328. This sets the pulse width of the clock which is going to be generated out of inver-ters 330, 331 and 332. This clock also becomes one of the inputs to AND gate 333. Its output runs into flip-flop 334 whose Q output 335 r~ms through inverter 336 and is used to determine the pulse width of the Q output o:t flip-flop 334. Thus, after the rising pulse edge from flip-E].op 309, line 32~l causes all of the necessary clocks to be generated for the TCU sequencer. I.ike-wise, the rising edge of fl:ip-flop 309 pin six which is line 3~0 causes a similar sequence of events to happen. Therefore all the clocks for the TCU
sequencer are generated from the pulse edges of flip-flop 309.
The ring counter is operated by a 50 megahertz clock and is fed into the clock inputs via line 341. This causes an 80 nanosecond up and an 80 nanosecond down clock to appear on the output of flip-flop 312 on line 342. OR
gate 338 is used to generate a memory clock which is used to write data into the input buffer which is buffer 121 on Figure 3C. Inverter 337 on Figure 5B is used to strobe the test inputs from the test MUX 330 to determine the time when the test is taken.
Flip-flop 350 is used at the end of the receive sequence. After the data message has been received~ the data set stops sending serlal clock and sends only crystal clock. The flip-flop at 350 is used to force the ring counter into a reset state and to allow time for the switching to occur beore continuing to generate clocks which run the TCU sequencer.

--. .:
" , ` ' ~

` ~L1'~'1~'739 ~ igure 6A is a detail of the function register 170 shown on ~igure 3B. ~egister 170 is loaded from the TCU microcode signal line 371. ~e inputs to register 370 come from the rcu input bus 372 which is also the same as bus ~ on Figure 3B. The outputs of register 370 go to decoder 375. Decoder 375 decodes bits in the function code which relate to diagnostic ~unc-tions. These al_ low various parity generators to be disabled so that parity checkers within the TCU input bus line may be checked.
Output line 391 is the upper bit of function register 370 and is used to determine whether the message is a command message or a response message. If line 391 is a command message, its level should be zero to enable decoding of a function code. The function ield on a response message should contain only this upper bit and no function code should be decoded for a response message. rrhis i5 done by pin five of decoder 38~1 and p:in four of decoders 385 and 375 being connected to line 391. Decoder 38~ is used to decode functions which control the workings of the NAD processor and decoder 385 is used to decode functions which transfer data or control the TCU and TCI.
To prevent accidental or unauthorized control of the NAD processor, line 396, not enabled, going into decoder 38~ pin four is connected to a switch which is under lock and key which disables the decoder if it is not intended for the TCU to manipulate the NAD processor.
Decoder 385 is used to determine what sort of function the TCU is to perform. The output line 397 is a function which the TCU handles on its o~n and is a function which can be used to obtain status from the TCU ~hich has been addressed.
Function line 398 is a master clear function which is used to master clear the NAD processor. However this signal must go through AND gate 389 which again is connected with the enable switch.

,, ., . ~ ~ --- , - . - ~
': - - ' ` ' ` : , vlit;3~

Lines 399 and 400 along with line 401 out of AND gate 387 tell the TCU sequencer that the message received ls going to contain an informatioll field following the header. In this case, the TCU must connect up to the TCI in order to input that data into the NAD memory. AND gate 386 is used to disable the not Data Reacly condition at times when a lost data condition on ~he trunk is not checked. AND gate 383 is used to disable the TCU input bus parity bit.
This allows checking of the parity checker on the input to the TCU memory and thus this is a diagnostic feature which can be used to verify that the data path is functioning correctly.
The AND gates at 380, 381, 382 perform a similar E~mction as AND
gate 383 which was just explained. These gates are used to disable various parity bits in the input bus networks to ensure that the input bus Erom tlle TCU
all the way through to the NAD memory is functioning correctly and it is to be used with diagnostic tunctions to verify its correct operation.
Figures 7A, B, C, and D relate back to Figure 3C lnput buffers 121 and tri-state drivers 205 of the bi-directional data bus lines 206. The TCU
input bus 144 in drawing 3B comes into Figure 7A in the upper left-hand corner and goes into parity checker 410. This provides a parity check on the data between the point where it was formed into an 8-bit byte and where it is put into the memory. If a parity error is detected, A~D gate 436 will clock flip-flop 438 causing flip-flop 438 to set indicating a TCU input bus parity error.
This will also turn on LED 439 to give a visual indication.
The TCU input bus goes on from the parity generator to become inputs to the TCU input buffer which are RA~ memory chips 412, 414, 416, 4I8 ànd 420 located on Figures 7A and C. The upper byte of a 16-bit word is contained in chips 412 and 414 whereas the lower byte of a word is contained in chips 416 and 418. The two parity bits, one for the upper and one for the lower bit, , ;

~: ~ , ' ' 1:~ 70739 are contained in memory chip 420. Since both parity bits are contained in thesame memory, the parity for the upper byte is held in flip-flop 434 until the lower byte is written. The 8-bit input bus comes into these chips and memory is used to assemble 8-bit bytes into 16-bit words. The output of memory comes out to tri-state drivers at 422, 424, and 426 on Figures 7B and 7D. These tri-state drivers are turned on by the TCU when the TCU is sending data to the TCI.
These tri-state drivers correspond to Figure 3C driver 205. Line 206 on Figures 3C corresponds to the outputs of drivers 422, 424, and 426. The out-puts of drivers 422, 424 and 426 go ihrough two parity checkers, an upper parity check ~28 and a lower parity check 430. The outputs of thesc parity ; checkers go through OR gate 432. The output of gate 432 becom~s an input to flip-flop 440. If when the TCU is sending data to the TCI, a parity error is detected on the 16-bit bi-dlrectional bus, then the flip-flop 44a will be set indicating a parity error condi~ion. Driver 426 sends the upper byte and lower byte parity bits to the TCI as well as the control signal indicat ng to the TCI when the data is valid on line 450 on Figure 7D.
Figures8A and 8B show the controls for the TCU input buffer. Flip-flop 500 in Figure 8A is used to control the bi-directional data bus 206 between the TCU and TCI. This flip-flop is controlled by the clear to send signal from the data set. This signal is used such that when data is being received, the driver 205 is enabled to send data to the TCI. When a message is sent out, the clear to send line will be active and will cause the Q output of flip-flop 500 to be a zero. If fIip-flop 500 is reset, the drivers 205 are disabled and the TCI is engaged to send data on bus 206 to the TCU.
AND gate 504 has the memory clock as well as enable line 505 from the TCU sequencer as inputs. AND gate 504 allows the TCU sequencer to control what data bytes to put into memory. As stated before, there are two sync bytes between the header and the data field which are not used. Signal line 505 causes the TCU sequencer to delete these two characters from the message as it is stored in NAD memory.
The output of AND gate 50~ on line 532 goes to flip-flop 526, AND
gate 530 and flip-flop 520. Output line 532 i5 a cloc~ pulse signal and flip-flop 526 is a simple divide by two flip-flop which selects either writing to the upper 8-bits of the input buffer or writing to the lower 8-bits of the inputbuffer. AND gates 528 and 530 are used along with the outputs of flip-flop 526 to develop ~he write signals for the upper and lower parts of the buffer memory. As words are written into the buffer memory, the input control counter 514 is incremented. The input and output control co~mters 514 and 51~, res-pectively, go through MUX 522 and become the address lines Eor the '['Cll input buffer RAM memory chips. The ~J~ operates on an 80 n~nosecond period clock and thus the address is switched Erom the input counter to the output counter and back again every 80 nanoseconds. This allows a write into the buffer memory and a read out of the buffer memory all within a 160 nanosecond time period which is one byte time on the data trunk. For each word written, the input control counter is incremented and word counter 516 is also incremented.
The memory chips used in the input buffer are 16 words deep. Therefore the carry input of word counter 516 goes to flip-flop 520 and if 16 words of data are written into the buffer, then flip-flop 520 will be set which will cause a buffer overflow condition to be noted and LED 521 will light as well as sending out a signal indicating this error condition has occurred.
Typical operation would be that as data is put into the memory from the TCU, the TCI would be taking data out of the memory and thus the word counter would never increment up to 16 because the word counter will be decre-mented each time a 16-bit word is taken out of the buffer. OR gate 518 simply ... ~ .

:
",:

detects whether the word counter has reached zero. ~Vhen the word counter is equal to zero it means that no data is left in the TCU input buffer. TCU
diagnostic f~mctions are enabled only on the data portion of a transfer. If the TCU diagnostic functions consist of disabling the various parity generator~
along the TCU input bus on the header portion of the received message, the message would most likely be disregarded because of these induced errors, and thus flip-flop 506 along with AND gate 510 and inverter 508 are used to disable the decoding of the diagnostic portion until the data field part of the received message has been encountered.
Figures 9A, 9B, 9C and 9D all relate back to Figure 3A. These four figures comprise one part of the TCU sequencer. The instruction memory PROMs 124 are shown in Figures 9A and 9C. The outputs of PROM 124 shown in Figure 9A hold the next address portion of the instruction. Every instruction in the ~ TCU microcode has a next address field and every instruction within the micro-; code is a jump instruction. Each jump is a decision jump based on the output of test MUX 130 shown in Flgures 9B and 9D. Test MUX 130 shown on those two figures ' have hardware bits as inputs. The test MUX is controlled from the instruction memory 124 shown in Figure 9C. The outputs of the PROM memory control which one of the many hardware input bits will be selected to be tested within any one instruction.
The output line 550 of the test MUX is fed to the data input of fllp-flop 551. The clock into flip-flop 551 lS the test clock which is generated from the serial to parallel interface logic 103. This clock determines the time at which the b;t to be tested will be strobed. The output of flip-flop 551 becomes the low order address bit of the next instruction. The decision making capability of thls particular sequencer is determined by running the test bit as the lower order address bit and thus either the next address as :
:: ~ - ` , : - -.

~ ~ 7~

specified by the outputs of holding register 250 will have either a low order bit of 0 or 1 depending on the output of the test MUX.
The output of holding register 250 goes to parity check network 552 and this checks parity on the 8 bits of the next address field. The microcode is set up such that every 8 bits of instruction has an odd parity bit associatedwith it. In Figure 9C, the instruction memory 12~ also connects to register 555. The outputs of register 555 feed the parity check ~mit 556. This same scheme is repeated throughout the rest of the TCU sequencer logic.
Every instruction in the TCU microcode is a jump instruction. How-ever, in order to simply sequence through memory, the lower bit oE the current instruction address is brought out from line 124 into inverter 560. Line 561 brings that lower bit into the test MUX. The instruction memory which selects the test MUX may now test the lowest order bit oE the current instrllction and the assembler puts the proper bit in that instruction so that the next sequential instruction will be~executed. The assembler takes care of putting in the proper next address in the instruction memory 124 as shown in Figure 9A. By using the low order bit, sequential operation through memory occurs, although the logic of the microcode is actually testing the low order bit.
Lines 565, 566, 567, 568 in Figure 9C and line 580 on Figure 10A
go to enable one of the five test MUXs. Lines 570, 571 and 572 are then used to select which one of the eight input signals to the selected MUX will become the output of the test MVX. One signal out of all of the input signals to the test MUX becomes the input to flip-flop 551.
Referring now to Figures 10A, 10B, 10C and 10D, the instruction memory 124 shown on Figures 10A and 10C has its outputs connected to the holdingregisters 250.- The outputs of the holding registers are two parity checkers.
A parity bit is associated with each of these two 8-bit bytes. From the outputs : ~: ~. : ' ' :

~ 1`70'739 of the holding register) the bits go toidecoders shown on Figures lOB and lOD.
The decoders are used to select various registers within the TCU logic and to provide various clock and strobe processes to other registers. All of these decoders provide the interface between the microcode anclthe hardware. ~n FigurelOB flip-flop 610 is used to enable the length counters to count after they havebeen loaded. The length counter is shown in Figure 3C at 195 and 196. Line 615 out of decoder 604 is used to clear the FCS reglster 120 shown on Figure 3C. The FCS register needs to be set to one before any information is run through the register. The signal line 616 ~rom decoder 604 is connected to the TCI and is used to provide theinterrup number which the TCU sends to the TCI
at the end of an operation. Signal line 617 loads a status register rom tlle TCU into the TCI. Line 618 loads the FROM register 192 shown on ~gure 3C.
Signal line 619 is used to load the resync register 145 shown on Figure 3~.
Line 620 loads the r&sync counter and is shown on Figure 3C. Signal line 621 is used to reset the input and output word counters in the input bufer memory 150, 207 and 151 in Figure 3C. Signal line 622 is not used. Signal line 623 loads the upper length counter 195 shown on Figure 3C. Signal line 624 loads the lower byte in length counter 196. Signal line 625 enables the TCU address switches 161 onto the TCU output bus. Signal line 626 enables the access code onto the output bus 243. Signal line 627 enables the resync parameter switches 246 onto the TCU output bus. Signal line 628 enables the PROM memory onto the output bus.
Signal line 629 enables the upper or first 8 bits of the FCS onto the TCU output ~us and this is shown on Figure 3C as an input to logic block 120.
Signal line 630 is an input to logic block 120 which enables the second or lower byte o the FCS onto the TCU output bus. Signal line 64n enables 8 bits of status information onto the TCU output bus to be sent to the data trunk.

. ~

Signal line 641 enables -the TCU address register to be enabled on-to the outputbus to be sent to the data trunk. Signal line 643 also enables an ~ bit byte of status onto the output bus to be sent to the trwlk.
Signal line 649 from decoder 606 is used to decrement the length counters 1~5 and 1~6 shown on Figure 3C. Signal line 650 is used to clear the latch register which holds various hardware bits which control transmitting and receiving of data. The latch bits will be explained later on in more detail.
The signal line 651 is used in conjunction with the error address register as a clock signal to load the TCU microcode address which has detected an abnormal condition into the error address register. The error address regls-ter contains the microcode address which has detected thc abnormal condition.
This provides a trace mechanism in tracing errors.
Signal line 652 is a clock signal which resets a timer mechanism which the TCU microcode uses to timeout various events. The timer operates erom a reset condition. The timer has four time interval lines which the TCU micro-code samples to deter~ine when a certain amount of time has elasped from the time the timer reset.
Signal line 653 loads the function register 170 shown on Figure 3B.
Signal lines 654, 655, and 660 are used to convey status information from the TCU to the TCI. Signal lines 673, 672 and 671 are used to control the PROM
memory shown on Figure 3D. These lines are used to select one of three differentbytes which can be selected from the PROM memory onto the TCU output bus~ Signalline 674 is the output used to select which of the switches to be gated onto the access code bus 188 to be used for either comparing access codes or for generating access codes. Line 674 is sho~n on Figure 3B and is an input to buffer 186.
Signa} line 675 is used to enable the TCU output bus to the TCI in - 35 _ - ' . '' '~ `
~; ~

order to send status information to the TCI. Thus, this signal is used along with signal lines 654, 655 and 660 to convey status to the TCI. Signal line 676 is used to enable tri-state drivers 225 and 226 to put data onto the output bus of the TCU.
Figures llA, 11~ and llC detail the TCU sequencer, more specifically, the instruction memory, the holding register and the addressable latch system.
The instruction memory again is shown as 124 on Figures llA and llC. The out-puts of the instruction memory are held in holding register 250. The output lines of -the holding register from Figure llA goes to Figure llB where these outputs are used to control the setting and clearing of the addressable latch shown in llB. The addressable latch has two sections 700 and 701. The outputs of this addressable latch are control signals to other logic in the TCU which the TCU microcode cannot control at every instruction cycle so these bits are stored in thc latch.
The first bit out of addressable latch 700 which is signal 702 is the send request. This is a signal sent to the data set telling the data set that the TCU is requesting to send a message and asking the data set to send a preamble o~ ones onto the data trunk. In response, the data set sends a clear to send signal.
The signal line 703 is a transmit request signal sent to the TCI
requesting that the TCI connect to the TCU in order to do a transmit. This signal is brought up in response to the TCU detecting a signal from the TCI say-ing that the TCI has a message to transmit to this TCU trunk. Signal line 704 is also used during a transmit and enables a write timing chain in the TCU
hardware which sends out an 8-bit byte which loads every 160 nanoseconds into the parallel to serial register. The timing chain provides all the timing to correctl~ load the by~es as needed. The flag slgnal line 705 is an internal ~:
:-.

' .

:~'70~39 signal used by the TCU microcode. The TCU microcode can set this bit and then test it. This is a substitute for subroutining capabilities so that the micro-code can decide which of two paths the microcode should take when coming out oE
a common routine. It is also used to indicate certain error conditions within the microcode. Signal line 706 is the not received request and is similar to signal line 703 in that it is sent to the TCI. This signal requests the TCI
to connect to it because this TCU is receiving a message from the trunk and wants to send forward that received message to the NAD memory.
Signal line 707 is used by the TCU microcode to enable the message being received ~o be recorded into the TCU input buffer memory 121. This line 707 is shown coming into AND gate 1~8 on Figure 3C. It also is used to control the clock going into the FCS generator checker, also shown on Figure 3C. Signal line 708 is used to enable a master clear function to the TCI when a master clear ~unction is the unction comm~md received in a message. Signal line 709 is a status bit which is set when an illegal function command has been detected in a received message. Thus, status gets sent back as part of the response message indicating to the sender that the function to be executed cannot be executed. Signal lines 710 and 711 are controlled by microcode during diagnos-tic functions. They are used to enable data to be looped back from the output bus to the input bus and back into the TCI. Signal line 712 is a status bit indicating that the TCU microcode has determined that the received message has an FCS error in it. Signal line 713 is another internal flag signal or indica~or signal to the microcode which tells the microcode whether it is doing a transmit sequence or whether it is doing a receive sequence. Line 713 is used to decide which path to take once a microcode instruction comes out of a common routine and this acts as a su~stitute for subroutine functions.

.

- , .
'' .

Signal lines 714 and 715 are used to control the transmitting o~`
data from the TCU output buffer to the TCU output bus. LED 7~l0 connected to latch 701 is used as an idle indicator. When the L~D is on, the microcode is in its idle loop. The TCU microcode will shut the LED off whenever -the micro-code leaves that loop.
Inverter 741 and ~D gates 742 and 743 are used to write information into either addressable latch 700 or addressable latch 701. There is a clock input into gates 742 and 743. The other two inputs to gates 742 and 743 control which of the latches will be written into. Lines 747, 7~8, 749 and 750 control which of the 8 bits will be written and whether the bit will be set or cleared in the addressable latch. The holding reg:ister shown in Figure llC simply holds all oE the parity bits for the instruction memory. ~11 o~ the parity bits ~or the instruction memory are held in that holding register.
Flip-flop 760 is used when a lK instruction memory is used. The TCU
will either accept a 512 bit instruction or a lK instruction memory. If a lK
instruction memory is used, this flip-flop will provide the needecl extra address bit to utilize the lK capability for that particular PROM.
In Figure llA, the address register sections 1, 2, and 3 are used to delay the address which is addressing the instruction memory. The outputs of address register section 2 go to the inputs of the TCU error address register.
If an error is detected, the microcode will load the microcode address which detected the abnormal condition.
~ eferring now to Figures 12A, 12B, 12C, 12D and 12E, the trunk con-trol interface is shown on the first four mentioned figures while the universal device interface corresponding to device interface 40 in Figure 1 is shown on Figure 12E. In each of the figures reference numeral 32 is used to denote the internal neh~ork access device data trunk as shown in Figure 1. Rx refers to ..... . .
:` ~, - ' . ' . ' ' ., . . '`.' ' .
.
:, 3g Teceive data while Tx refers to transmit data.
Referring now particularly to Figure 12A, the Rx data buffer 800 receives information from the TCU/TCI bus labelled 801 on this figure. This mechanism synchronizes the connected TCU and NAD memory using buffer registers and the control logic for these buffers or the microcode instruction loop. Rx data buffer two 802 serves as a control package mechanism to interlock the Tx and Rx commands. The TCI request word is controlled by the microprocessor Rx program. The Tx enabled bit, bit 12 and this word, interlock the Tx request word. The TCI microcode forms the interlock. The processor program rules are that the Rx program only changes the request bits in the TCI request word and - the Tx program only changes the request bits itl the TX request word. ~le Rx parameter and the Tx parameter are thereEore also controlled e~clusively by the appropriate processor program.
Referring now to ~'igure l~B, the memory data register 803 is a hardware mechanism interlocking the control package TCU Rx and Tx enables. The hardware locks out any Tx enables to TCUs not enabled to receive. This eliminates the problem where two network devices want to transmit to each other and do not want to or forget to permit a receive command. This relates to the rule of the NAD that you must establish a listening return path if transmission is desired.
The mechanism of allowing or requesting more than one TCU to transmit the message means that the first TCU that gets a data trunk will transmit the message. Redundant data trunks or do not care which trunk or which user and other commands will allow the work to be accepted and accomplished. A multiplex switch 804 provides one input to register 803. This multiplex switch forms a mechanism to hold up or to have the TCU wait for the microprocessor to generate a response for another message. This mechanism also allows the TCI to generate responses such as for autodump and diagnostic loop back functions.

-'' ' . ' - ~ .

-~1'7()''~3g ~ eferring again to Figure 12A, the first and second Rx data buffers 800 and 802, respectively, receive data from the trunk control unit on trunk control unit bus 801. Buffer register 800 receives data which is passed through buffer 802 in a resynchroni~ation process. Thus, register 802 receives data from the trunk control unit through the first buffer register 800. The contents of the first register 800 are immediately loaded into the second register 802 for transfer to memory.
Referring now to Figure 12B~ memory write data register 803 holds data to be written into the network access device memory 36 as shown in Figure 1.
Multiplexer 804 provides one input to the write data register 803. This multi-plexer passes the parity bits received from the Rx buEEer register 802 to tlle write data register 803 or in the case of TCI data generated internally, multl-plexer 804 connects the parity bits generated by the parity generate check logic unit 805 to the write data register 803.
Referring again to Figure 12AI Tx data buffer 806 holds data to be transferred to the TCU for transmission. This register performs part of the resync and buffering functions between the NAD memory and the TCU transmit operation. The output of the Tx data buffer 806 is connected through the bi-directional trunk 801.
2~ Referring again to Figure 12B, the read data register 807 catches and holds data received from the NAD memory for internal use in the TCI or for transfer to the Tx data buffer 806 for a TCU data transmit operation.
Multiplexer 808 passes on the parity bits from the read data register 807 to the Tx data register 806, or in the case of TCI internally generated data, it connects the parity generate check logic unit 805 to the Tx data register 806 in order to attach proper parity bits to the TCI generated data.
The parity check and generate logic unit 805 checks parity on .

'73~3 data received from the TCU or read from NAD memory. In the case of the TCI
sending status information or data to the NAD memory or to the TCU, this logic generates the proper parity bi.ts :Eor the data or status information to be sent.
~ lultiplexer 810 connects the parity bits from the TCU Rx data buffer 802 or the read data register 807 to the parity check logic input in order to perform the proper parity checks. Multiplexer 810 also conditions the parity check generate logic to enable it to generate the proper parit~ bits for TCI
internally generated data. Registers 812, 814 and 816 are status registers which are loaded by the connected TCU in order to pass on the status information genera~ed by the TCU to NAD memory. Control flag register 818 pert`ornls the resynchronization and latch f~mction required by the TCI to present stable data to the parity check generate logic ~mlt 805 and to the unlversal devlce interPace microsequencer test logic. The trunk cantrol lnterface status loglc 820 is a tri-state bus driver to connect the TCI internal status information to the control flag reglster 818 input.
TCU interrup register 822 is loaded by the connected TCU in order to inform the TCI of the results of the operation which was performed. The code loaded into this register is also stored into the NAD memory as status information.
The TCI test unit 824 is a tri-state bus driver to connect the internal operating status for the trunk and control interface to the control flag register 818.
The TCU control latch logic 830 is a mechanism by which the trunk control inter-face passes on control and status information on bus 831 to the connected TCU
on a TCU status bus 832 shown in Figure 12A. The RX enable and write request logic unit 834 shown in Figure 12B perform the mask function of allo~ing only the receive enabled TCU to be requested to output data to a trunk. This logic also latches and holds the request until a TCU connects to the TCI.

~ - 41 -.
; -{~35~

The TCU priority and connect logic unit 836 performs con-tention resolution on a request by two or more TCUs to connect at the same time to the TCI. T~e logic to mask out unselected TCUs or TCUs not enabled is also perEormed in this unit. BufEers 800, 802 and 806 perform certain logic functions in connection with the data transfer sequence used by the TCI. A waiting flip-flop disables the low clock to the device interface register. ~Yhen the clock is disabled, the data transfer instruction does nothing because the low clock signal is blocked to inhibit the generation of clock signals for the NAD memory request, the length counter and address counters thus preventing the data transfer to or from a TCU Tx or Rx data buffer.
Referring now to Figure 12E which contai.ns the universaL clevice illter--face or device interface 40 as shown in Figure 1, the tri-state transmitters to the net~ork access device address ~us 850 are shown connected to bus 32. 'Ihe acldress counter function for the NAD memory addressing is performed by address counter 852. Similarly, length counter 854 counts the length of the data message sent. Multiplexer 856 is selected to allow the address or length counter 852 or 854, respectively, to be connected to the bus 32.
The assemble/disassemble register 860 is used by the TCI for testing of bits, temporary storage, etc. It is not used for the purpose of assembling and disassembling but this type of register is required for this function.
Length counter 854 is used to decrement from a predetermined starting number to determine the length of a data transmit operation or the buffer size limit on an input or receive operation. nle shift network 862 permits a shift of 0, 4, 8 or 12 places on data passing through it. The bit set/clear flip-flop 864 is used to allo~ the setting or clearing of bits 8 through 15 from trans-ferring data into a register.
Tri-state transmitter 866 is used to connect the file register 868 ,~ `
.

:~ . ~ .-) 73A9 to data bus 32. The file register may be a 16 word by 16 bit -file register to store operat;ng parameters and status information. The test multiplexer 870 is used to permit the testing of the contents of the register which is then currently enabled into bus 32.
PROM transmitter 872 is used by the TCI to force bits O through 7 on bus 32 to zeros or ones when PROM data is selected to the bus bits 8 through 15. This is to avoid interference on the bus. Thus, the other section of transmitter 872 relating to bits 8 through 15 connects PROM data from PROM 874 to bus 32.
A microsequencer 876 generates addresses, and contains a data stack for fabricating microcode subroutines c~nd also functions as a test mechanism ~or performing conditional branches. The PROM 874 is a programmable read only memory for storing control programs.
Address latch 878 is an addressable latch for use as required by the programming. The go, stop and master clear functions are permanently assigned to latch 878. The remainder of the latch is not used by the TCI. Clock logic unit 880 is a register clock to determine which register data on the bus 32 is to be loaded into. Clock unit 882 generates address and length counter clock signals and permits parallel operation with other register clock signals. The bus select logic unit 884 determines which register or data is to be enabled into 32. Clock unit 886 is a register clock source. This completes the specific description of hardware elements. The operation of a NAD according to the present invention will now be described.
T~e NAD bus 32 in Figure 1 is an interconnect link between the various elements of the NAD. Attachments to bus 32 include the trunk control interface 30, the NAD processor 34, the device interface 40, the memory 36 and the maintenance interface 38. Use of bus 32 is divided equally among the three . .

:
, 7~3 active elements: the TCI, processor 34 and the device interface 4~. Bus access is by time division multiplex with equal access guaranteed for all elements. By way of example, a system according to tlle present invention may operate on a 320 nanosecond time frame with 106.6 nanosecond apportioned to each device. Thus within its access time slot, the appropriate active element can access any bus address.
Referring now to the drawing figures, the following symbols are used on various signal lines to denote the following functions. The minus M/C
signal indicates that a master clear function was received by a TCU which is enabled to control the NAD, or the TCI generated a master clear to the TCU.
The minus Rx Data Ready signal loads data from the connected TCU input data buffer into the first TCI input data buffer. The minus TCU Tx Buffer Empty signal informs the TCI that the connected TCU ou~put data buffer can receive data.
The Interrupt/Status Enable signal specifies the interrupt sent to the TCI as follo~s: interrupt zero is an abnormal end Rx command~ interrupt one is an abnormal end Rx sequence, interrupt two is an abnormal end Tx sequence, interrupt three is an end of Rx command, interrwpt four is an end of Rx sequence, interrupt five is an end of Tx sequence and interrupt six is a stream mode time out warning.
The minus load INT signal latches the three TCU encoded interrupt lines into the TCI interrupt register. The minus status CLK0 signal latches TCU status information into the upper 8 bits of the TCI status one register.
The minus status CLKl s;gnal latches the TCU error address into the lower 8 bits of the TCI status one register. The minus status CLK2 signal latches TCU status information into the TCI status t~o reg~ster.
The minus disable data bus Tx reeister parity check signal, when active, disables checking parity on data the TCI received from the connected ,:

3~

TCU. The minus TCU Rx request signal indicates the requesting TCU has received a header message containing the proper TO address c~ld access code fields and is requesting to be connected to the TCI. The min-ls TCll Tx request signal indicates that the TCll time slot has come up while the TCI T~ request line was active and the TCU data set has captured the data tr~k. The TCU
length or word count not equal to zero signal provides the TCI with a live status of the connected TCU input buffer condition. The minus TCI Tx request signal indicates that the TCI wants to transmit a message to the trunk or perform a processor initiated diagnostic on the TCU receiving the signal. The minus TCU connected signal indicates that this TCU is logically connected to the TCI. Only one TCU may be connected at a time to a TCI. The minus TC[ Rx Buffer Enpty signal tells the TCU that the TCI first input bufer can receive data. The mi.nus Tx Data Ready signal loads the TCU output bu~fer wi-th datcl.
Referring now to Pigures 3E and 3~ the message field de:Finitions will be discussed in detail. The TO address field is the first 8 bit byte following the synchronization character in the header field. This field defines the logical TCU on the trunk to which the message is directed. Each TCU on the trunk receiving a message compares this field with its own 8 bit logical address. If they match, the TCU will process the remainder of the header field.
If the fields do not match, the TCU does not process the remainder of the header field except to input it to its frame checking ~FCS) logic. After receiving the complete header field, the TCU tests the results of the PCS logic to determine if the message was received error free. If no errors occurred, and the message was a command messageJ the TCU will load the received resync parameter into its resync counter. If an error was detected the message is ignored.

.
.

, . ^ - - , .
'' , ~ . ~
.
- . . ' :

The f~mction field is the second byte following the sync character.
The function field has four subfields: response command frame, enable TCU
trunk diagnostics, trunk diagnostic functions and command functions. In all cases the TO address and the header frame check test must be correct before any part of the function field is executed.
The command functions are used by the TCU/TCI to control the data link~ The command codes are: O is resync, 1 is master clear, 2 is data command, 3 is enable TCI trunk diagnostic command, 4 is autoload, 5 is autodump, 6 is go and 7 is s~ep. The length parameters must equal O for command codes 0, lj 6, and 7~ An~ data sent with these commands will be lost~ The TCU must be enabled b~ the NAD control switch to process commands 1, 4, 5, 6 and 7.
The resync command code is 0. This command is basically a NOP
function which can be used to get the hardware status o~ the TCU/NAD on the clata trunk. The resync parameter field value is lnserted by the transmittin~ TCU
hardware. The only action taken by the TCU in response to this command is to load the received resync parameter into its resync counter and to transmit a hardware status response message.
The master clear command code is 1. When this command is received, the TCU tests the enable NAD control sianal which is switch selectable. If the TCU is not enabled to control the NAD, the TCU will perform a resync command and will return illegal function status in the hardware response. If the TCU
is enabled to control the NAD, and the header FCS has been verified, the TCU
will activate the M/C ~master clear~ line to the TCI for two instruction cycles.
The M/C line is bi-directional, connecting all four TCUs and the TCI. This line ma~ be activated by the TCI or any o~ the TCUs in order to initiate a master clear function. Each TC~ receiving the M/C signal compares with the master clear command decode. This is to prevent the TCU which initiated a ~46-.
, . .
~ . ' ' 3~

master clear command to a trlmk from master clearing itself and being unable to generate a response message to the command. The response message to a master clear command is transm;tted after the TCU sends the master clear signal to the TCI~ If the TCI is connected at that time, a processor response will be sent or otherwise the TCU will send a harclware response~
IVhen a TCU detects the master clear signal, it will execute its msster clear microcode sequence and will then wait for a predetermined time to re-ceive a command message with which to resync itself with normal trunk operations.
If no message is received in this predetermined time, the TCU will send out a trunk resync message and return to its normal idle loop functlon.
After a master clear, the TCI will accept only the GO, autoload or autodump commands from the connected TCU.
~ hen multiple TCUs in a NAD are enabled to control the NAD processor, the last TCU which sent a master clear to the TCI will be the onl~ TCU through which the GO, autoload and autodump commands will be accepted. Sending, simultaneously, master clear commands to multiple TCUs on a N~D is an illegal s~stem ~unction which must be avoided. If one TCU sends a master clear and starts an autoload sequence, there is no way to prevent another TCU from master clearing the first. The first autoload sequence being halted will be retried 2~ and then halt the second autoload sequence, etc.
The data command code is 2. The TCU will request to connect to the TCI after the TO address and access code have been received and checked. If the header FCS characters indicate that the header field contained an error, the TCU will withdraw its connect request to the TCI and will ignore the message.
~f the TCI is already connected to the TCU, the TCU will send status to the TCI ' containing the FCS error status followed by an abnormal end of Rx command in- -terrupt. The TCU will wait ~or the data set to drop the channel active signal . .

:. ' - , :

- . : .

'0'7~3 before returning to its idle mode.
If a TCll successfull~ connects to the TCI and the header is Okay, the header and data fields including all FCS characters will be stored into the NAD memory starting at the address assigned by the processor. After the TCU has received all the data from the trunk, it will capture the trunk and wait for a predetermined period of time if not in the data s~reaming mode for the processor trunk control interface to prov~de a response message. The TCU
~ill send a hardware response if the processor does not provide one.
Any o the following conditions will terminate a data transfer re-sulting in data following the error being lost:
1. TCU connected signal drops out, 2. Modem Data Ready signal drops out beforc TCU data length countor equals 0, 3. TCU input bus parity error, 4. TCU/I'CI bus Rx parity error~

5. TCI bus parit~ error,

6~ TCI detected error, or

7. TC~ input buffer overflow.
If the TCU is unable to connect to the TCI, it will perform a resync function and the TCI not connected status will be sent in the hardware response.
The command code for the enaBle TC~ trunk diagnostics command is 3.
The recei~ing TCU need not be enabled to control the NAD in order to execute this command. The header length parame~er may be Q only if the diagnostic requires no data to be transferred to the TCI. All of the remaining TCU pro-cessing steps or this command are the same as for the GQ command. When the TCI decodes this command, it will then decode the TCI trunk diagnostic function .~= . ~, . - . . . . . .

, field and determine the diagnostic action to be performed. This is a micro-processor function and will not be descT~bed in detail.
The command code for the autoload command is 4. If the receiving TCU is not enabled to control the NAD, the TCU will perform a res~lc function and will return illegal function status in the hardware response. The TCU
should already be enabled to connect to the TCI due to a master clear command which must precede this command. The TC~ then loads the NAD memory starting at Q with the contents of the information field in this command message. The TCI discards the header and FCS fields. The number of 16 bit words loaded into memory is specified by the length parameters in the header field receIved for this command. A processor response is sènt by th0 TCU after the TCI in-activates the wait processor response signal. If another autoload command is received, the data is loaded ollowing the last word of the data from the pre-vious autoload command. The GO command or a processor running status signal will terminate the autoload sequence and disallow autoload commands.
The command code for the autodump command is 5. If the receiving TCU is not enabled to control the NAD, the TCU will perform a resync command and will return an illegal function status in the hardware response. If the TCU is enabled to control the NAD, the TCU will request to be connected to the TCI after the header FCS is verified. The TCI will send wait for processor response to the TCU, to prevent it, Erom sending a hardware response message immediately and will connect to the TCU. Once connected the TCI will input the header. The TCI sets up the data transfer from the NAD memory and will clear the wait for response signal. The TCU then transmits a processor re~
sponse followed b~ a data field. This response data field is the contents of the NAD memor~ starting at the address specified in the second word of the data field. The number of 16 bit words transferred is- specified by the first word ,, ~ ., ., :.... . . . . . :
- - : ~ : , -, . .
' ~ ' ' ' .' ~', :' ,' " ~ ,, ' "' ,-~.

of the data field of this command. The second word o~ the data defilles the starting address. The TCU will generate and send the FCS characters for the information field.
The G0 conunand code is 6. Ie the TCU is not enabled to control the NAD, the TCU will perform a resync command and will return illegal function status in the hardware response. If the TCU is enabled to control the NAD, the TCU will request to connect to the TCI after the header FCS is verified.
The TCr will pick the function field out of the header field being transferred and will decode the command coda field. Upon decoding a G0 command the TCI
~ill issue a go signal to the processor. The TCU will transmit a processor response message after the TCI inacti~at0s the wait processor response signal.
The TCr will decode and execute this co-nmand at any time. If the TCU is un-able to connect to tlle TCI, the TCU will per~orm a resync f-mction and wLIl transmit a hardware response message with the TC~ not connected status set.
The command code for the step command is 7. This is the same as the G0 com~and except the TCI issues step and G0 commands to the processor which cause the processor to execute a single instruction.
The access code field is 16 bits long and is contained in the third and fourth bytes of the header field. This field is processed as four indèpendent 4 bit groups. The TCU hardware modifies the access code when a command message is being transmittad. In general terms, the access code is a concatenation of switch selectable hardware bits and of processor generated software bits, although an all hardware or all software access code s~stem is possible.
To generate the access codeJ each 4 bit group is processed as follo~s. ~f any of the hardware bits associ~ated with a specific 4 bit group are non-0, the hardware bits will be sent as that 4 bit group o~ the access . 5 ' :. '' ~ : ' , 7 ;~ ~3 code. rf all the hardware bits for a group equal 0, the software bits will be sent as that 4 bit group of the access code. The TCU hardware compares the re-ceived access code field with its own switch selectable hardw~re access codc bits only on a command message.
In respons~ messages, the access code field bits in the header are used to send status information back with the response. When the TCU hardware checks the access code field, each ~ bit group is processed independently as follows. If an~ of the hardware bits in a 4 bit group of the receiving TCU
are non-O, the corresponding ~ bit group of the received access code must match the hardware bits~ If all the hardware bits of a group equal 0, the correspond-ing group in the received access code is a software access code which is not compared with the hardware bits. ~t i5 llp to the N~D processor to verify these software access codes.
The resync parameter field is the fifth byte of the header f:ield.
This field is inserted by the transmitting TCU hardware. The resync parameter is contained in the lower 5 bits of this field while the upper 3 bits are al-~ays zeros. After a TCU receives a command message and verifies the header FCS~ the TCU will load the resync counter with the S bit resync parameter re-ceived. The resync parameter is a switch selectable value for each TCU. Each TCU on a data trunk must have a uni~ue resync parameter whose value must not be greater than the number of TCUs on the trunk. This relates to the contention scheme used in this device. This field is valid only for command messages. In a response message this portion in the header is used to transfer st~tus infor-mation with the response.
The F~OM address~field is the sixth byte of the header field. The FROM address specifies the logical TCU which sent the message. For all messages the send~ng TCU logical address switch setting is the FRO~ address transmitted.

-~, ~.. .. ... .. .. ...

:- - , . .
:' ' ~ o~

~hen a command header ield is received, the FR0~ address is stored :in a re-gister. The contents of this register is then sent as the TO address parameter irl the response message.
The length field is the seventh and eighth bytes of the header field~
This field defines the number of 16 bit words ~hich are to be transferred in the informatlon field. The data FCS word is not included in this count. The seventh b~te of the header contains the high order :Length count while the eigh*h byte contains the low order length count.
The header FCS field is the ninth and tenth bytes of the header.
10 These bytes define the end of header field and are used to validate the correct reception of this f~eld. The ~CS used is a cyclic redundancy checklng algoritllm using the CCITT recommendation V.~l generator polynomial of x to the 16th plus x to the 12tll plus x to the 5th plus l. ~ 'rcu has its ~CS remainder reglster initialized to all ones before a message is transmitted or recelved. Each byte transmitted is premultiplied by x to the 16th and divided by the generator polynomial to obtain a remainder. The TCU transmits the complement of the final remainder. If the message is received without errors, the final FCS remainder in the recei~ing TCU is a predetermined number.
The data field is made up of two parts, the information $ield ~nd the in$ormation FCS.
The in$ormation (I) field is only present if the length fleld in the header is non-0. It contains the data which is transferred between higher level processes that exist in units attached to the trunk. Since the data length con-trol ls all contained in the header field, the I field consists of a variable number of bytes which are~code and character independent. The length of the I
field must be an even number of 8 blt bytes and a length of 0 is specifically per-mitted.

.
~ -52-: ~ , 7~3 The in~ormation frame check se~uence field ~s present only if the length field in the header is non-0. This field consists of 16 bits o~ frame checking which are generated from the contents of the I field in the same manner in which the header ~CS field is generated.
The TCU automaticall~ inserts and deletes two sync character bytes between the last bit of the header FCS and the ~irst bit of the information field. This is to allow the TCU time to reset its FCS registers to all ones before processing the information ~ield. These bytes are referred to as the trunk fill bytes. The TCU automatically sends two bytes at the end of each message to act as trunk ~ill bytes. This is required to allow the receiving TCU adequate time to receive the last byte of the message before thc trunk read~ signal goes inactive.
The trunk contention mechanism functions to elimin~te trunk con-tention situations by asslgning to each TCU, a spec~fic time interval when transmitting onto the trunk is permitted. Each TCU on the trunk is assigned a time interval by means of a hardware scanner which is divided into slots and subslots. There must be at least one slot ~or each TCU but additional sIots are permitted. One slot time must be greater than twice the total transmission line propagation delay. A TCU according to the present invention can be de-signed with a time slot which readily allo~s a 2,000 to 3,000 foot long coa~ial cable for the data network. Each TCU on a trunk is assigned a unique resync slot number and has its own resync counter which keeps the TCU approximately synchroni~ed with all other TCUs. When a TCU detects a command message on the tTunk, it stops clocking the resync counter and processes the header field.
~f the message was received correctl~ and the header FCS was correct, the TCU
sets its resync counter to the resync number o~ the TCU which sent the message.
The sender resync number is the resync parameter received in the command header ~...

: .
~ ' ' .

` 11.'7~73~

field. The ~CU rece~ving the message waits for the Data Ready signal from the data set to drop out while the other TCUs are Naiting ~or the channel act~ve signal from the data set to drop out. The Data Ready signal drops after the last bit of data while the data set has an internal wait for a predetermined time after the last data bit before dropping the channel active signal. When the Data ~eady signal drops, the TCU which accepted the message will send data bits of all ones down the data trunk until it can transmit the response message.
This keeps the channel active signal high for all the TCUs and prevents th~m from incrementing their resync counters. The channel active signal to the TCUs will drop out a predetermined time after the response message is sent, en-abling the TCU resync counters to count. From this point each TCU will incre-ment its resync counter once every predetermined time interval for as long as there is no message transmitted onto the data trunk. Since the clock of each TCU is not synchronized to all the other clocks, the TCUs would dri~t out of synchronism with one another if there was no message traffic or the data trunk for a period of time. To prevent this, each TCU also has a contention counter.
This counter is incremented each time the TCU reaches its slot time on the data trunk~ This counter is reset whenever a transmission is detected on the trunk.
W~en the counter reaches a predetermined count, the TCU sends a trunk resync message down the trunk to keep all the TCUs in synchronism.
A TCU may begin transmitting a command message only in the first predetermined small time interval portion of the trunk slot time. This predeter-mined small time interval may be approximately 10 percent of the entire slot time. Thus, all TCUs on the data trunk will see the trunk go active during the transmitting TCUs slot time. This will inhibit any TCU rom incrementing a re-sync counter l~thin the transmitting TCU slot time due to physical locations on the data trunk table.

;54-:
':

3~

This hardware scanner tec~n~que prov~des access to the data trunk for the TCUs on a rotating priority basis. This prevents any TCU from being locked out of the trunk. A contention channel system consistent with the pre-ceding description is explained in detail in our Unlted States Patent No.
4,199,661, issued April 22, 1980.
The hardware response status field is the status of the TCU, TCI
and processor which is returned in each response message transmitted. The hardware response status consists of three 8 bit bytes which represent three parameters which are sent as the third, fouTth and fifth bytes of the response header field.
The first parameter o~ the hardware response status Eleld has 8 bits which are represented as follows. The ~irst bit is set when a command m~ssage is received in which the f~mction field either has bit one set to enable TCU
diagnostics or the command function is to enable the TCI diagnostics.
The second bit is set when a parity error is detected on data being written into the TCU input buffer. This status is cleared by master clear or when the data set channel active signal is low. The third b:it is set when a parity error is detected on the TCU Tcr bus by the TCU. This status is cleared by master clear or when the data set channel active signal ls low.
~20 The third bit is set when a parity error is detected on data loaded into the TCU parallel to serial register. This bit is cleared by master clear OT when the data set channel active signal is low.
The ~ith bit is set if the TCU output buffer was empty when data ~as loaded into the parall~ to serial register and the length count was not zero.
The sixth bit ls set if the TCU input buffer word counter equals 15 when a word is written into the input buffer.

55~ -- ~17(~3S~

The seventh b~t is set whene~er the TCU detects an FCS error on either the header or information fields.
The eighth bit is set to zero if an abnormal condition is found by the TCU.
The second parameter of the hardware response data field has 8 bits which are defined as Eollows. The first bit is set when a TCU is unable to connect to the TCI.
The second bit is set by the TC~ to indicate it has detected an ab-normal condition and represents an error signal. Such conditions may include those where a data transfer is completed but the data bu~fer is eitller still full or not empt~.
The third bit is set when the processor has stopped.
The fourth bit is set when the processor has detected a memory parity error or when the processor is master cleared.
The fifth bit is set when the NAD control function is attempted through a TCU which is not enabled to execute a NAD control function or when the length field for a command function is incorrect or if the response bit of the function field is set in a command message received from the data trunk.
The sixth bit is set when the TCU data length counter or :Rx word counter is not equal to zero.
The seventh bit is set by the TC~ when it detects a parity error on the TCr Bus or data from the TCU during a Rx or on data from the NAD memory during a Rx sequence.
The eighth bit is set if the TC~ processor fails to provide a re-sponse message within a predetermined time of receiving a Rx command interrupt or if in t~e data streaming mode no response command message is provided within a predetermined time of receiving a ~x command/Tx sequence interrupt signal.

-56~

- . - , 1~.7ll';~

The third parame~er of the hardware response status field ~s Llsed if the TCU detects an a~normal condition. This 8 ~it byte shows the 8 ~its of the TCU sequencer address which detected the abnormal condition. The most significant bit of thc TCU error address is in bit 7 of the parameter 1 status.
If no abnormal condition has been found, this byte will be all Os.
There are six interrupt conditions which the TCU may send to the TCI to indicate that the TCU has completed an operation. The interrupts are defined as follows: abnormal end of Rx command - this interrupt indicates that the TCU detected an abnormal condition while receiving a command message. Ab-normal end of Rx sequence - this interrupt indicates the TCU detected an aborn-mal condition while transmitting a response message. ~normal end of Tx sequ-ence - this interrupt indicates that the TCU detected in abnormal conditions ~hile trcmsmitting a command message or receiving a response message. End of Rx command - this interrupt indicates that the TCU has completcd receiving an error free command message. End of Rx sequence - this interrupt indicates the TCU has completed transmitting an error free response message. End of Tx sequence - this interrupt indicates that TCU has completed transmitting an error free command message and received an error free response message. Stream mode time out warning - this interrupt indicates the processoT must provide a response message or Tx command within a predetermined time interval to prevent the TCU from sending a hardware response message or terminating the Tx command stream mode sequence.
The trunk resync message is initiated 'oy the TCU hardware in order to keep all of the TCUs on a trunk synchronized. Since this message is directed to all TCUs on the trunk, the TCU which transmits this message puts its own logical address into the TO address parameter ~ield. This prevents all of the TCUs receiv~ng this message from generating a response message.

. .. .

~ ' ' " " ' ~', ' . . ~ . ' ~ ~,'. . ' .

The strec~ mode is initiated by lligher level protocols within the NAD microprocessors to trans~er large blocks o~ data. The stream mode is the only trunk operation in which the trunk is not available to other TCUs between command response message frames. The trunk is dedicated to the two TCUs in stream mode ~mtil operation is completed or until an error is detected by either of the NADs.
When receiving a command message the TCU interrogates the TCI stream mode line only after sending the TCI end of Rx command interrupt. If the stream mode line is active, the TCU will capture the trunk by setting the send request and sending binary ones continuousl~ down the data trunk. If the processor does not supply a resonse message within a predetermined time interval of when the interrupt was sent, the TCU will send a stream mode time out warning interrupt to the TCI. If no response is recelved within a predetermined tlme interval of this interrupt, the TCU will send a hardware response to the originating TCU~
The originating TCU NAD processor should drop that TCU out of stream mode on receipt of the message. A processor stream mode error status and abnormal end of Rx sequence interrupt are sent to the processor which will terminate stream mode in the receiving TCU.
When receiving a response message the TCU interrogates the stream mode line onl~ after sending a Tx sequence interrupt to the TCI. If the stream mode line is active~ the TCU will capture the trunk and wait a predetermined time interval for a new Tx message ~rom the processor. A stream mode time out warning interrupt is sent to the TCI if a Tx message is not received within this Rredetermined time interval. If a Tx message is not received within a pre-determined time interval of this interrupt message, the TCU will release the trunk, that ls drop the send xequest signal, and will send a processor stream mode error status and abnormal end o~ Tx sequence interrupt to the TCI which : ' :..

::. . . :
- , ~ill terminate stream mode in the originating TCU. Releasing the t~lnk will cause the remote TCU to drop out of stream mode.
Since every microcode instruction is actually a jump instruction, a next address field is specified with each instruction. Sequential memory referencing is provided by using the current address as the hardware condition ~eing tested. The sequencer has a unique diagnostic feature called an error address register.
The TCU Microcode Sequencer performs four ~asic ~unctions.
1. It provided timed pulses to clock var~ous hardware registers.
2. ~t provided signals to trans~er data onto the internal hardware bus from various source registers.
3. ~t provides a latch mechanisnl to store program fla~s.
~ ~t provides a mechanism to perEorm conditional micrococlc jumps ~le-pendent on the condition Oe the speci~ic hardware condition being tested.
The sequencer has no data manipulation or program subroutine capa-bilities. The sequencer is constructed such that the least significant address bit ~LSB~ for the next address is dependent on the hardware condition being tested. ~f the hardware condition being tested is true, the LSB of the next address is forced to a logical one, if the condition being tested is false, the LSB of the next address is forced to a logical ~ero. Since every instruction is actually a jump instruction, a next address field is specified with each instruction. Sequential memory referencing is provided by using the LSB of the current address as the hardware condition being tested. The sequencer has a unique diagnostic feature called an error address register. This register is loaded by a field decoded from the microinstruction. The data loaded into th~s ~egister is the lQ~bits of the address of the instruction preceding the m struction containing the load command. This provides a unique and very in-..

.. , .. . ,: , - - -, 3~

form~t~ve pointer to each abnormal condition detected by the sequencer while u~ing a common error handling rout~ne~

-6Q~
;

,

Claims (19)

THE EMBODIMENTS OF THE INVENTION IN WHICH AN EXCLUSIVE
PROPERTY OR PRIVILEGE IS CLAIMED ARE DEFINED AS FOLLOWS:

1. A network access device adapted to be connected to a data trunk for transmitting and receiving messages from said data trunk and for interconnect-ing various computer devices to said data trunk, said network access device comprised of: a data set for receiving and transmitting data into and out of the network access device for connection to a data trunk, a trunk control unit connected to said data set for bi-directional communication into and out of said trunk and for transmitting at least first and second types of command messages and for receiving at least first and second types of response messages, a first type of command message being generated by said trunk control unit to indicate the status of said trunk control unit and a first type of response message being used by said trunk control unit to control the status of said trunk control unit, a trunk control interface connected to said trunk control unit and having means for connection with at least one additional trunk control unit for buffering of data transmitted to and received from said trunk control unit, said trunk control interface being responsive to control signals to respond to said trunk control unit in a selected function from a group of available functions, said available functions including receiving data from or trans-mitting data into said data trunk, a network access device internal bus con-nected to said trunk control interface, a network access device processor operating as a microcode sequencer and issuing output control signals connect-ed with said internal bus for controlling said trunk control interface and trunk control unit by generating addressed status and interrupt control signals to said trunk control interface and to said trunk control unit, said processor generating at least some of said addressed control signals in response to signals received from said trunk control interface and said trunk control unit, said processor also generating a second type of command message and receiving a second type of response message to control the network access device, a trunk control unit input bus connected to said trunk control unit and said data set to receive signals from said data set and which is accessed by a num-ber of tri-state drivers included in said trunk control unit each of which is controlled by said microcode sequencer logic and clock signals produced by said network access device processor and transferred by said trunk control interface to control access to said trunk control unit input bus at predeter-mined times according to said microcode sequence, an internal network access device memory connected with said internal bus, and a device interface con-nected with said internal bus for communication through said trunk control interface to said trunk control unit and to said data trunk through said data set and having an output device channel adapted for connection to an appropri-ate computer device.

2. The network access device of claim 1 wherein said trunk control inter-face is connected with a plurality of trunk control units each of which has an associated data set for connection to a data trunk.

3. The network access device of claim 1 wherein said device interface in-cludes a message counter-comparator and an address counter-comparator each of which is connected to receive signals from said network access device internal bus, each of which respectively compares by issuing a compare output signal the message length and address used with header information received on a command message on said internal bus to use in determining that the data message has been correctly received.

4. The network access device of claim 1 in which said trunk control unit includes an input holding register and an input buffer connected to said trunk control unit input bus, a plurality of tri-state drivers connected to said input buffers to drive an output bi-directional data bus connected with said trunk control interface, an input word counter connected with said input buffer, an output word counter connected with said input buffer wherein said counters are controlled by an input header portion of a command message rec-eived from said data trunk and decrement to zero as said message is supplied to said input buffer and out of said input buffer to said trunk control in-terface wherein a zero count is used to determine that a message has been fully transmitted.

5. The network access device of claim 4 wherein said trunk control unit is further comprised of internal latches responsive to said network access device processor to receive and store microcode instructions prior to a time when used and responsive to clock signals from said network access device processor to generate a microcode sequencing function to perform selected functions in a predetermined sequence.

6. The network access device of claim 4 wherein said trunk control unit is further comprised of logic means connected to said trunk control unit input bus for producing FCS (Frame Check Sequence) check characters to be sent in command messages in both a header portion and a data portion of said message in response to microcode latch instructions received from said network access device processor in sequence in response to clock signals.

7. The network access device of claim 1 wherein said trunk control in-terface includes a trunk control unit control latch for receiving status in-formation from said trunk control unit with respect to the mode of operation of said trunk control unit.

8. The network access device of claim 1 wherein said trunk control unit is further comprised of a function register, an internal trunk control unit input bus connected to receive signals from said data set and connected to said function register to provide the contents of said function register from said data set, a decoder receiving the contents of said function register and producing an output control signal, said function register and decoder being responsive to clocking signals from said network access device processor to selectively receive data from said trunk control unit input bus at a pre-determined time in a sequence of timed operations.

9. The network access device of claim 8 wherein said trunk control unit further comprises an input buffer connected to said trunk control unit input bus, an input buffer counter connected to said input buffer, means responsive to said counter to indicate when said buffer is either full or empty and logic means connected to said means responsive to said counter for sending an error signal on said data trunk in response to said trunk control unit buffer being full.

10. The network access device of claim 1 wherein said trunk control unit includes logic means for responding to said first type of command message re-ceived from said data set with a first type of response message sent to said data set indicating an error or a diagnostic within a predetermined time in the absence of second type of response message control of said trunk control unit by said network access device processor.

11. The network access device of claim 1 wherein said trunk control unit is comprised of: an instruction address holding register for holding each instruction address in a received message from said data set during execution by said network access device so that it is not lost, an error detection logic means connected to said instruction address holding register for detecting an error status in the trunk control unit, and means connected to said error .

detection logic means for sending a first type of command message to said data set indicating an error status in response to a signal from said error detection logic means, said message containing a portion which consists of the instruction address received from said instruction address holding register which resulted in the error status.

12. The network access device of claim 11 wherein said trunk control unit includes means for resynchronization with said data trunk including the trunk control unit generating said second type of command message in response to microcode instructions from said network access device internal processor as part of a predetermined microcode sequence of operations.

13. The network access device of claim 12 wherein said data set provides data in a serial mode to said trunk control unit and wherein said trunk control unit includes a serial to parallel interface logic unit connected to said trunk control unit internal bus and an input holding register wherein data is received in bit serial form and output in byte parallel form to said trunk control interface.

14. The network access device of claim 13 wherein said trunk control unit includes a plurality of tri-state drivers connected to said trunk control unit internal bus each of which is controlled by microcode sequence logic signals provided by said network access device internal processor to control access to said trunk control unit input bus at predetermined times.

15. The network access device of claim 1 wherein said trunk control interface includes a trunk control unit control latch for receiving status information from said trunk control unit with respect to the mode of operation of said trunk control unit.

16. A network access device comprised of: a data set adapted to be connect-ed to a data trunk, trunk control unit means connected to said data set for bi-directional communication into and out of said trunk and for transmitting first and second types of command messages and for receiving response messages, and wherein for each command message sent as the response to a received mes-sage, the command message provides status information about the network access device, a trunk control interface connected to said trunk control unit for buffering of data, said trunk control interface having means for connection to at least one additional trunk control unit, and wherein said trunk control interface includes a control latch for receiving status information from said trunk control unit with respect to the mode of operation of said trunk control unit, a network access device internal bus connected to said trunk control interface, a network access device microprocessor connected with said internal bus for controlling said trunk control interface and trunk control unit by generating addressed control signals to said trunk control interface and said time control unit, an internal network access device memory connected with said internal bus, and a device interface connected with said internal bus for communication through said trunk control interface to said trunk control unit and to said data network through said data set and having an output de-vice channel adapted for connection to an appropriate computer device.

17. The network access device of claim 16 wherein said trunk control unit is comprised of: an instruction address holding register for holding each instruction address in a received message from said data set during execution by said network access device so that it is not lost, an error detection logic means connected to said instruction address holding register for detecting an error status in the trunk control unit, and means connected to said error detection logic means for sending a first type of command message to said data set indicating an error status in response to a signal from said error de-tection logic means, said first type of command message containing a portion which consists of the instruction address received from said instruction address holding register which resulted in the error status.

18. The network access device of claim 17 wherein said trunk control unit includes a trunk control unit input bus connected to a plurality of tri-state drivers each of which is controlled by microcode sequence logic generated by said network access device microprocessor to control access to said trunk control unit input bus at predetermined times according to said microcode sequence, and wherein said trunk control unit includes at least one instruction holding register latch means connected to said input bus for holding microcode instructions from said processor received prior to the time of execution and which are latched until the time of execution according to said microcode sequence.

19. The network access device of claim 18 in which said trunk control unit includes an input buffer connected to said trunk control unit input bus, a plurality of output tri-state drivers connected to said input buffer an output bi-directional data bus connected with said trunk control interface and to said output tri-state drivers, an input word counter connected with said input buffer and an output word counter connected with said input buffer wherein said count-ers are controlled by an input header portion of a second type of command mes-sage and decrement to zero as said message is supplied to said input buffer and out of said input buffer to said trunk control interface wherein a zero count is used to determine that a message has been fully transmitted.