Note: Descriptions are shown in the official language in which they were submitted.
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
-- 1 --
,
'~ .~
'`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
- 6 -
"~
.
.~ . . .
' ' :
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
- 13 -
,~ .
~,` '
,
~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
- 14 -
.
.
- : . - . : .
~ ,' ' ' ' " -
,- , ' ' '
~ 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
- 15 -
; ' '~`
," ~ '' , ' '' ' '
.
: ,
~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
- 16 -
: .
. . ~
~'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
- 17 -
-
: . .
- -
:
:~'~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
- 18 - -
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
- 19 -
,.. .
,~ ,~. . . - ~
-
- - :
-
/'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
- 20 -
... ~.. ~. ..... . .
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
- 22 -
.". 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
- 23 -
. .
. - .
.
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
- 24 -
,.~, . . .. ~ .
.
~'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
- 26 -
` ,
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.
- 27 -
--
. .:
" , ` ' ~
` ~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.
28 -
,, ., . ~ ~ --
- , - . - ~
': - - ' ` ' ` : ,
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,
29 -
, ;
~: ~ , ' '
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
- 3Q -
39
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
... ~ .
:
",:
39
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
- 32 -
:
:: ~ - ` , : - -
.
~ ~ 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
- 33 -
: ~: ~. : ' '
:
~ 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.
- 34 -
. ~
739
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 _
- ' . ''
'~ `
~; ~
0739
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
- 36 -
~:
:-
.
'
.
:~'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.
- 37 -
.
- , .
''
.
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
- 38 -
..... . .
:` ~, - ' . ' . ' '
., . . '`.' ' .
.
:,
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.
- 39 -
-'' ' . '
- ~ .
-~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
- - 40 -
.
'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
-- - 42 -
,~ `
.
:~ . ~ .-
) 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
43 -
. .
:
,
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
- 44 -
,:
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.
- 45 -
.
.
, . ^ - - , .
''
,
~ . ~
.
- . . ' :
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
-48-
.~= . ~, . - . . . . . .
,
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
-49-
,, ~ ., ., :.... . . . . . :
- - : ~ : , -, . .
' ~ ' ' ' .' ~', :' ,'
" ~ ,, ' "' ,-~.
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.
-51-
-
~, ~.. .. ... .. .. ...
:- - , . .
:' '
~ 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
-53-
~...
: .
~ ' ' .
` 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.
-57-
. .. .
~ ' ' " " ' ~', '
. . ~ . ' ~ ~,'. . '
.
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
: '
-58-
:..
::. . . :
- ,
~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-
59-
..
.. , .. . ,: , - - -
,
3~
form~t~ve pointer to each abnormal condition detected by the sequencer while
u~ing a common error handling rout~ne~
-6Q~
;
,
