 |
Description  |
|
|
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to an asynchronous high-speed data interface for
processing serial data frames and, more particularly, to such an interface
for processing frames originating from a serial channel and destined for a
control unit having a parallel interface.
2. Description of the Related Art
The copending application of D. F. Casper, J. R. Flanagan, G. H. Miracle,
R. A. Neuner and P. L. Potvin, Ser. No. 07/392,754, entitled "Apparatus
for Interconnecting a Control Unit Having a Parallel Bus with a Channel
Having a Serial Link", and the copending application of M. E. Carey, G. H.
Miracle, J. T. Moyer, and R. A. Neuner, Ser. No. 07/392,629 entitled
"Channel and Extender Unit Operable with Byte Mode or Non-Byte Mode
Control Units", both owned by the assignee of this application and filed
on even date herewith, describe a fiber-optic-extended parallel channel
emulator. As described in those applications, the total extended channel
consists of a cooperating serial channel, associated with a host
processor, which is connected through a serial fiber-optic link to an
extender unit coupled to one or more parallel control units. The control
units in turn handle devices, especially direct-access storage devices
(DASD) such as magnetic disk drives. The serial protocols for
communicating over the fiber-optic link and the format of the serial
frames transmitted over the link are also described in the
above-identified copending application of D. F. Casper et al. The use of
the serial fiber-optic link between the serial channel and the extender
unit allows control units to be placed up to 3 km from the channel (1 km
in the case of certain time-critical control units), as contrasted with a
distance of about 400 feet for conventional parallel channels and control
units.
In the system described in the copending applications referred to above,
the channel and the extender unit coupled by the fiber-optic link are
timed by clocks which, although having the same nominal frequency, run
asynchronously with each other. In the extender unit, frames arriving from
the channel are received under the control of a clock that is synchronous
with the channel transmitter clock and are later processed under the
control of a clock that is used generally to time the extender unit logic
and is asynchronous with the channel transmitter clock. Such asynchronism
between the receiving of the serial frame and its later processing usually
requires that the entire frame be received in an input buffer and checked
for validity before the frame is further processed. This requirement
significantly limits the data transmission rate and may result in an input
buffer overrun if two consecutive frames are spaced two closely together.
Further, the necessity of receiving the entire frame in the input buffer
before proceeding with later processing increases the effective latency
period of the device connected to the control unit.
SUMMARY OF THE INVENTION
A principal object of the present invention is to provide a data interface
that handles data that is asynchronous with circuits that later process
the data.
A further object of the present invention is to provide a data interface
that is capable of high-speed operation without data overrun.
In general, the present invention contemplates an asynchronous data
interface for processing serial data frames, such as those originating
from a serial channel, transmitted in synchronism with a first clock in
which a first clocked logic circuit operating synchronously with the first
clock fills an input buffer with data from the frames. A second clocked
logic circuit operating synchronously with a second clock that is
asynchronous with the first clock begins emptying data from the buffer
before the first clocked logic circuit has completed its filling
operation.
More specifically, in the preferred form of the invention, the frames
comprise (1) a start-of-frame (SOF) delimiter (in particular a
passive-start-of-frame (PSOF) delimiter) (2) data-type characters
including one or more frame contents bytes and one or more cyclic
redundancy check (CRC) bytes, and (3) an end-of-frame (EOF) delimiter
which may be either a normal disconnect-end-of-frame (DEOF) delimiter or
an abort-end-of-frame (AEOF) delimiter. The first clocked logic circuit
begins to fill the input buffer in synchronism with the first clock upon
detecting an SOF delimiter and, optionally, other non-frame contents bytes
such as an architecture identifier (AID) or the like. Upon detecting the
receipt of a predetermined number of frame contents bytes, preferably
three, the first clocked logic circuit sets a start latch to signal the
second clocked logic circuit to begin emptying the data bytes from the
input buffer into an output buffer in synchronism with the second clock.
The second clocked logic circuit uses a pointer register to address the
output buffer. Upon detecting the setting of the start latch, and before
initiating the transfer of data from the input buffer to the output
buffer, the second clocked logic circuit stores the existing contents of
the pointer register in a backup pointer register. As the, second clocked
logic circuit transfers successive frame contents bytes from the input
buffer to the output buffer, it increments a backup byte counter used to
keep track of the number of bytes in the output buffer awaiting further
processing. The backup byte counter is readable only by the second clocked
logic circuit, and not by the logic circuit that further processes the
data in the output buffer.
Upon detecting the start of an EOF delimiter, the first clocked logic
circuit performs a CRC check and sets a pause latch, signaling the second
clocked logic circuit to halt temporarily the further transfer of data
from the input buffer to the output buffer. If the EOF delimiter is a
normal EOF delimiter, and if the CRC check is satisfactory, the first
clocked logic circuit sets a "good" latch, signaling the second logic
circuit to complete the transfer of the frame data from the input buffer
to the output buffer. On completion of the data transfer, the second
clocked logic circuit transfers the contents of the backup byte counter to
the principal byte counter that is readable by other logic circuitry.
On the other hand, if the EOF delimiter is found to be an abort EOF
delimiter, the first clocked logic circuit sets an abort latch, signaling
the second clocked logic circuit to abort the transfer sequence. In this
case, the second clocked logic circuit transfer the contents of the backup
pointer register to the principal pointer register, and transfers the
contents of the principal byte counter to the backup byte counter. Thus,
even though portions of the aborted frame have been transferred to the
output buffer, they are, in effect, invisible to the external circuitry
and will be overwritten when the next frame is received.
By providing this capability for disregarding the portion of an aborted
frame that has already been transferred from the input buffer, the present
invention permits the transfer of contents from the input buffer to the
output buffer before the incoming frame is completely received and checked
for validity. By delaying the transfer from the input buffer until a
predetermined number of incoming frame contents bytes have been received,
one ensures that the second clocked logic circuit will always have data in
the input buffer to transfer to the output buffer while the input buffer
is being filled.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a schematic block diagram of an extended channel incorporating an
interface constructed in accordance with the present invention.
FIG. 2 is a schematic block diagram of the extender unit of the extended
channel shown in FIG. 1.
FIGS. 3A and 3B are a schematic block diagram of the input buffer and
associated circuitry of the extender unit shown in FIG. 2.
FIG. 4 is a schematic block diagram of the latching circuitry associated
with the circuitry shown in FIG. 3.
FIG. 5 is a schematic block diagram of the data buffer pointer registers
associated with the data buffers shown generally in FIG. 2.
FIG. 6 is a schematic block diagram of the byte counters associated with
each of the data buffers shown generally in FIG. 2.
FIGS. 7A, 7B, 7C, and 7D are timing diagrams illustrating the processing of
a normal write data frame by the extender unit shown in FIG. 2
FIGS. 8A, 8B, 8C, and 8D are timing diagrams illustrating the processing of
an aborted write data frame by the extender unit shown in FIG. 2.
FIG. 9 is a flow diagram illustrating the operation of the In Buffer Fill
State Machine (IBFSM) of the extender unit shown in FIG. 2.
FIG. 10 is a flow diagram illustrating the operation of the In Frame State
Machine (INFRSM) of the extender shown in FIG. 2.
DESCRIPTION OF THE PREFERRED EMBODIMENT
Referring first to FIG. 1., a system 10 incorporating the present invention
includes a host processor 12, which communicates by way of a parallel bus
(not separately shown) with a channel 14. Channel 14, in turn,
communicates serially with a channel extender unit 22 by way of a duplex
fiber-optic link 16 comprising an outbound conductor 18 for transmitting
information from the channel 14 to the extender unit 22 and an inbound
conductor 20 transmitting information back from the extender unit 22 to
the channel 14. Extender unit 22 in turn communicates with one or more
control units (CUs) 26 by way of a parallel interface 24 comprising bus
and tag lines. The protocols governing the serial link communications
between the channel 14 and the extender unit 22 are described in the
copending application of D. F. Casper et al. referred to above. The
serialized characters flowing on the serial link 16 are described in
Franaszek et al. U.S. Pat. No. 4,486,739, which patent is incorporated
herein by reference.
If the link 16 is idle, then only idle characters flow in either direction.
If either conductor of the link 16 becomes non-idle, then this means that
a frame is flowing in that direction. Frames may flow in both directions
on the link 16 simultaneously. A normal frame conforming to the protocol
referred to above consists of (1) a two-character passive-start-of-frame
(PSOF) delimiter, (2) data-type characters including (a) an architecture
identifier (AID) character (b), from 1 to 130 frame contents characters,
and (c) two cyclic redundancy check (CRC) characters followed by (3) a
three-character disconnect-end-of-frame (DEOF) delimiter. An outbound
frame originating from the channel 14 can contain from 1 to 18 frame
contents characters, while an inbound frame originating from the extender
unit 22 can contain from 1 to 130 frame contents characters. Four types of
outbound frames (command, data, control and test) and four types of
inbound frames (status, data, control and test) are defined in the
protocol identified above. Data frames are variable in length, and contain
from 1 to 16 data bytes, and are used to transfer data between the main
storage (not shown) associated with the channel 14 and host processor 12
and the devices attached to control units 26.
Referring now to FIG. 2, extender unit 22 contains a
receiver/deserializer/decoder (RX/DESR/DEC) 28, hereinafter simply
"decoder", which converts serialized light pulses to electrical signals,
accumulates successive groups of ten serial bits into ten-bit transmission
code characters, and converts the ten-bit transmission code characters to
eight-bit format characters containing bits 0 to 7, a "K" bit and an odd
parity bit (P). The K bit is used to distinguish the special ten-bit
transmission codes (K characters) used as idle characters, frame
delimiters and special continuous sequences from data-type characters, as
described in U.S. Pat. No. 4,486,739, referred to above.
A first clocked logic circuit, more specifically, an In Buffer Fill State
Machine (IBFSM) 30, to be described in detail further below, detects the
arrival of a frame from the channel 14 (FIG. 1), checks the frame
including the CRC characters for validity and stores the frame in one of
two dual-port buffers constituting the In-frame Buffers (IBs) 32. A frame
is considered arriving into extender unit 22 if an SOF delimiter is
received, which usually occurs after receiving one or more idle
characters. Each storage location of buffers 32 stores 9 bits, i.e. data
bits 0-7 and the parity bit P; the K bit is not stored since it is always
0 for a data-type character. Each of the two dual-port buffers which
together constitute IBs 32 is capable of holding 20 characters, which is
sufficient for the maximum outbound frame contents of 18 characters plus 2
CRC characters. The CRC characters are written into IBs 32 since they
cannot be recognized as CRC characters in advance of receiving the first K
character of the DEOF delimiter. They are also used for logout purposes in
case a CRC error is detected by IBFSM 30.
A second clocked logic circuit, more specifically, an In Frame State
Machine (INFRSM) 34, controls the transfer of incoming data from the
in-frame buffers 32 to storage means, more particularly, a pair of data
buffers (DBs) indicated collectively by the reference number 44 and
comprising a pair of individual buffers 44a and 44b (FIG. 5). For the
purposes of this disclosure in-frame buffers 32 may be regarded as the
input buffers and data buffers 44 may be regarded as the output buffers,
since it is data transfers from the former to the latter with which the
present invention is concerned. INFRSM 34 also moves portions of the frame
into a set of in-frame registers (INFRREGS) 36 to decode the type of frame
being processed. If it is a command frame, INFRSM 34 sends it to an
Initial Selection State Machine (ISSM) 40 for execution. Certain control
frames and all test frames, on the other hand, are executed by a
microprocessor 38 ("CODE" in FIG. 2) running under the control of stored
microcode. Microprocessor 38 is also responsible for reset and
initialization sequences, error detection and reporting, and diagnostic
controls.
A Parallel Data Transfer State Machine (PARDXSM) 46, operating under the
supervisory control of ISSM 40, controls the transfer of data from data
buffers 44 to parallel interface 24 by way of NPL driver/receiver module
(NPLD/R) 42. Module 42 converts the extender unit signal levels to those
required to drive interface 24.
PARDXSM 46 also controls the transfer of data in the other direction, from
interface 24 through module 42 to data buffers 44, in the case of a read
operation. An Out Frame State Machine (OUTFRSM) 48 controls the subsequent
transfer of read data from data buffers 44 to an
encoder/serializer/transmitter (TX/SER/ENC) 52, which encodes successive
bytes into a suitable transmission format, converts the parallel bytes to
serial form, and transmits the serial signal as light pulses on conductor
20 to channel 14 (FIG. 1). OUTFRSM 48 operates in conjunction with a set
of out-frame registers (OUTFRREGS) 50.
Decoder 28 and IBFSM 30 are timed by a Receive Byte Clock (RBC), internal
to decoder 28, which uses the incoming signal from channel 14 (FIG. 1) to
generate a clock that is synchronous with the channel transmitter clock.
On the other hand, INFRSM 34, PARDXSM 46 and the other clocked logic
circuits of extender unit 22 are timed by a Transmit Byte Clock (TBC)
which, while having the same nominal frequency (e.g., 20 MHz) as the
Receive Byte Clock (RBC), runs asynchronously relative thereto. Although
not necessary for an understanding of the present invention, a fuller
description of the general operation of the extender unit 22 may be found
in the copending applications of D. F. Casper et al. and M. E. Carey et
al. referred to above, which applications are incorporated herein by
reference.
Referring to FIG. 3, input buffers 32 comprise a pair of dual-port buffers
32a (IBl) and 32b (IB2). A first port of each of buffers 32a and 32b
receives parallel data inputs from an IBIN register (IBINREG) 54 contained
in decoder 28. IBINREG 54 also supplies its output to a decoder 56 of
IBFSM 30, which detects the presence of a K character as distinguished
from a data-type character, the type of K character if present, and
whether an AID character conforms to the protocol (i.e., is a hex `00`).
IBINREG 54 additionally supplies its output to a CRC generator/checker 58
contained in IBFSM 30, which performs a CRC check on the frame being
received. The first ports of buffers 32a and 32b also receive write inputs
from respective AND gates 60 and 62, each of which receives one input from
a WRIB line of IBFSM 30. Gate 60 receives a second input from a
complemented SELWRIB line from IBFSM 30, while gate 62 receives a second
input from a SELWRIB line also originating from IBFSM 30. Finally, the
first port of each of buffers 32a and 32b receives a write address input
from an in-pointer register (IBINPTR) 154 of IBFSM 30. IBFSM 30 activates
the WRIB line synchronously with the RBC clock to transfer a byte of
incoming data from IBINREG 54 to the buffer 32a or 32b determined by the
logic level of SELWRIB.
IBFSM 30 also includes a pair of input buffer counters 158a and 158b (FIG.
3), which it uses to maintain respective counts IBINCTR1 and IBINCTR2 of
the number of frame contents bytes in input buffers 32a and 32b awaiting
processing by INFRSM 34.
Referring now to FIG. 4, IBFSM 30 contains various latches for
communicating control signals across the asynchronous boundary dividing
IBFSM 30 and INFRSM 34 (FIG. 3). Thus, IBFSM 30 contains a pair of
RBCSTART latches 74, one for each of buffers 32a and 32b, a single
RBCPAUSE latch 76, a pair of RBCGOOD latches 78 ,and a pair of RBCABORT
latches 80. For simplicity of exposition, only a single latch of each of
the paired latches 74, 78 and 80 is shown in FIG. 4. Latches 74-80 receive
respective set inputs from lines 82, 86, 90 and 94 from IBFSM 30 and reset
inputs from respective OR gates 100, 102, 104 and 106. OR gates 100-106
receive respective first inputs from lines 84, 88, 92 and 96 from IBFSM 30
and each receive a second input from a hardware reset (HWRST) line 98
originating from microprocessor 38 (FIG. 2).
Each of latches 74-80, in a manner well known in the art, comprises an
input latch followed by an output latch and receives clocking signals from
a pair of lines 108 (shown in FIG. 4 as a single line) originating from
the Receive Byte Clock (RBC). The respective clocking signals supplied to
latches 74-80 are so timed that, on each cycle of the Receive Byte Clock
(RBC) the input latch half is loaded with the information appearing at the
latch inputs, following which that information is transferred from the
input latch half to the output latch half.
In a similar manner, INFRSM 34 contains a pair of TBCSTART latches 110, a
single TBCPAUSE latch 112, a pair of TBCGOOD latches 114, and a pair of
TBCABORT latches 116. For simplicity of exposition, latches 110, 114 and
116, although paired to correspond with respective buffers 32a and 32b,
are each shown as only a single latch in FIG. 4. TBCPAUSE latch 112 is a
polarity hold latch which, as shown in FIG. 4, receives its D-input
directly from the output of RBCPAUSE latch 76. The output of latch 112
takes on the new value appearing at the D-input on each TBC clock cycle.
Latches 110, 114 and 116 receive respective set inputs from OR gates 132,
136 and 140, each of which receives one input from the corresponding latch
in IBFSM 30 and a second input from a line 118, 120 or 122 originating
from the microprocessor 38. Lines 118-122 are used for diagnostic purposes
only and are normally inactive. Likewise, latches 110, 114 and 116 receive
respective reset inputs from OR gates 134, 138 and 142, each of which
receives one input from HWRST line 98 and a second input from a line 124,
126 or 128 originating from INFRSM 34. Finally, each of latches 110-116
receives clocking signals from a pair of lines 130 (shown as a single line
in FIG. 4) originating from the Transmit Byte Clock (TBC). As in the case
of latches 74-80 of IBFSM 30, latches 110-116 of INFRSM 34 each comprise
an input latch half and an output latch half, which are consecutively
triggered on each cycle of the Transmit Byte Clock (TBC).
Considering again the RBC side of the RBC-TBC asynchronous boundary shown
in FIG. 4, IBFSM 30 also includes a pair of RBCSTARTSYNC latches 152
corresponding respectively to input buffers 32a and 32b. Latches 152 are
polarity hold latches, similar to TBCPAUSE latch 112, which receive clock
inputs from RBC lines 108 and respective D-inputs from the corresponding
IBSTART outputs of TBCSTART latches 110. IBFSM 30 uses latches 152 to
determine, prior to filling a selected input buffer 32a or 32b with data
from a frame, whether the buffer has been emptied of data from a previous
frame by INFRSM 34.
Referring again to FIG. 3, INFRSM 34 also contains an in-frame buffer
output register (IBOUTREG) 72, which receives gated outputs from
respective buffers 32a and 32b. Thus, if a signal SELRDIB generated by
INFRSM 34 is low, IBOUTREG 72 receives data from the second port of buffer
32a by way of gate 64, while if SELRDIB is high, IBOUTREG 72 receives data
from the second port of buffer 32b by way of gate 70. Respective gates 66
and 68 supply the second port of a selected buffer 32a or 32b with a RDIB
signal generated by INFRSM 34 synchronously with the TBC clock, the
selection depending on the logic level of the SELRDIB signal also
generated by INFRSM 34. An input buffer out-pointer register (IBOUTPTR)
156 similar to in-pointer register 154 of IBFSM 30 is used by INFRSM 34 to
address via the second port the location of the selected buffer 32a or 32b
from which data is read.
Referring to FIG. 5, INFRSM 34 also includes a data buffer in-pointer
register (DBINPTR) 144, which it uses to address the selected buffer 44a
or 44b to transfer bytes thereto from IBOUTREG 72. Associated with DBINPTR
144 is a backup pointer register (DBINPTRBU) 146. Upon receiving an
IBSTART signal from the selected latch 110 (FIG. 4), INFRSM 34 transfers
the existing contents of DBINPTR 144 to DBINPTRBU 146. In the event of a
subsequent IBABORT signal from the selected TBCABORT latch 116 (FIG. 4),
the previously saved contents are restored to register 144 from backup
register 146. In this manner, in the event that an incoming frame is
aborted, INFRSM 34 in effect disregards the existence of any bytes of the
aborted frame that it has written into DB 44.
Referring now to FIG. 6, for each of the two buffers of DB 44, INFRSM 34
and PARDXSM 46 share a byte counter (BC) 148 and a backup byte counter
(BCBU) 150. Counters 148 and 150 are used to keep track of the number of
bytes in the corresponding buffer 44a or 44b awaiting processing by
PARDXSM 46. Thus, upon each transfer of a byte from the selected buffer
32a or 32b to the selected buffer 44a or 44b, INFRSM increments BCBU 150.
Similarly, upon reading each byte of data from the selected buffer 44a or
44b during channel write operations, PARDXSM 46 decrements the BC 148 and
BCBU 150 corresponding to that buffer. PARDXSM 46 also increments the
selected BC 148 each time it transfers a byte of data to the selected
buffer 44a or 44b from the parallel interface 24 during channel read
operations.
As is apparent from this description, INFRSM 34 increments only the backup
counter 150 as it is transferring data from the selected buffer 32a or 32b
to the selected buffer 44a or 44b. Upon subsequently receiving an IBGOOD
signal from the selected TBCGOOD latch 114 (FIG. 4), and following the
termination of any decrementing signal from PARDXSM 46, INFRSM 34
transfers the byte count from the selected backup counter 150 to the
selected counter 148. On the other hand, in the case of an aborted frame,
and following the termination of any decrementing signal from PARDXSM 46,
INFRSM 34 restores the byte count from the end of the previous frame from
counter 148 to backup counter 150. Since counter 148 is the only one of
each pair of counters 148 and 150 that is readable by PARDXSM 46, INFRSM
34 in effect masks the byte count for the selected buffer 44a or 44b from
PARDXSM 46 until INFRSM 34 has established that the incoming frame is
good.
The operation of IBFSM 30 for a valid write data frame will now be
described, with particular reference to FIGS. 7 and 9. Normally, when
incoming line 18 from channel 14 carries idle (K28.5) characters, IBFSM 30
remains in state 0. While in this state IBFSM 30 continually enters a loop
in which it examines the output of IBINREG 54 by way of decoder 56 for a
start of frame (SOF) delimiter consisting of a K28.5 character ("SOF.5" in
FIG. 9) followed by a K28.7 character ("SOF.7" in FIG. 9). Upon receiving
such a succession of K characters, and if the selected start as indicated
by the selected RBCSTARTSYNC latch 152 is inactive, IBFSM 30 enters state
1. If at this time the selected RBCSTARTSYNC latch 152 is active, IBFSM 30
sets an "overrun pending" error condition, since INFRSM 34 has not
finished processing data from the selected input buffer 32a or 32b.
Upon entering state 1, IBFSM 30 monitors IBINREG 54 for either the correct
AID character (in this particular example a hex `00`) or the K28.6
("EOF.6" in FIG. 9) of an AEOF delimiter; detection of any other character
will set a pending error condition. If such an AID character is received,
IBFSM then enters state 2 (FIG. 9) to start the normal data-handling loop
for writing incoming data into the selected input buffer 32a or 32b. On
entering state 2, IBFSM 30 begins writing the incoming frame contents
bytes into the selected buffer 32a or 32b of IB 32, one byte per RBC clock
cycle, beginning with the first frame contents byte following the AID
character. IBFSM 30 increments IBINPTR 154 each time it writes a frame
contents byte into the selected, input buffer 32a or 32b. IBFSM 30 also
cycles each frame contents byte through the CRC checker 58. Upon receiving
the third such byte following the AID character, IBFSM 30 sets the
selected RBCSTART latch 74 (FIG. 4). This results in the setting of the
corresponding TBCSTART latch 110 on the next TBC clock cycle. The selected
IBSTART signal generated by the selected TBCSTART latch 110 tells INFRSM
34 to begin transferring data from the selected input buffer 32 a or 32b
to the selected output buffer 44a or 44b, one byte at a time in
synchronism with the TBC clock. Also at this time, IBFSM 30 begins
incrementing the selected counter 158a or 158b for each byte transferred
from IBINREG 54 to the selected buffer 32a or 32b.
IBFSM 30 delays incrementing the selected counter 158a or 158b until the
transfer of the third frame contents byte to the selected register 32a or
32b because, as noted, above, the two terminal CRC characters appear to be
frame contents bytes and are not recognized as CRC characters until the
following K28.6 character of an EOF delimiter is detected. Ignoring the
first two data characters compensates the byte count for the two CRC
characters necessarily included in the count. As a result, INFRSM 34,
which bases its actions on the contents of the selected counter 158a or
158b, will not transfer the CRC characters from the selected input buffer
32a or 32b to the selected data buffer, even though the CRC characters
have been loaded into the input buffer.
IBFSM 30 continues to fill the selected buffer of IB 32 with bytes from
IBINREG 54 and to increment IBINPTR 154 and the selected counter 158a
(IBINCTR1) or 158b (IBINCTR2) in this fashion until it detects the
reception of a K28.6 character, which indicates the beginning of either a
disconnect-end-of-frame (DEOF) delimiter (K28.6-K28.1-K28.1) or an
abort-end-of-frame (AEOF) delimiter (K28.6-K28.4-K28.4). Upon detecting
such a K28.6 character, and if the selected RBCSTARTSYNC latch 152 (FIG.
4) is active, IBFSM 30 sets the RBCPAUSE latch 76 (FIG. 4). This results
in the setting of the TBCPAUSE latch 112 on the next TBC clock cycle. The
IBPAUSE signal generated by TBCPAUSE latch 112 tells INFRSM 34 to halt the
further transfer of data from IB 32 to DB 44. IBFSM 30 also stops writing
data into the selected buffer 32a or 32b and transitions to state 3. While
in state 3, IBFSM 30 expects either a K28.1 character ("EOF.1" in FIG. 9)
or a K 28.4 character ("EOF.4" in FI | | |
