Unit 1 introduction

EMBEDDED
COMMUNICATION
SOFTWARE DESIGN

INTRODUCTION
COMMUNICATION DEVICES
COMMUNICATION ECHO SYSTEM
DESIGN CONSIDERATIONS
Communications systems include many devices ranging in complexity from small
hand held phones to large,central office switching devices.the earliest communic-
-ations devices, such as phones, were all electrical and did not possess
software,but
New communications devices incorporate software based on the function that
each
Device performs in the network.

The Open Systems Interconnect (OSI) model (see xrefparanum) was created by the
International Organization for Standardization (ISO) to form the basis for
communications systems. The OSI seven-layer model for communication protocols
provides a modular separation of functionality into seven layers, which can be
implemented in hardware and/or software. Each layer works independently, yet builds
upon the lower ones.
Each of the seven layers implements a specific communications function. This logical
division allows for modular development, ease of upgrades, and increased manageability,
as shown in xrefparanum.
Each layer is implemented via a combination of end points and protocols. An end point is
a device that implements a protocol function. It communicates with a peer end point
using the implemented protocol. For example, two hosts using the Transmission Control
Protocol (TCP) to communicate between each other are TCP peers (Layer 5 peers, as
depicted in xrefparanum). Similarly, a router and a WAN switch communicating over a
Frame Relay (FR) link are FR peers.
OSI Reference Model:

Table 1-1: Reference model.
Table 1-1: OSI reference model.
Layer Typical
Implementation
Name Function Examples
7 Software Application Network interface
and user apps.
Email
6 Software Presentation Data format XDR (eXtended Data
Representation) in
Network File System
(NFS) protocol definition
5 Software Session Dialog and
synchronization
management
Checkpointing protocols
4 Software Transport End-to-End
Application
Transport
User Datagram Protocol
(UDP), Transmission
Control Protocol (TCP)
3 Software and
Hardware
Network Addressing and
packet
transmission
Internet Protocol (IP)
2 Hardware and
Software
Data Link Frame transmission
across link
Ethernet MAC
1 Hardware Physical Transmission
method
RS-232

Application Layer
Presentation Layer
Session Layer
Transport Layer
Network Layer
Datalink Layer
Physical Layer
Application Layer
Presentation Layer
Session Layer
Transport Layer
Network Layer
Datalink Layer
Physical Layer
Fig:Communication Between Peers
Communicating
peer1
Communicating
peer2

This layer defines how transmission media, such as cable, communicate with other
devices and how bits are conveyed between peer systems. The physical layer provides
the hardware means for transmitting data, including mechanical, procedural, electrical,
and functional specifications for attributes such as voltage levels, encoding formats, and
signal pins. This layer is almost always implemented in hardware; functionality for the
physical layer is usually enabled in software as device drivers.
1.1.1 Physical Layer
1.1.2 Data Link Layer
The physical layer is inherently unreliable-its susceptibility to electrical noise being one of
the reasons. The data link layer provides for reliable transmission of frames between peer
nodes. As with the physical layer, the peer node is a physically adjacent node. The data
link layer is subdivided into two layers-the Logical Link Control (LLC) layer and the Media
Access Control (MAC) layer. The data link layer is usually associated with data integrity
through error detection and uses data checks such as Cyclic Redundancy Check (CRC).
Framing and CRC are handled by hardware controllers; so the data link layer software
needs to program the controllers appropriately, as with the physical layer.

1.1.3 Network Layer
This layer is responsible for delivery of packets from the source to the destination. It
isolates the network topology from the higher layers, so that these layers are network
independent. The network technologies may be different-for example, the source may be
connected to an Ethernet network, while the destination may be part of an ISDN network.
The network layer provides information for source and destination addresses, subnet
information, and parts used by higher transport layers. This layer uses information to
determine the correct path to reach a destination from the source and proceeds with
forwarding the packets from source to destination networks.Routers and software used by
routers typically utilize the network layer.
1.1.4 Transport Layer
Running on top of the network layer, the transport layer provides network-independent,
end-to-end integrity between two devices communicating through the network. It builds
on the addressing protocols implemented in the network layer and interfaces with higher
layer processes and applications on both source and destination systems. Protocols at this
layer may be either connection oriented and reliable or connectionless and unreliable.

1.1.5 Session, Presentation and Application Layers
The session, presentation, and application layers are closest to the user applications and
can be treated together. Session layer functionality includes establishment, management,
and termination of application connections and includes services such as data flow
synchronization, partitioning, and checkpointing. The presentation layer specifies how
user applications format data between applications and includes functionalities such as
encryption, data compression, and character sets. The application layer provides end- user
services such as mail, file transfer, and so on.
1.1.6 Networking Communication
Network communication processes data from the bottom of the OSI model with peer
devices in the same layer. For example, the physical layer of device A will
communicate with the physical layer of device B. So is the case for the data link layer,
but the data link layer has to use the services of the physical layer to communicate
with the data link layer on device B. Attached headers and trailers encapsulate data
and provide a communication path from layer to layer

Application
Layer
Application
Layer
Presentatio
n Layer
Presentatio
n Layer
Session
Layer
Session
Layer
Transport
Layer
Transport
Layer
Network
Layer
Network
Layer
Datalink
Layer
Datalink
Layer
Physical
Layer
Physical
Layer
Physical
Layer
header
Network
layer
header
Data link
layer
header
Presenta-
-tion
layer
header
Session
layer
header
Transport
layer
header
Application
layer header
& Data
Fig:Layering Encapsulation for a packet in the OSI Seven Layer Mode

1.2 Communication Devices
Communication devices have a specific place in the network and implement specific
protocols at each of the layers.
A host system, for example, may implement all the layers of the OSI stack to
communicate with a peer host entity.
A hub or repeater may implement only the physical layer to regenerate the signals.
An Ethernet switch may implement only physical and data link layer functionality.
A router primarily operates at the network layer, so it will typically implement the first
three layers, physical, data link, and network.
In the following figure,a host on LAN1 communicates with a server on LAN 2 across a
WAN (Wide Area Network) using routers and switches.which illustrates a typical
network architecture.

Figure 1.3: A typical network architecture

Host Systems
A host system connected to a LAN, such as Ethernet, communicates with devices
on its own LAN and can also communicate with devices on other networks, such as
Web servers.
A host system with a Web browser uses an application protocol like HyperText
Transfer Protocol (HTTP) to access the content provided by the Web server. In this
situation, HTTP runs on top of TCP at the transport layer, which, in turn, runs over IP
at the network layer. In xrefparanum, the host software implements layers 1 through 5.
Layer 2 Switches
Layer 2 switches operate at the data link layer and switch MAC (Ethernet) frames
between two LAN segments. They determine the destination Ethernet address from
the MAC frame and forward the frame to the appropriate port.
The port determination is done via a table which has entries in the form of a
(Destination MAC Address, Port) pair. The Layer 2 switch constructs this table by
learning the addresses of the nodes on each of its ports. It does this by monitoring
traffic that the nodes send out on its LAN segment (see xrefparanum). The source
address on a MAC frame indicates that the node with this address is present on the
LAN segment (and port) over which the frame was received

Routers
Routers operate at the network layer of the OSI model and can forward IP
packets between a source and destination.
Hosts send their “off-net” packets to the router, which, in turn, forwards these
frames in the direction of the destination. If the destination host is directly
connected, the packets are sent directly to the destination. If the destination host is
not directly connected, the packets are sent to another router, from where they are
directed towards the destination network, traversing, possibly, several intermediate
networks
IP routers build tables using routing updates that are exchanged between
neighboring routers. These tables are used for forwarding IP packets across a
network.
The format and processing of routing updates are defined in routing protocol
specifications like those for the Routing Information Protocol (RIP), Open Shortest
Path First (OSPF), and Intermediate System–Intermediate System (IS-IS)
protocols.

Using Multiple Protocols
Protocol functions constitute a large part of the software in a communications
system. Software that implements protocol functionality is often called a
protocol stack.
Each protocol stack component performs the protocol function while stacked on top
of or below another. For example, a TCP stack sits on top of an IP stack in a host
implementation. The IP stack could sit on top of a PPP (Point to Point Protocol) stack
for communicating over a serial interface.
Communications devices often perform more than one function—for example, a
router may also perform Layer 2 switching.
Telecom Equipment
In the telecommunications (telecom) world, circuit switching is the traditional
switching scheme used for voice communications. In this scenario, the end node is
typically a phone which is connected to the telecom network though a wired or
wireless link. The connection from the phone terminates at a local exchange or
switching center.

The phone links to the network by using messages sent via a tone (analog) or
messages (digital). Multiple switching centers or exchanges use these messages to
establish the connection from the dialing phone to the destination phone, a process
known as signaling.
The exchanges communicate with each other using a separate protocol called
Signaling System #7 (SS7). This protocol enables the end-to-end connection between
source and destination phones.
Phones
Traditional phones use analog signals to communicate with the central office
exchange. Some cordless phones still use analog methods to communicate with the
central office to record, store, and retrieve messages.
Cellular phones now use digital communication with the network. These phones
have a set of protocols starting from the physical layer that they use to
communicate with the base transmission station

Convergence
Many companies typically have two networks
— a telephone network and
— a data network.
The telephone network is a circuit-switched network both internally and externally.
while email, file transfer and collaborative work is done using IP on a packet-
switched network
To reduce complexity, there is a movement towards a single, integrated network, where
even voice is carried over the network in IP packets. In a typical voice-over-IP
implementation, a phone is connected to an Ethernet network instead of a private branch
exchange. Voice is sampled and digitized into discrete packets and sent over the
Ethernet network. Packets are forwarded to reach destinations, which could be other IP
phones or analog phones. With analog phones, a gateway converts the packets back
into analog information to communicate with the analog phone.

• protocol software, which implements a protocol specification,
• systems software (including infrastructure software) which usually
includes . a real-time operating system (RTOS) and an infrastructure to
manage the hardware.
1.3.1 Protocol Software
Protocol software implements the protocol as detailed in a protocol specification.
These specifications are usually specified by a standards body such as the
 International Organization for Standardization (ISO),
 Institution of Electrical and Electronic Engineers (IEEE), or
 International Telecommunications Union (ITU-T).
Example protocols include the Internet Protocol (IP) and IEEE 802.2 Logical Link
Control (LLC).
While the protocols are standard, implementation on communications systems
varies widely.
1.3 Types of Software Components
Broadly, there are two types of software components in a communications system:
Using the OSI layering as an abstraction mechanism, the software architecture of a
complex communications system can be partitioned into higher and lower layers.

Protocol implementation is typically based on a state event machine (SEM), also
known as a state machine. The state machine is the core of the protocol
implementation, typically in the form of the State Event Table (SET), which holds a set
of rules specifying the action to be performed based on events.
Higher Layer
Protocol Implementation
Lower Layer
Figure 1.4: Protocol Implementation and Interfaces

1.3.2 Infrastructure and Systems Software
The infrastructure and systems software components form the platform on which the
communications system is built.
Typically a real-time operating system (RTOS) forms the platform along with other
software components such as buffer management, memory management, timer
management subsystems, and device drivers.
Protocols run on top of the operating system using the buffer management
subsystem to exchange data on their interfaces and the timer management subsystem
to keep track of timeouts.
In a large distributed architecture, communication systems can include multiple rack-
mounted hardware modules.
Infrastructure software handles the inter-board or inter- chassis communication and
other software modules that monitor and manage the health of some hardware
modules.

The Communications Ecosystem
The communications infrastructure requires a number of participants in the development
and deployment process. xrefparanum details the players in the food chain.
They are:
Electronic Design Automation (EDA) vendors
Semiconductor component vendors
RTOS, tools and software vendors
Contract Manufacturers (CMs)
Equipment Manufacturers (EMs)
Home, Enterprise and service-provider users
Semiconductor component vendors supply their chips to the equipment manufacturers.
Semiconductor vendors use tools from Electronic Design Automation (EDA) vendors to
design chips, which are then supplied to the communications equipment manufacturers.
If the EM staff designs some ASICs, these EDA vendors supply the tools to the
equipment manufacturers also. The hardware designers on the EM staff design their
hardware using these chips—they may include processors, network controllers, switch
fabrics, network processors, and so on.

Figure 1.5: Players in the communications infrastructure

1.4 Design Considerations-A Prelude
The following is an example of some of the issues faced by designers and developers
of communications software. It is important that these issues are addressed early in the
design for the product to meet its requirements.
Does the hardware architecture involve one processor or multiple processors?
Partitioning of functions will depend upon the number of processors.
Has the RTOS been chosen? If so, does it provide memory protection between
processes/tasks? The task partitioning and interfacing will depend upon this.
What kind of performance is required? Can this be implemented completely in
software, or does it require some hardware acceleration support?
What are the protocols to be implemented, and how do they interface with the system
software and other protocols? Can any of the protocols be accelerated via hardware?
What kind of global data structures and tables are to be used for the implementation?

What kinds of buffer and timer management are required?
What kind of error notification and handling are required? Does the software require
extensive configuration and control? What are the types of interfaces to be provided for
such management?
Does the RTOS provide a simulator which can be used for the development while the
hardware is getting ready? What kind of testing can be done with the simulator? What
kind of testing can be performed once the hardware is ready?

This chapter investigates software in greater detail, starting
with an introduction to host-based communications along with
a popular framework for building host-based communications
software—the STREAMS environment.
Subsequently, we focus on embedded communications
software detailing the real-time operating system (RTOS) and
its components, device drivers and memory-related issues. The
chapter also discusses the issues related to software
partitioning, especially in the context of hardware acceleration
via network processors. The chapter concludes with a
description of the classical planar networking model.

Host-Based CommuniCations
Hosts or end systems typically act as the source and
destination for communications.
When a user tries to access a Web site from a browser, the
host computer uses the Hyper Text Transfer Protocol
(HTTP) to communicate to a Web server—typically
another host system.
The host system has a protocol stack comprising several of
the layers in the OSI model.
In the web browser, HTTP is the application layer protocol
communicating over TCP/IP to the destination server.

User and Kernel Modes
Consider a UNIX™-based host which provides the
functionality of an end node in an IP network.
In UNIX, there are two process modes—user mode and
kernel mode. User applications run in user mode, where
they can be preempted and scheduled in or out.
The operating system runs in kernel mode, where it can
provide access to hardware. In user mode, memory
protection is enforced, so it is impossible for a user
process to crash or corrupt the system.
In this mode, processes cannot access the hardware
directly but only through system calls, which, in turn, can
access hardware. Kernel mode is, effectively, a “super user”
mode.
System calls execute in kernel mode, while the user
process is suspended waiting for the call to return.

For data to be passed from user to kernel mode, it is first
copied from user-mode address space into kernel-mode
address space.
When the system call completes and data is to be passed
back to the user process, it is copied from kernel space to
the user space.
In the UNIX environment, the Web browser is an
application process running in user mode, while the
complete TCP/IP stack runs in kernel mode.
The browser uses the socket and send calls to copy data
into the TCP protocol stack’s context (in the kernel),
where it is encapsulated into TCP packets and pushed
onto the IP stack.

There is no hard-and-fast requirement for the TCP/IP
stack to be in the kernel except for performance gains and
interface simplicity.
In the kernel, the entire stack can be run as a single thread
with its own performance efficiencies. Since the TCP/IP
stack interfaces to multiple applications, which could
themselves be individual user-mode processes,
implementing the stack in the kernel results in crisp
interfaces for applications.
However, since memory protection is enforced between
user and kernel modes, the overall system performance is
reduced due to the overhead of the additional copy.

Some host operating systems like DOS and some
embedded real-time operating systems (RTOSes) do not
follow the memory protection model for processes.
While this results in faster data interchange, it is not
necessarily a reliable approach.
User processes could overwrite operating system data or
code and cause the system to crash.
 This is similar to adding an application layer function into
the kernel in UNIX. Due to the system-wide ramifications,
such functions need to be simple and well tested.

network interfaCes on a Host
Host system network interfaces are usually realized via an
add-on card or an onboard controller.
For example, a host could have an Ethernet network
interface card (NIC) installed in a PCI (Peripheral
Component Interface) slot as its Ethernet interface.
The Ethernet controller chip on the NIC performs the
Media Access Control (MAC), transmission, and reception
of Ethernet frames.
It also transfers the frames from/to memory across the PCI
bus using Direct Memory Access (DMA).

In the reception scenario, the controller is programmed
with the start address in memory of the first frame to be
transferred along with the default size of the frame.
For standard Ethernet, this is 1518 bytes, including headers
and Cyclic Redundancy Check (CRC). The controller
performs the DMA of the received Ethernet frame into
this area of memory.
Once the frame transfer is complete, the actual size of the
frame (less than or equal to 1518 bytes) is written into a
header on top of the frame.
At this stage, the Ethernet driver software needs to copy
the data from the DMA area to be memory accessible to
both the driver and higher layers.
This ensures that subsequent frames from the controller
do not overwrite previously received frames.

In the UNIX example, the Ethernet driver interfaces to the
higher layer through a multiplexing/demultiplexing
module.
This module reads the protocol type field (bytes 13 and 14)
in the Ethernet frame header and hands it off to the
appropriate higher layer protocol module in the kernel.
In a host implementing both IP and IPX, IP packets
(protocol type 0x0800) are handed off to the IP module,
while IPX packets (protocol type 0x8137) are handed off to
the IPX module in the kernel.
The packets are subsequently processed by these modules
and handed to applications in the user space. Frame
transmission is implemented in a similar manner.

streams arCHiteCture
Using a modular approach permits the development of
individual modules without the dependency on other
modules.
In the UNIX example, the IP module in the kernel may be
developed independent of the Ethernet driver module,
provided the interfaces between the two modules are
clearly defined.
When the two modules are ready, they can be combined
and linked in. While this is a good mapping of the OSI
model, an additional level of flexibility can be provided via
an “add and drop” of functional modules while the system
is running.
The most common example of this is the STREAMS
programming model, which is used in several UNIX hosts
for implementing network protocol stacks within the
kernel.

The STREAMS programming model was first specified in
AT&T UNIX in the 1980s.
It is now used in several UNIX systems and in some real-
time operating systems (RTOSes) as well.
 STREAMS uses a model similar to the OSI layering model
and provides the ability to create and manipulate
STREAMS modules, which are typically protocol
processing blocks with clear interfaces.

The model consists of a set of kernel-resident system calls,
kernel resources, and utility routines to facilitate duplex
processing and data paths between kernel mode and a
user process.
The fundamental unit of STREAMS is a stream, which is
used for data transfer between a user process and a
module in kernel space and can be decomposed into three
parts: a Stream head, zero or more modules, and a driver.

The stream head is closest to the user process; modules
have fixed functionality and interface to the adjacent layer
(the stream head or another module).
A module can be dynamically pushed on to or popped
from the stream by user action, making this architecture
suitable for the layering associated with communications
protocols.

Each module has a “read” side and a “write” side. Messages
traveling from the write side of a module to the write side
of the adjacent module are said to travel downstream.
Similarly, messages traveling on the read side are said to
be traveling upstream. A queue is defined on the read and
write side for holding messages in the module.
This is usually a First In First Out (FIFO) queue, but
priority values can be assigned to messages, thus
permitting priority-based queuing.
Library routines are provided for such operations as buffer
management, scheduling, or asynchronous operation of
STREAMS and user processes for efficiency.

streams messages
A message queue consists of multiple messages. Each
message consists of one or more message blocks.
Each message block points to a data block.
Most communications system suse this two-level scheme
to describe the data transfer units.
Messages are composed of a message block (msgb) and a
data block (datab).
The db_ref field permits multiple message blocks to point
to the same data block as in the case of multicast, where
the same message may be sent out on multiple ports.
Instead of making multiple copies of the message,
multiple message blocks are allocated, each pointing to
the same data block.

So, if one of the message blocks is released, instead of
releasing the data block associated with the message
block, STREAMS decrements the reference count field in
the data block. When this reaches zero, the data block is
freed.
This scheme is memory efficient and aids performance.
STREAMS is important because it was the first host-based
support for protocol stacks and modules which could be
dynamically loaded and unloaded during program
execution.
This is especially important in a system that requires a
kernel rebuild for changes to the kernel.

soCket interfaCe
The most common interface for kernel- and user-mode
communication is the socket interface, originally specified
in 4.2 BSD UNIX.
The socket API isolates the implementation of the
protocol stacks from the higher layer applications.
 A socket is the end point of a connection established
between two processes—irrespective of whether they are
on the same machine or on different machines.
The transport mechanism for communication between
two sockets can be TCP over IPv4or IPv6, UDP over IPv4
or IPv6, and so on.
A “routing” socket is also useful, for such tasks as setting
routing table entries in the kernel routing table.

The socket programming model has been used in other
operating systems in some popular commercial real-time
operating systems such as Wind River Systems VxWorks™.
 This permits applications that use the socket API to
migrate easily between operating systems that offer this
API.

issues witH Host-Based networking
software
Host-based networking software is not usually high
performance.
This is due to various reasons—there is very little scope
for hardware acceleration in standard workstations, the
host operating system may be inherently limiting in terms
of performance
 (for example, the user and kernel space copies in UNIX)
 Or the software is inherently built only for functionality
and not for performance (this is often the case, especially
with code that has been inherited from a baseline not
designed with performance in mind).

Despite these, protocols like TCP/IP in the UNIX world
have seen effective implementation in several hosts.
Designers address the performance issue by moving the
performance-critical functions to the kernel while
retaining the other functions in the user space.
Real time performance can also be addressed by making
changes to the scheduler of the host operating system, as
some embedded LINUX vendors have done.

EmbEddEd CommuniCations softwarE
Host machines running general-purpose operating
systems are not the best platforms for building
communications devices.
Even though some routers are built on top of UNIX and
Windows NT, they have seen limited use in the Internet.
 These routers perform all processing in software and have
to work within the constraints of the general-purpose
operating system, for example, equal-priority, timeslice-
based scheduling, which can result in packet processing
delays.
Moreover, often times, these general-purpose systems are
used to run other application code at the same time as the
networking application.

The solution is to use dedicated communication hardware
or an “appliance” which could be a router, switch, terminal
server, remote access server, and so on.
 For our discussion, the dedicated appliance is an
embedded communications device, to differentiate it from
the host, which participates in the communication.
Common characteristics of a communications appliance
are as follows:
It typically runs a real-time operating system
It has limited memory and flash
It either has limited disk space or is diskless
It provides a terminal and/or Ethernet interface for
control and configuration
It frequently has hardware acceleration capability

rEal-timE opErating systEm
The real-time operating system (RTOS) is the software
platform on which communications functionality and
applications are built. Real-time operating systems may be
proprietary (home grown) or from a commercial real-time
operating system vendor such as VxWorks™ from Wind
River Systems, OSE™ from OSE Systems, and Nucleus™
from Mentor Graphics.
The embedded market is still struggling with homegrown
platforms. Often, engineers from the desktop world are
surprised that so many embedded development engineers
still develop their own real-time operating systems.
 Some commercial real-time operating systems have too
much functionality or too many lines of code to be used
for an embedded project.
 Perhaps more significant, many commercial real-time
operating systems require high license fees.

The per-seat developer’s license can be expensive, and
royalty payments may be required for each product
shipped with the RTOS running on it.
Some engineering budgets are too tight to handle this
burden. Last, some engineers feel they can do a better job
than an off-the-shelf software component.
since the component may or may not be optimal for the
application, especially if the RTOS vendor does not
provide source code. However, this is not always a simple
task.

rtosEs for CommuniCations systEms
Early communications architectures were quite simple.
The entire functionality was handled by a big dispatch
loop—when data arrived, it was classified and appropriate
actions performed.
 The operations were sequential, and there was no
interaction between the modules which performed the
actions.
In this case, an RTOS would have been overkill and the
dispatch loop was more than sufficient. However,
communications systems are rarely this simple.
They require interaction between functional modules at
various layers of the OSI Seven Layer Model. If, say, TCP
and IP were implemented as separate tasks, they would
need an inter-task communication mechanism between
them, which could be in the form of queues, mailboxes, or
shared memory.

If the two tasks needed to access some common data such
as a table, semaphores might be used to protect access to
the table.
Commercial real-time operating systems provide these
mechanisms and functions, and there is no need to
recreate them.
RTOS vendors typically support the complete
development environment, including the processor used
for the project, the “tool chain” like compilers, assemblers,
and debuggers, and other development tools.
 RTOS vendors have also tuned their operating systems to
utilize some of the features of the processor being used for
the development—something that would take developers
on a homegrown project a much longer time to
accomplish and is usually beyond the scope of the
development project.

It is strongly recommended that developers of
communication systems use commercially available real-
time operating systems and place engineering focus on
communications development rather than infrastructure.
Typically, homegrown projects end up adding more
systems software to handle common infrastructure
functions that the RTOS provides out of the box.
Furthermore, newly developed OS software tends to be
more complicated, convoluted, and buggy, making it more
expensive to develop and maintain than the commercial
RTOS.
The following table summarizes the issues to consider for
using a commercial RTOS instead of developing your own
for the specific project.

Issue Standard RTOS Proprietary RTOS
Performance for a specific
application
Less Optimized More optimized
Maintenance Responsibility of RTOS vendor Responsibility of developer
Portability to multiple processors Provided by RTOS vendor via
separate packages
Has to be provided by developer
for each processor
Support for standard
Ethernet/serial devices
Provided as part of RTOS
package for board
Has to be developed
Modifiability Can be done only if RTOS
vendor provides source code
Easily modifiable since source
code is available internally
Tool Chain Support Supported by RTOS vendor Need to build using third-party
development tools
Standard Interfaces, IPC
mechanisms and APIs
Provided by RTOS vendor Has to be designed in by the
developer
Cost High in dollar terms Low in upfront dollar terms but
could be high because of
development effort/time and
debugging

board support paCkagE (bsp)
A typical embedded communications platform has a CPU,
flash, or DRAM from which the code runs, DRAM for the
data structures, and peripherals like serial and Ethernet
controllers.
The CPU requires its initialization sequence, after which it
can perform a diagnostic check on the various peripherals.
This software is CPU and board specific and is usually
included in the RTOS specific to the board.
This software, including the RTOS is also known as a
Board Support Package (BSP). For Common Off The Shelf
(COTS) communications boards, the BSPs are provided by
the board manufacturer via a license from the RTOS
vendor.
Alternately, the RTOS vendor can provide the BSP for
several popular COTS boards along with the RTOS
developer license.

For boards developed internally, engineers have to create
the BSP, which is not a trivial task.
Most vendors offer board porting kits, which instruct
engineers on how to create and test a homegrown BSP.
RTOS vendors and commercial system integrators often
provide board support as a consulting service.
Once the BSP is created, it allows an executable image of
the RTOS or a portion of the RTOS to run on the target
board and can be linked in with the communications
application to form the complete image.

mEmory issuEs
Embedded communications devices rarely have a disk
drive except when they need to store a large amount of
data.
These systems boot off a PROM (or flash) and continue
their function. In a typical scenario, the boot code on flash
decompresses the image to be executed and copies the
image to RAM.
Once decompression is complete, boot code transfers
control to the entry point of the image in RAM, from
which the device continues to function.

The embedded communications system comprises the
RTOS and the communication application.
The communication application is the complete set of
protocol and systems software required for a specific
function—for example, a residential gateway
implementation.
The software application and the RTOS use the RAM for
data structures and dynamic buffer and memory
requirements.
We earlier discussed memory protection in user and
kernel modes in a UNIX host.
The most significant difference between UNIX and the
RTOSes is that there is no defined kernel mode for
execution in RTOSes.

Memory protection is enforced between tasks where
appropriate, but that is all. Interestingly, many of the
popular earlier RTOSes did not support memory
protection between tasks.
This did not limit the development engineers’ flexibility
during testing and debugging. However, in the field, these
systems still ran the risk that user tasks with buggy code
could corrupt the RTOS system code and data areas,
causing the system to crash.
Recently, RTOSes with memory protection are seeing use
in communications systems.
 Note that memory corruption bugs can be manifested in
several indirect ways. For example, a task can overwrite
data structures used to maintain the memory pool.
. The system will crash only when malloc is called next,
causing much grief to the developer, who cannot figure
out why the system has crashed and which task is
responsible.

Our recommendation is to use memory protection if it is
available via a memory management unit (MMU) and in
the RTOS

Configuration and imagE
download
A communications system needs to be able to save its
current configuration so that if the system goes down, it
can read the last saved configuration and use it to start up
and be operational as soon as possible.
For this reason, the communications device configuration
is often stored in local non-volatile memory like an
EEPROM or flash. Alternately, the configuration can be
saved to and restored from (on restart) a remote host.
In the same context, these systems also permit the
download of a new image to upgrade the existing image on
the flash. Most communications systems require an
extensive amount of configuration to function effectively.

For example, a router needs to be given the IP addresses of
its interfaces; routing protocols need to be configured with
timer values, peer information, and so on.
Losing this configuration on reset would require the user
to set these parameters all over again—which is not only a
demand on network administrator time but also has a
potential for misconfiguration.
Frequently, the flash system is used for field upgrades to
avoid shipping the system back to the manufacturer for
bug fixes and upgrades.
To ensure that a new image does not cause the system to
become non-operational, systems provide a backup to the
last saved image.
That is, there will be two sections on the flash, one for the
existing saved image and the other for the newly
downloaded image.

The new image is downloaded to a separate area of the
flash so that the system can recover in case the download
is unsuccessful or if the new image has problems.
If the new image is downloaded and overwrites the
existing image, the system cannot recover from this error
and requires manual intervention.
 A key feature of telecom systems deployed in service
provider networks, is their ability to perform a stepwise
upgrade and rollback to the previous version of the
software if the upgrade is unsuccessful.

dEviCE issuEs
Unlike the PCs or workstations, embedded
communications devices do not come with a monitor and
a keyboard.
The only way to communicate with the “headless”
embedded device is through a serial port or Ethernet.
Headless devices can be booted and continue to operate
without a keyboard and monitor.
To communicate with the device through a serial port,
you need to connect a terminal or use a PC with a terminal
emulation program (like Hyperterminal on a Windows
PC).
The communications device typically has a Command
Line Interface (CLI), which allows the user to type
commands for configuring the device, displaying status
and statistics, and so on.

In addition, an Ethernet port is typically used for
communicating with the device for management
purposes.
The Ethernet port can be used to boot up a system as well
as download new software versions.
 The TCP/IP stack runs over this Ethernet port, so that the
network administrator can telnet to the device over this
port to access the CLI.
This facility is used by network administrators to manage
the device from a remote location.

dEviCE drivErs
Some RTOSes have their own communications stacks
integrated or available as an additional package. These
stacks interface to the hardware drivers through standard
interfaces.
Usually, the only hardware driver provided is the default
Ethernet driver for the device used for management
communication.
Other drivers need to be written for specific ports to be
supported by the application.
Standard driver interfaces ensure that the higher layer
stacks such as IP will use the same interfaces irrespective
of the device they are running on.
For example, as in UNIX, some RTOSes use the following
set of calls to access drivers, independent of the type of
driver (Ethernet, Serial, and so on).

open () causes the device to be
made active
close () results in the device being
made inactive
read () is used for reading data
received by the device
write () is used for writing data to the
device
ioctl () is used for configuring and
controlling the device
Applications using this interface will not need to be modified
when moving to a new platform, as long as the new driver
provides the same interface.

Hardware and Software Partitioning
Partitioning functionality between hardware and software
is a matter of technology and engineering with the
constraints of optimization.
For example, a DSL modem/router may implement some
compression algorithms in software instead of hardware,
to keep the cost of hardware lower.
The application environment may not consider this as a
restriction, if the performance of such a software
implementation is sufficient for normal operation.
As technology progresses, it may be easier and less
expensive to incorporate such functionality into a
hardware chip.
Developers should provide flexibility in their
implementation via clearly defined interfaces, so that an
underlying function can be implemented in software or

Size–Performance tradeoff
Students of computer science and embedded systems
would be familiar with issues related to size and
performance and how they sometimes conflict with each
other.
Caching is another size–performance tradeoff made in the
embedded communications space. A lookup table can be
cached in high-speed memory for faster lookups, but
instead of caching the entire table, only the most recently
accessed entries could be cached.
 While this improves the performance of the system, there
is an associated cost in terms of additional memory usage
and the complexity of the caching algorithms.
Depending on application and system requirements,
memory is used in different ways.

For example, the configuration to boot up a system could
be held in EEPROM. The boot code can be in a boot ROM
or housed on flash.
 DRAM is typically used to house the executable image if
the code is not executing from flash.
DRAM is also used to store the packets/buffers as they are
received and transmitted.
 SRAM is typically used to store tables used for caching,
since caching requires faster lookups. SRAM tends to be
more expensive and occupies more space than DRAM for
the same number of bits.
High-speed memory is used in environments where
switching is performed using shared memory.
Dual-port memory is used for receive and transmit buffer
descriptors in controllers such as the Motorola
PowerQUICC™ line of processors.

For cost-sensitive systems, the incremental memory cost
may not be justifiable even if it results in higher
performance.
Similarly, when performance is key, the incremental
complexity of a design that uses SRAM for caching may be
justified.

Hardware acceleration
All the information presented earlier about networking
software assumed that it runs on a single, general-purpose
processor (GPP).
These are the processors like the ones used in
workstations. They include the MIPS™ and PowerPC™ line
of processors, which have a strong RISC (Reduced
Instruction Set Computer) bias.
While these processors are powerful, there is always a
limit to the performance gain from a software-only
implementation.
For devices with a small number of lower speed interfaces
like 10/100 Mbps Ethernet, these processors may be
sufficient.
When data rates increase, and/or when there are a large
number of interfaces to be supported, software based
implementations are unable to keep up.

To increase performance, networking equipment often
includes hardware acceleration support for specific
functions.
This acceleration typically happens on the fast-path
function. Consider a Layer 2 switch, which requires
acceleration of the MAC frame forwarding function. A
Gigabit Ethernet switch with 24 ports,
for example, can be built with the Ethernet switching
silicon available from vendors like Broadcom, Intel or
Marvell along with a GPP on the same board.
The software, including the slow-path functions, runs on
the GPP and sets up the various registers and parameters
on the switching chipset.

These chips are readily available for any Ethernet switch
design from the semiconductor manufacturer and are
known as merchant silicon.
These chips are available with their specifications,
application notes, and even sample designs for equipment
vendors to build into their system.
In the case of an Ethernet switching chip, the device
specifies connectivity to an Ethernet MAC or to an
Ethernet PHY (if the MAC is already included on the chip,
as is often the case).
Hardware designers can quickly build their boards using
this silicon device.
The Broadcom BCM5690 is one such chip. It implements
hardware-based switching between 12 Gigabit Ethernet
ports, so two 5690s can be used to build a 24-port Gigabit
Ethernet switch.

Once the 5690s have been programmed via the CPU, the
switching of frames happens without CPU intervention.
Software vendors are provided with the programming
interfaces to these devices.
For example, for a switching device, we may be able to
program new entries into a Layer 2 forwarding table.
These interfaces may be provided through a software
library from the silicon vendor when the vendor does not
want to disclose the internal details of the chip.
Often, the details of the chip are provided, so software
engineers can directly program the registers on the chip
for the required function.
 Independent of the method used to program the device,
software performance can be enhanced by offloading the
performance-intensive functions to the hardware device.

network ProceSSorS
Network processors (NPs) are another type of network
acceleration hardware, available from vendors such as
Agere, AMCC, IBM, Intel, and Motorola.
 A network processor is simply a “programmable ASIC,”
which is optimized to perform networking functions. At
high speeds, a processor has very little time to process a
packet before the next packet arrives.
So, the common functions that a packet processor
performs are optimized and implemented in a reduced
instruction set in a network processor.
The performance of an NP is close to that of an ASIC; it
has greater flexibility since new “microcode” can be
downloaded to the NP to perform specific functions.

Programmable hardware is important because networking
protocols evolve requiring changes in the packet
processing.
The hardware needs to analyze multiple fields in the
packet and take action based on the fields.
For example, for an application like Network Address
Translation (NAT), there may be fields in the packet
which need to manipulated to reflect an address change
performed by the address translation device.
These are implemented via functions called Application
Layer Gateways (ALGs) which are present in the address
translation device implementing NAT.
 ALGs are dynamic entities and more are defined as
applications are developed. Since the address translation
performance should not be degraded as more and more
ALGs are added, programmable hardware like network
processors are a good fit for implementing NAT.

control and data PlaneS
A high level method of partitioning the functionality of
the system is by separating it into functions that perform:
All the work required for the basic operation of the system
(e.g. switching, routing)
All the work required for (1) to happen correctly
The classical planar networking architecture model uses
this partitioning scheme to separating the
communications functionality into three distinct planes.
Control Plane
Data Plane
Management Plane

The data plane is where the work required for the basic
operation takes place. The control and management
planes ensure that the data plane operation is accurate.
The control plane is responsible for communicating with
peers and building up tables for the data plane to operate
correctly.
The functions include peer updates, signaling messages,
and algorithmic calculations. The control plane functions
are typically complex and might also involve conditional
execution.
Examples of control plane protocols include the Open
Shortest Path First (OSPF), Signaling System 7 (SS7) in the
telecom world, signaling protocols like Q.933 in Frame
Relay, and so on.

The data plane is responsible for the core functions of the
system. For example, in the case of a router, the data plane
performs the IPv4 forwarding based on tables built up by
control protocols such as OSPF.
Data plane functions are relatively simple and repetitive
and do not involve complex calculations.
There is little or no conditional execution required on the
data plane. The functions on the data plane are relatively
simple and do not involve complex calculations, as in the
control plane (e.g., the OSPF protocol requires a complex
Shortest Path First calculation based on information
obtained from protocol updates).
The management plane spans across both the control and
data planes and is responsible for the control and
configuration of the system.
This is the part of the system which performs
housekeeping functions.

It also includes functions to change configuration and to
obtain status and statistics. Functions like SNMP,
Command Line Interface (CLI), and HTTP-based
management operate on the management plane.

engineering Software for Hardware
acceleration
Hardware acceleration is typically used in the data plane
and typically for fast-path processing.
Software on the data plane is responsible for initializing
the hardware used for acceleration, configuration, and
programming.
It also handles the slow-path processing.
While writing communications software for the data
plane, it is essential that we partition functionality so that
hardware acceleration can be added very quickly.
Consider an IPSec implementation.

IPSec is used in the TCP/IP world for securing
communications between hosts or between routers.
It does this via adding authentication and encryption
functionality into the IP packet.
The contents of the authentication and encryption
headers are determined by the use of security algorithms
which could be implemented in hardware or software.
An algorithm like Advanced Encryption Standard (AES)
can be implemented in a security chip, like those from
Broadcom and HiFn.
An IPSec implementation should be written only to make
function calls to the encryption or authentication
algorithm without the need to know whether this function
is implemented in software or hardware.

Software witH Hardware
acceleration—a cHeckliSt
The following is a checklist for engineering software in the
presence of hardware acceleration. The underlying
premise is that the software is modular, so it will be
efficient with and without acceleration.
Design the code to be modular so that functions in the
data plane can be easily plugged in or out depending upon
hardware or software implementation.
Separate the fast-path and slow-path implementation of
the data plane up front
Maximize performance in the data plane even if it is a
software-only implementation—it is very likely that the
software implementation is sufficient for some low-end
systems. This includes efficient search algorithms and data
structures.
Handle all exception processing in software

Ensure that interrupt processing code is efficient—for
example, read counters and other parameters from the
hardware via software as fast as possible, since they run
the risk of being overwritten.
Do not restrict the design such that only certain parts of
the data plane may be built in hardware. Network
processor devices can move several data plane functions
into software.
Ensure that performance calculations are made for the
system both with and without hardware acceleration—this
is also one way to determine the effectiveness of the
partitioning.
When interfacing to hardware, use generic APIs instead of
direct calls to manipulate registers on the controller. This
will ensure that only the API implementations need to be
changed when a new hardware controller is used.
Applications will see no change since the same API is
used.

The use of hardware acceleration is a function of the
product requirements and the engineering budget.
While it is certainly a desirable, developers should not
depend upon it as a way to fix all the performance
bottlenecks in their code.

Unit 1 introduction

More Related Content

What's hot (20)

Similar to Unit 1 introduction (20)

More from PRADEEP (20)

Recently uploaded (20)

Unit 1 introduction