1082 IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS. VOL? I . NO. 7.

SEPTEMBER 1989

VLSI Implementations of Communication Protocols-

A Survey
A. S . KRISHNAKUMAR AND KRISHAN SABNANI, SENIOR MEMBER,
IEEE

Abstract-Rapid advances in transmission technology and network- hardware system, typically a VLSI chip or a chip set,
.
ing have resulted in development of hardware implementationsof sev- which implements the functions of one or more protocol
eral communication protocols, called protocol controllers. Such con-
trollers have been developed for several standard protocols such as
layers. It is programmable if it can be programmed to
X.25 and LAPD. Controllers for some transport layer protocols are implement different protocols or variations of the same
also under development. Several controllers for the IEEE 802 local area protocol.
networks have been developed. In this paper, these controllers are sur- Protocol controllers come in many flavors-from mi-
veyed and some characteristics for classifying them are given. Some croprocessor-based implementations to single-chip VLSI
case studies from these controllers are given as illustrations. In addi-
tion, two new developments-the Protocol Engine and the Program-
circuits. Our focus in this paper will be on VLSI imple-
mable Protocol Engine-are also described. The Protocol Engine, cur- mentations. Most of the activity in this area, especially
rently under development, will implement a new protocol called XTP the use of VLSI techniques, has been recent. We will not
which performs the functions of both the network and transport lay- survey implementations which use programs on a micro-
ers. The Programmable Protocol Engine will be able to implement sev- or a minicomputer. A good survey of such implementa-
eral connection-orientedprotocols by changing contents of a program-
mable RAM.
tions is given in [ l].
The physical layer protocols such as RS-232 have al-
I. INTRODUCTION ways been implemented in hardware and will not be cov-
ered here. Several implementations of data link protocols
R ECENT advances in fiber optics have resulted in an
increase of several orders of magnitude in transmis-
sion bandwidth. In addition, the trend towards new net-
(layer 2) are in hardware. Several chips perform only some
front-end functions such as bit stuffing, bit destuffing, and
flag insertion [2]. Some recent chips implement the com-
works such as the broadband integrated services digital
plete link level protocols [3]. Occasionally we find hard-
network (ISDN) requires handling of high-speed traffic
ware implementations of network layer protocols also [4].
sources. Such trends indicate that communication pro-
There are some current efforts to implement transport layer
cessing has to be done faster than at any time in the past.
protocols in VLSI circuits [ 5 ] . Several attempts have been
Such high speeds can be achieved by the use of special-
made to simplify protocols which can help in easy imple-
ized VLSI circuits. In the past, transmission links used to
mentation in hardware [6]-[8]. There are no hardware im-
operate at rates of several kilobits per second (kbits/s).
plementations of the session layer and the higher layers.
New fiber links can operate at speeds of several gigabits
Thus, we will focus on controllers for the following lay-
per second (Gbits/s). Their speeds are faster than even
ers-data link, network, and transport.
that of the internal buses of mainframe computers. We
For most of the standard local area networks (LAN’s),
should not expect that the communication processing for
several chips have been developed to perform the medium
such links can be done using software on general purpose
access protocol and the front-end functions of their link
computers.
level protocols, such as bit stuffing, bit destuffing, and
If communication processing consumes a significant
flag insertion [9]-[2 13.
part of processing power of a large host computer, then it
Some of the criteria for comparing these VLSI control-
is very expensive. If it can be performed by a relatively
lers are throughput, programmability, interface with the
inexpensive VLSI circuit, then the overall system cost will
host, and ease of use. The throughput is typically mea-
be lower. One of the potential problems of implementing
sured in terms of number of messages processed per unit
protocols in hardware is the difficulty in changing its de-
of time. In some cases, the communication processing
sign when the underlying protocol is changed. Most of
performed by the controller can be altered by changing a
the new VLSI circuits for communication processing are
program or a microprogram. This level of programmabil-
at least partially programmable.
ity can vary. In some cases, only minor changes can be
In this paper, we provide a survey of protocol control-
made in these programs. In other cases, major changes
lers, which are defined next. A protocol controller is a
can be made, i.e., many different protocols can be exe-
cuted. Ease of changing these programs is also very im-
Manuscript received May 15, 1988; revised March IO, 1989.
The authors are with AT&T Bell Laboratories, Murray Hill, NJ 07974. portant. There are several levels of abstractions between
IEEE Log Number 8929692. the protocol specifications and the VLSI designs. If the

0733-8716/89/0900-1082$01 .OO O 1989 IEEE

KRISHNAKUMAR A N D SABNANI: VLSI IMPLEMENTATIONS OF COMMUNICATION PROTOCOLS 1083

changes in protocol specifications cannot be easily mapped

into the necessary changes in the program, then the chip
is very hard to reprogram.
The paper is organized as follows. In Section 11, we
present some characteristics on which our taxonomy of
protocol controllers is based. In Section 111, seven pro-
tocol controllers, production chips, and research proto-
types are described in some detail as case studies to illus-
trate the protocol controllers which have been developed
or are under development. We discuss future trends and
present our conclusions in Section IV.
CC

P L ~
Receive &
Transmit
Machines
Register
file &
ALU
FIFO DMA +
Interface - 51

11. A TAXONOMY OF PROTOCOL CONTROLLERS

Before describing a taxonomy of protocol controllers, t t t
I n t e r n a l Data Bus
t +
we present the various characteristics that can be used to
compare and classify protocol controllers. A list of the
characteristics used in our survey and their description N o t a t i o n PLT= Physical L e v e l I n t e r f a c e
SI = System I n t e r f a c e
follows.
Fig. 1. The internal architecture of the MC68824 token bus architecture.
A. Level of Primitives
Any hardware implementation can be considered to
provide a set of primitive operations (or commands) to its complete. During the development of a protocol control-
user, which can be used to exercise various functions pro- ler, variations of the same protccol have to be accom-
vided by it. For example, at one extreme, a protocol con- modated. If the underlying design is programmable, then
troller may have a single command which results in all such changes can be easily included. But if the controller
processing required for transmission or reception of a is hardwired, then changes in the protocol design are very
packet. This command is considered to be a high-level hard to accommodate.
primitive. Another controller may require a small se-
C. Underlying Architecture
quence of operations to.perform the same function. At the
other extreme, a protocol controller implemented as a Some protocol controllers exhibit enough structure, i.e.,
program on a general purpose microprocessor requires a have a datapath which can be modified by a hardware de-
large number of primitive operations (instructions from signer to implement a different protocol while the others
the instruction set of the microprocessor). These instruc- do not have such a general structure. Consider as an ex-
tions are low-level primitives. Different levels of primi- ample the MC68824 controller whose architecture is
tives have their own advantages and disadvantages. A shown in Fig. 1. The components of this architecture-a
high-level primitive allows close matching between the first-in-first-out buffer (FIFO), a direct memory access
hardware and the functions being performed, leading to (DMA) controller, receive and transmit machines, arith-
optimized designs. It does not require extensive program- metic logic unit (ALU), and register files-are not specific
ming by the host. The disadvantage is that it may be hard to any one protocol and the same machine organization
to modify the controller design for another protocol or with some modifications can be used to implement a dif-
even for a variation in the original protocol. Given the ferent protocol. Hence, this controller has an underlying
ambiguous nature of most protocol specifications, this architecture which can be adapted for other protocols.
could be a serious drawback. As described in the next This controller is further described in Section 111-C.
section, some controllers which are programmable and
provide high-level primitives do not have this problem. D. Performance
Low-level primitives provide a high degree of flexibil- A major consideration in evaluating a protocol control-
ity but are typically slow in performing the protocol func- ler is its performance-the number of packets it can pro-
tions. Many such primitives have to be executed to per- cess per unit time and the bit rate it can handle. While this
form any protocol function. The instruction fetch and depends on the protocol itself, the performance can be
decode overhead leads to lower efficiency than for a con- improved by choosing an appropriate hardware architec-
troller with high-level primitives. If a protocol controller ture. A controller designed for a specific protocol may
which is both flexible and fast is desired, it may be nec- also be able to take advantage of the special features of
essary to seek a middle ground between these two levels. the protocol to improve its performance.
B. Programmability E. Direct Memory Access (DMA) Interface and Bufer
A protocol controller is programmable if it can be made Management
to implement different protocols by changing a program All data transfer protocols require transmit and receive
or a microprogram. This feature is important because the buffers. In an implementation of two protocols from a lay-
typical protocol standards are usually imprecise and in- ered network architecture, it makes sense to store the user
 -

1084 IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 7. NO. 7. SEPTEMBER 1989

TABLE I
CLASSIFICATION DESCRIBED
OF THE CONTROLLERS I N THE PAPER

‘ *

data in a common area (typically, the host computer’s munication processing. The host computer interacts with
-.
.
memory) instead of storing them locally in the protocol these processors using high-level commands and does not
controller(s). To move data to and from the host’s mem- concern itself with the details of the protocol operation.
ory we need a DMA interface. In addition, the protocol The future trends are exemplified by the Protocol Engine
controller should have a simple method for storing, re- [5], [23] and the Programmable Protocol VLSI Engine
trieving, and referring to these buffers. This buffer man- [24]. The Protocol Engine implements a new protocol
agement operation is a significant data management func- called XTP [25] which performs the €unctions of both net-
tion. A protocol controller which incorporates this as a work layer and transport layer. The Programmable Pro-
part of its implementation is more useful than the one tocol VLSI Engine (PROVE) can be programmed to im-
which does not. This fact has been recognized, and most plement different protocols. The major Characteristics of
VLSI protocol controllers [22] incorporate DMA and some of these controllers are given in Table I. All con-
buffer management capabilities in their design. Several trollers listed in Table I are described later as case studies.
experts believe that these capabilities are the major bot- There are many VLSI implementations of protocols
tlenecks in speeding up any controller. from the X.25 recommendation. Some of them implement
the link layer protocol only [3]. MC68605, a controller
F. Complexity from this group, is described later in Section 111-A. Some
It is desirable to rank the complexity of protocols im- others implement both the link layer and packet layer pro-
d
plemented by various controllers. There is no quantitative tocols [4]. The NTT X.25 controller, which implements
way of measuring protocol complexity. Such a measure both of these layers, is described later in Section 111-B.
should capture the amount of processing required for han- There are also some VLSI implementations for the ISDN
dling each packet. Some work should be done in the future Link Access Procedure on the D-channel (LAPD) [26],
on this quantification. [27]. Many VLSI protocol controllers for local area net-
In the next section, we will present some examples and works (LAN’s) have also been developed. This is a nat-
classify them based on the characteristics described here. ural outcome of the higher speeds at which LAN’s operate
The examples have been chosen so as to sample all major compared to the wide-area networks. Most of the con-
types of protocol controllers. trollers are designed for the Token Bus, the Ethernet, or
the Token Ring protocols. A few other access protocols
111. CASESTUDIES have also been implemented 191, [ 1I], [ 121. Descriptions
Early protocol implementations started as software im- of some Token Bus controllers can be found in [ 131-[ 163.
plementations due to many reasons-among them the low The MC68824 controller from this class of controllers is
speed of communication channels, the lack of widely ac- described in Section 111-C. There are many controllers for
cepted standards for protocol, and the complexity and cost the widely used Ethernet [171-[20]. Such a controller from
of hardware implementations. The emergence of various intel is described in Section 111-D. A controller for the
protocol standards and VLSI technology has changed the Token Ring LAN described in [ 101 is summarized in Sec-
rules of the game. Further impetus is provided by the need tion 111-E. The major standard next-generation-LAN is the
for executing these standard protocols at high speeds to Fiber Distributed Data Interface (FDDI) network operat-
utilize the high bandwidth provided by fiber-optic links. ing at 100 Mbits/s. Some controllers have been devel-
Another important area where protocol controllers can oped for FDDI [2 11.
make an impact is that of protocol conversion and inter- Seven case studies are presented next which illustrate
networking. Programmable protocol controllers are par- the spectrum of protocol controllers which have been de-
ticularly suitable for this purpose. veloped or are under development. A summary of their
Current state-of-the-art is exemplified by chips such as characteristics is given in Table I.
the MC68605 X.25 protocol controller and the MC68824
Token Bus controller from Motorola, the VLSI imple- A. MC68605 X . 25 Protocol Controller
mentation of layers 2 and 3 of X.25 from Nippon Tele- The MC68605 X.25 Protocol Controller (XPC) is a
phone and Telegraph Company (NTT), and the Ethernet VLSI chip that implements the X.25 data link layer pro-
controller chips from Intel and AMD. These chips act as tocol (LAPB) [3]. It implements the complete protocol
coprocessors which relieve the host computer of com- including the retransmission procedure, and relieves the
KRISHNAKUMAR A N D SABNANI: VLSI IMPLEMENTATIONS OF COMMUNICATION PROTOCOLS 1085

host from a large part of communication processing. The

XPC supports full-duplex communications at data rates of
:I: U, cornmandlstatus

up to 10 Mbits/s. It has two first-in-first-out buffers (FI-

FO's), each 22-bytes deep, to facilitate serial-to-parallel
data conversion during reception and parallel-to-serial
conversion during transmission. A DMA controller per-
forms high-speed data transfer to and from the memory
shared between the host and the controller. In addition to
the 16-bit cyclic redundancy code (CRC) specified in the
LAPB standard, the controller has also a provision for
generating a 32-bit CRC. The XPC performs various pro-
tocol functions in response to the commands from the host
processor. These commands fall into the following
classes:
initialization,
table handling,
link handling,
test and diagnostics. r
After a hardware ,or software reset, the initialization
commands can be used to configure the XPC for data
transfer. Three shared memory tables-station table, re-
ceive frame specification table, and transmit frame spec-
ification table-are used for communication between the
I n t e r n a l bus
Transmitted
Data t
host processor and the XPC. The station table contains CM - Common Memory DMAC - DMA Control INFP - I n t e r f a c e Processor
XPC operating parameters, status information, and point- LNRP - Layer N r e c e i v i n g processor LNTP - Layer N t r a n s m i t t i n g Processor
ers to the transmit and receive tables. The receive table LM - Local Memory RLC - Receiving Line c o n t r o l l e r RH2.3 - Receive header
buffer
contains information regarding the location of receive TLC - T r a n s m i t t i n g Line C o n t r o l l e r TH2.3 - T r a n s m i t header b u f f e r
buffers and the queue of received frames. The transmit Fig. 2. Architecture of the NTT X . 2 5 protocol processor
table contains information regarding the location of trans-
mit buffers and the queue of packets to be transmitted. parallel, both across and within the layers. Based on the
The table handling commands can be used to access or functions performed at layers 2 and 3, the designers
change the station, transmit, and receive tables. The link worked out a design which overlaps these functions in
handling commands are used to set up and break the con- time. An interesting feature of this implementation is the
nection on the communication link. Test and diagnostic partition of layer 2 functions into upper and lower cate-
commands are used to test the system and also to generate gories which are processed in parallel. The lower layer
application frames not specific to the LAPB procedure. functions include CRC generation, flag generation and
Before issuing a new command, the host processor should testing, and bit stuffing and destuffing, while the upper
check a semaphore register in the XPC. This register is layer functions include the analysis and synthesis of
written by the XPC and read by the host. Programmable frames, flow control, and retransmission procedure. For
options include 8- or 16-bit data, and low-byte-first or details of the parallel processing, refer to [4]. It has a data
high-byte-first ordering for 16-bit data. The XPC also rate of 50 Mbits/s for a frame length of more than 500
provides buffer management for received and transmitted bytes.
frames which reside in shared memory. A block diagram of its architecture is shown in Fig. 2.
In addition to performing communication processing, It has four processors: L3RP, L3TP, L2RP, and L2TP.
the XPC performs the DMA and buffer operations re- The layer 2 processor L2RP (L2TP) performs both the
quired for moving the transmitted and received informa- upper and lower layer functions for the receiver (trans-
tion frames to and from the shared memory. The XPC is mitter) operations. Similarly, the other two processors
a good example of a communication coprocessor which L3RP and L3TP perform the operations for the network
can be used by a host processor to offload its communi- layer. All four processors operate concurrently. Many
cation processing burden. context variables such as sequence number counters, and
the poll and final bit are shared by these processors. A
B. m e NTT X.25 Protocol Processor locking mechanism is used to maintain consistency of the
This controller is a CMOS VLSI implementation of the context information. A DMA controller transfers the data
data link and network protocols in the CCITT X.25 rec- in received frames to an external memory and brings it
ommendation. It was developed by Aoki et al. [4], [28], out during transmission.
[29] at Nippon Telephone and Telegraph Company, Ja- The layer 3 processor performs multiplexing and de-
pan. It exploits parallelism in functions of the two layers. multiplexing of logical channels. To do this efficiently, a
The receivers and transmitters for both layers operate in fast context-switch mechanism is needed. In the multi-
 1086 IEEE JOURNAL ON SELECTED AREAS I N COMMUNICATIONS, VOL. 7 . NO. 1. SEPTEMBER 1989

plexed operation of the X.25 packet layer, many logical control the modem which connects the controller to
channels operate over a single physical channel. Each one the physical line.
of these logical channels has context information such as
The host controls the MC68824 controller by issuing ap-
receive sequence numbers and transmit sequence num-
propriate commands and does not intervene during normal
bers. Processing of the incoming packets on a particular
transmission and reception of frames. To support high-
logical channel is based on its context information. When
speed bulk data transfers between the host and the net-
a packet on a multiplexed link is processed, the appropri-
'~ work, a shared memory with linked data buffer structures
ate context information has to be brought into the con-
is used. The reader is referred to [14] for further details
troller. Since this happens frequently and represents an
on various modes of operation.
overhead, a fast context-switch mechanism is needed. It
A useful feature of this controller is the provision of
is not clear from [4], [28], and [29] whether this control-
. ler provides a fast context-switching mechanism. Based
monitoring and diagnostic aids. Information about inter-
esting quantities such as number of tokens passed and
on this description, we can conclude that this controller
number of FIFO overruns can be measured by the
is an example hardware implementation which exploits
MC68824 controller. If these numbers exceed a host-pro-
the parallelism in protocol operations to achieve high pro-
grammed threshold, the controller generates an interrupt
cessing speeds.
for the host. These statistics can be used to monitor net-
C. The MC68824 Token Bus Controller work usage and traffic; this information can be used to
configure the network efficiently. The diagnostic aids pro-
The MC68824 token bus controller from Motorola [ 141
vided consist of the following tests-a host-interface test,
implements the IEEE 802.4 media access control (MAC)
a full-duplex loopback test, a transmitter test, and a re-
layer functions. These functions cover the access control
ceiver test.
procedure and a major portion of the data link layer.
This controller has a good design matched to the re-
The architecture of the MC68824 controller is shown
quirements of the protocol being implemented. Since it is
in Fig. 1. The controller consists of the receive and trans-
intended to be a token bus controller only, the host can
mit state machines, an arithmetic logic unit (ALU) and
program only some parameters. However, its architecture
register file, a FIFO buffer, DMA, and a bus interface to
is general enough to be adapted to other protocols.
the host processor. These units are controlled by a micro-
i coded controller. The use of microcoded control enabled D. The Intel 82586 Communications Controller
the designers to adapt quickly to the changes in the evolv-
As the Ethernet LAN is used widely, there are many
ing protocol. This suggests that it might be advantageous
controllers from different manufacturers available at pre-
to have this facility not only during development but even
sent. For a comprehensive list, the reader is referred to
afterwards, i.e., provide a certain degree of programma-
[30]. We will describe one such controller, the Intel 82586
bility to adapt the hardware to variations of the access
communication controller [3 11. This controller imple-
protocol. An extension of this idea leads to the program-
ments the complete access procedure used in Ethernet in-
mable protocol controllers discussed later in Section
cluding automatic retries after collision and random back-
111-G. To handle the 10 Mbit/s data rate without overruns
off generation. It provides the host processor with high-
on reception or underruns on transmission, a 40-byte FIFO
level commands.
buffer is used in this design. The receive and transmit ma-
The 82586 communication controller has the following
chines perform CRC computation, and serial-to-parallal
features.
and parallel-to-serial conversion. The ALU is used to
Collision sense, multiple access with collision detect
generate program addresses for microprogram routines, to
(CSMA/CD) method, the access protocol for Ethernet, is
compare incoming address with the station address, and
performed by this controller.
to collect statistics.
It performs direct transfer of frames to/from the host
The MC68824 controller provides to the host processor
memory using four on-chip DMA channels.
high-level commands matched to the token bus commu-
Commands from the host processor are read from a
nication protocol. These commands can be used to:
command list in an external shared memory.
load parameters from the initialization table in shared
It provides the host with automatic status reports on
memory into the 68824 controller (initialize the control-
received and transmitted frames, including error condi-
ler), tions.
choose different options and modes to configure the
It provides diagnostic commands for testing the con-
controller for one of many different token bus networks
troller and for monitoring network status.
(set operation mode),
transmit data frames, It also can perform 16- or 32-bit CRC generation and
set and read values of parameters which are not di- checking. Its data bus can be configured for either 8- or
rectly accessible to the host, 16-bit operation. It can handle data rates up to 10 Mbits/s.
test the controller, The internal architecture of the 82586 controller, shown
notify the controller of events such as completion of in Fig. 3, consists of two major blocks: the parallel pro-
an interrupt routine, and cessor and the serial channel. These blocks communicate
KRISHNAKUMAR A N D SABNANI: VLSI IMPLEMENTATIONS OF COMMUNICATION PROTOCOLS 1087

1 ALU
to the host, on-chip DMA and buffer management, and
execution of all protocol functions.

E. The Texas Instruments (TI) Token Ring Adapter

(TMS380)
The TI token ring controller implements the medium
access and logical link layer protocols for the IEEE 802.5
Exponential token ring LAN [lo]. This logical link layer protocol is
Micro-
Backoii based on the IEEE 802.2 standard. This adapter acts as a
Unit instruction
satellite unit for a host which has to be connected to a
ROM
token ring LAN. It is based on a general RISC architec-
ture consisting of five chips: three MOS VLSI circuits and
two medium scale integrated (MSI) linear bipolar circuits.
A block diagram of this adapter is given in Fig. 4. The
three MOS VLSI circuits are the communication proces-
sor, the protocol controller, and the system interface. The
~~~~~~i~ Transmit
Unit communication processor consists of a 16-bit central pro-
Transmit
4 Bit 4 Byte 4- 1 cessing unit (CPU), 2.75 kbytes of parity protected RAM
FIFO
Machine Machine for packet buffering and working storage, and a process
timer. It is the overall controller of the adapter. The pro-
\ / tocol controller VLSI circuit performs time-critical func-
1 tions such as address recognition in firmware. Some other
Serial Channel Parallel Processor examples of time-critical functions are serial-to-parallel
Fig. 3. Architecture of the Intel 82586 controller. and parallel-to-serial conversion, CRC generation and
checking, token control, and encoding to and from differ-
ential Manchester code. The system interface VLSI pro-
via the transmit and receive FIFO buffers. The parallel vides interface with the host. The two MSI bipolar cir-
processor performs the interface functions with the host cuits perform the physical interface function. They contain
processor. It consists of several blocks such as the com- TTL to differential line drivers and receivers, a ring clock
mand unit, the DMA machine, and the receive unit. The receiver using a phase-locked loop circuit, and fault de-
command unit fetches commands from and writes status tection such as signal loss and frequency error.
information to the memory. It also controls the DMA ma- The adapter performs complete processing for the me-
chine. The DMA machine performs data transfer to/from dium access and link layer protocols. It provides high-
the host memory. The receive unit performs for the re- level primitives to the host. It can process back-to-back
ceive memory structure functions similar to that of the packets received from the LAN.
command unit. The receive memory structure is used to
store the incoming packets. Both of these units share a F. Protocol Engine
microinstruction read-only memory (ROM). The serial
channel performs the CSMA/CD procedure and the front- The Protocol Engine described by Chesson in [5] is
end functions of the link layer protocol. It consists of sev- based on the premise that network software will be unable
eral blocks, such as the transmit byte block, the transmit to keep pace with the trend towards higher speeds of net-
bit block, the receive byte block, and the receive bit block. work hardware. The receiver is considered to have the
The transmit byte block executes commands received bulk of protocol complexity and hence its performance
through the transmit FIFO and returns status information limits the throughput. This has led to the design of a pro-
through the receive FIFO. It assembles the frames to be tocol called XTP [25] in which the receiver complexity is
sent. The transmit bit block performs front-end process- reduced to increase its throughput. This is done by allo-
ing such as serialization and encoding of data, bit-stuff- cating some receiver tasks to the transmitter. The XTP
ing, CRC generation. Similarly, the receive bit machine protocol performs network as well as transport layer func-
performs bit destuffing and CRC checking and it delivers tions.
the decoded data in bytes to the receive byte machine. The Protocol Engine Project envisions a chip set ini-
Further processing on these data from the receive bit ma- tially aimed at Ethernet, FDDI, and internet applications.
chine is done by the receive byte machine which then The key features of this engine are
sends it to the receive unit. The operation of various units 100 Mbit/s bandwidth,
in the 82586 controller is highly concurrent. This allows adaptability to multiple physical layers including
this controller to operate at a high speed. Ethernet, the IEEE 802.3 LAN, and the 100 Mbit/s FDDI
Its characteristics are similar to that of the other con- ring,
trollers described earlier-high-level primitives provided useful for implementing real-time gateways which
 1088 IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. I. NO. 7. SEPTEMBER 1989

Interface
Logic
I
Processor

. I
r ' " L V L Y ' Address

II I I
Engine Loqlc
Control
Logic - 1 SMemory
tate Vector

, I

Fig. 4. Architecture of the TI adapter for the token ring LAN.

can perform real-time data transfers between a pair of net-

works,
provision of both virtual circuits and datagrams.
The current architecture of the protocol engine is shown
in Fig. 5 . Its main components are the control logic, the
address logic, the buffer logic, the network interface logic,
and the host interface logic. The controllers for the var- Fig. 5 . Current design of the Protocol Engine
i ious logic units are contained in the control logic. The
control logic also contains a state machine for the XTP
protocol. This implementation of this state machine has and the other controllers is that PROVE is not designed
limited programmability achieved through the use of mi- to implement any one specific protocol. It is designed to
crocode. The address logic performs address translation implement a collection of communicating finite state ma-
for routing, The buffer logic handles the memory access chines (FSM's) efficiently. Several protocols can be spec-
needs of both the host and the protocol engine. It also ified as a collection of FSM's. PROVE can implement
transfers data between internal shift registers and external several connection-oriented protocols. One key feature of
buffers. Design of the network interface logic depends on PROVE is fast context switching to handle multiplexed
the specific network choice. Similarly, the host interface operation of logical links or virtual circuits efficiently.
logic depends on the host processor. Their designs are PROVE, shown in Fig. 6, consists of three major
chosen on a case-by-case basis. blocks-the message parser (MP), the message assembler
The Protocol Engine is a step in the right direction to- (MA), and the central control unit (CCU). The MP breaks
wards utilizing high bandwidth available in fiber-optic the header information in each incoming packet into its
channels. The ideas proposed in [5] will very likely affect component tokens and provides them to the CCU after the
the future VLSI implementation of protocols. packet is found to be syntactically correct. The MA per-
In [ 5 ] , a scheme for implementing gateways using Pro- forms the reverse operation by assembling the tokens pro-
tocol Engines is also proposed. It is not clear how easily vided by the CCU into a packet. The syntax of valid pack-
one can design the various host interface logic units ets is specified using a tree grammar and is converted into
needed in this scheme. Since it has to be designed on an the microprogram for the MP and the MA using a set of
ad hoc basis, designing a gateway may require a lot of software tools. A wide variety of protocol formats can be
effort. handled hy the MP and the MA with appropriate program-
ming. The CCU implements the core of the protocol spec-
G. Programmable Protocol VLSI Engine (PROVE) ified as a collection of communicating finite state ma-
All the controllers decribed until now are designed for chines in a formal specification language. These FSM's
specific protocols. We will next describe the architecture are stored as tables in an external RAM. Thus, the CCU
of programmable protocol controller that allows protocols can be reprogrammed by changing the tables in the RAM.
specified in a formal language to be executed directly. It uses the tokens provided by the MP as inputs. The MP
This is based on ongoing work by the authors and an early and MA perform syntactic processing of packets while the
description can be found in [24]. A major difference be- CCU performs semantic processing. Buffer management
tween the Programmable Protocol VLSI Engine (PROVE) and DMA interface are done by a separate interface unit.
KRISHNAKUMAR AND SABNANI: VLSI IMPLEMENTATIONS OF COMMUNICATION PROTOCOLS 1089

MESSAGE MESSAGE

PARSER ASSEMBLER

t f t f + tv+ f +
ALU SEQ 1 SEQ 2 SEQ n

8
REGISTER

FILES
I
ARB H
I
ARB 4
I
ARB ]

CENTRAL CONTROL UNIT

TCS -- Timer Control Subsystem

TM - Timer Memory
GCM -- Global Context Memory
ARB -- Arbiter
STM -- Slate Table Memory

Fig. 6. PROVE Architecture.

IV. CONCLUSIONS [2] “Z8030/Z8530 serial communication controllers,’’ in MOS Micro-

processors and Peripheralsfor AT&T, Advanced Micro Devices Data
As described in this paper, controllers for several stan- Book, 1987-1988.
[3] I. Erickson, “Protocol controller chip manages X.25 interface,”
dard protocols have been developed or are under devel- Comput. Design, vol. 24, pp. 78-81, Sept. 1 , 1985.
opment. The motivation behind this trend is progress of [4] M. Aoki, T . Uchiyama, S. Tonami, A. Hayakawa, and H. Ichikawa,
transmission technology and a desire to offload protocol ‘‘Protocol processing for- high-speed packet switching systems,” in
Proc. In?. Zurich Seminar,’Ziirich, Switzerland, Mar. 1986, pp. 125-
processing from host processors to satellite units. 130.
Most of the standard protocols were designed in the [5] G. Chesson, “The Protocol Engine Project,” UNIXRev., pp. 70-77,
1970’s for communication channels such as a telephone Sept. 1987.
[6] D. Clark, M. Lambert, and L. Zhang, “NETBLT: A high throughput
line. These channels have a low bandwidth and a high transport protocol,” ACM Cornput. Commun. Rev., vol. 17, no. 5,
error rate. With the widespread use of fiber optic channels Special Issue, 1987.
[7] D. R. Cheriton, “VMTP: A transport protocol for next generation
in the future, many of these limitations will not exist. Fi- communication systems,” in Proc. ACM SIGCOMM’86, Aug. 1986.
ber channels opepte at high speeds and low error rates. [8] A. G. Fraser and W. T. Marshall, “Data transport in a byte stream
Novel simpler protocols can be designed for such chan- network,” IEEE J . Selen. Areas Commun., this issue, pp. 1020-
nels. These protocols shouId be designed in such a way 1033.
[9] B. Cayton, “VLSI circuit provides a cost effective token LAN,” in
so that they can be easily implemented in hardware. As GLOBECOM ’84 Conf. Rec., vol. 3, 1984, pp. 1345-1349.
protocols are made leaner and protocol processing ceases [lo] R. G. Cochran and G. R. Samsen, “A VLSI chip set for token ring
LANs,” in Proc. IV Phoenix Conf. Compur. Commun.,1985, pp.
to be a bottleneck, movement of large quantities of data 428-431.
between the host and the protocol controller becomes the [I 11 D. Walters, Jr., P. Lou, 0. Fanini, and P. Koeppen, “A LAN system
bottleneck. Very high-speed protocol implementations interface with selectable bus protocols,” in Proc. ISSCC 85, Feb.
1985, pp. 190-191.
will have to pay as much attention to the memory man- [12] H. Walze, “A VLSI communication controller for process data high-
agement as they do to the protocol processing itself. Sev- ways with pdv-protocol,” in Proc. VI European Conf. E1ectrotech.-
eral attempts to simplify protocols have been made re- EUROCON 84, i984, pp. 143-147.
[I31 T. Balph and J%Vitiera, “Architectural considerations in the devel-
cently [6]-[8]. opment of an IEEE 802.4 Token Bus chip set,” in Proc. IV Phoenix
Conf. Comput. Commun., 1985, pp. 439-443.
[I41 R. A. Dirvin Bnd A. R. Miller, “The MC68824 token bus control-
REFERENCES ler-VLSI for the factory LAN,” IEEE Micro, pp. 15-25, June 1986.
[15] M. P. Huth, “A VLSI chip set for the IEEE 802.4 Token Bus,” in
[ 11 P. Gunningberg, “Innovative communication processors: A survey,’’ Proc. IV Phoenix Conf. Comput. Commun., 1985, pp. 434-438.
Tech. Rep., vol. R87003, Swedish Instit. of Comput. Sci., Spanga, [I61 K. Smith, R. Morrell, P. Hofhine, A. Soria, D. Broadhead, M.
Sweden, 1987. Whitaker, and M. Huth, “A local-area network VLSI chip set,” in
 1090 IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 7, NO. 7, SEPTEMBER 1989

Proc. IEEE 1986 Custom Integrated Circuits Con$, 1986, pp. 426- 1281 H. Ichikawa, M. Aoki, and T. Uchiyama, “High-speed packet
430. switching systems for multimedia communications,” IEEE J. Select.
1171 EDLC Ethernet Durulink Controller, SEEQ Technology, San Jose, Areas Commun., pp. 1336-1345, Oct. 1987.
CA, June 1983. [29] H. Ichikawa et a l . , “Protocol control VLSI for broadband packet
[ 181 The AM 7990 Family IEEE-802.3/Etherner Node, Advanced Micro communications,” in Proc. GLOBECOM, Nov. 1988.
Devices, Sunnyvale, CA 1984. [30] R. E. Shotwell, Ed., Ethernet Sourcebook. New York: North-Hol-
[ 191 LAN Components User’s Manual, Intel Corporation, Santa Clara, CA, land, 1985.
1984. [31] M. Stark, A. Kornhauser, and D. Van-Mierop, “A high functionality
1201 A. G. Bell and G. Borriello, “A single chip NMOS Ethernet con- VLSI LAN controller for C S M A K D network,” in Proc. IEEE
‘: troller,” in Proc. IEEE Int. Solid-State Circuits Con$, Feb. 1983, Compcon Spring, Feb. 28-Mar. 3, 1983, pp. 510-517.
pp. 70-7 1.
I211 B. E. Cole, “LAN chips makers grapple in a turbulent market,”
Electron., vol. 61, no. 8, pp. 87-95, Apr. 14, 1988.
[22] R. W. Dobinson and M. D. Szpak, “Interfacing to Ethernet using
. VLSl protocol chips,” Interfaces in Computing, vol. 3, no. 3-4, El-
sevier Sequoia, Netherlands, Sept.-Dec. 1985, pp. 173-187. A. S. Krishnakumar received the B.Tech. degree from the Indian Institute
I231 G. Chesson and L. Green, “XTP-Protocol Engine VLSl for real-time of Technology, Madras, in 1979, the M.S. degree from Northwestern Uni-
LANs,” in Proc. EFOC/88, Amsterdam, July I , 1988. versity, Evanston, IL, in 1980, and the Ph.D. degree from Stanford Uni-
[24] A. S. Krishnakumar, B. Krishnamurthy, and K. K. Sabnani, “Trans- versity, Stanford, CA, in 1984, all in electrical engineering.
lation of formal protocol specifications into VLSI designs,” in Pro- He has been with the Computing Systems Research Laboratory, AT&T
tocol Specification, Testing, and Verification, VII, Elsevier Science Bell Laboratories, Murray Hill, NJ, since 1984. His research interests in-
Publishers B. V., North-Holland, May 1987, pp. 375-390. clude special-purpose architectures, parallel algorithms, and CAD.
[25] G. Chesson et al., “XTP protocol definition,” in Protocol Engines,
1421 State Street, Santa Barbara, Ca 93101.
[26] G. Geiger and L. Lerach, “ISDN-oriented modular VLSI chip set for
central-office and PABX applications,” IEEE J. Select. Areas Com-
mun., vol. SAC-4, no. 8, pp. 1268-1274, Nov. 1986.
1271 R. Kun, “A VLSI approach to supporting LAPD in an ISDN ex- Krishan Sabnani (M’M-SM’89). for a photograph and biography, see
change termination,” in Proc. ICC, 1986, pp. 760-765. this issue, p. 1019.