Design and Implementation of a Configurable Platform for Embedded
Communication Systems
Visvanathan Subramanian, Joseph G. Tront, Charles W. Bostian, Scott F. Midkiff
Bradley Department of Electrical & Computer Engineering
Virginia Tech
Blacksburg, VA 24061-0111
Abstract
Broadband wireless technologies have the potential to
provide integrated data and multimedia services in several
niche areas. The rapid emergence of many new protocols
in this area has created a growing need to develop high
performance communication systems that can satisfy
high-end data processing requirements inherent in these
technologies within ever decreasing time to market
windows. A methodology used to develop a configurable
platform for embedded communication system designs is
discussed here. One of the applications for the
architecture requires that the device interact with a variety
of components that may communicate using variety of
different protocols. Varying geographic deployment of
the device may also require dynamic adjustment of the
operating behavior of the system hardware. Thus the
architecture is built with the ability to be rapidly
reconfigured in order to optimize its functionality and
performance.
1 Introduction
Designers of embedded wireless communication
systems face several difficult and interesting challenges
before high-level protocol descriptions can be translated
into hardware and software that implement the system.
Several issues related to access mechanisms, error rates,
transmission rates and bandwidth, need to be addressed.
The speed and complexity of these systems requires
designers to break away from traditional architectures and
design methodologies. A more comprehensive and
cohesive design process including both hardware and
software is required to overcome these challenges.
Moreover designers must also contend with rapidly
changing or evolving standards and specifications. This
requires that the target hardware platform allow
maximum flexibility to incorporate future design or
algorithmic changes. Increasing importance being given
0-7695-1926-1/03/$17.00 (C) 2003 IEEE
Proceedings of the International Parallel and Distributed Processing Symposium (IPDPS’03)
to energy considerations is another factor to be dealt with
in making architectural choices. All of these requirements
necessitate a flexible, low energy architecture and a
system level design methodology upon which novel
communication systems can be built.
The communication system application used here as an
example has several design constraints that dictate the use
of a reconfigurable architecture. One of the applications
for the architecture requires that the device interact with a
variety of other components that may communicate using
a variety of different protocols. Varying geographic
deployment of the device may also require dynamic
adjustment of the operating behavior of the system
hardware. Thus, the example architecture is built with the
ability to be rapidly reconfigured in order to optimize its
functionality and performance. The design philosophy
described herein is used to develop each of the
architectural configurations that the system reconfigures
into.
2 Platform-based Design
The emergence of a number of wireless standards like
Bluetooth [1], IEEE 802.11 [2] and IEEE 802.16 [3] has
created a market for numerous applications and products.
However, they have also taught us that the lifetime of
these products is rapidly decreasing even as the time-to-
market budgets are decreasing. One of the solutions
suggested by Ferrari et al. [4] and Kuetzer et al. [5] is
platform-based design by orthogonalization or separation
of design space concerns. Platform-based design aims to
reduce design time by facilitating reuse using abstractions
called platforms consisting of functionally unique entities
that may be used in different configurations throughout an
architecture. For example, a set of parameterizable
architectures that satisfy the constraints and support the
functional specifications of a design is called a hardware
platform. Similarly a software platform is a software layer
 consisting of the real-time operating system (RTOS) and
device drivers that allows for abstraction of the hardware
platform through an interface called the Application
Program Interface (API). The combination of the
hardware and software platforms constitutes the system
platform.
2.1 Platform-based Design Methodology
The platform-based design methodology can be
broadly classified into three phases viz., platform
conception, platform instantiation and implementation
[6]. The design flow is represented in Fig.1. ‘Platform
conception’ is the process of developing hardware and
software platforms. It is imperative that the target
application be fully understood before embarking on a
platform design. The first step in the development of a
hardware platform, functional profiling, is to identify and
extract common functionality and features of the
application domain. The next step, architecture
exploration, is to identify architectures for these functions
that would deliver adequate performance while satisfying
the constraints of the application domain. Once the
hardware platform is clearly defined the software
platform can be developed. ‘Platform instantiation’
involves mapping functionality to specific modules that
results in optimal performance under the given
constraints. The mapping process involves the
development of platforms with varying performance from
architecture modules in the system platform and then
selecting an optimal platform for the application. When
all the design constraints are satisfied, the implementation
of an application becomes software based. The
application designer only needs to focus his attention on
the application software compilation and hardware
synthesis to create an application.
Functional Design/
Feature Specification Architecture Definition
Mapping Process
Physical Implementation
Fig.1 Platform-based System Design
Methodology
0-7695-1926-1/03/$17.00 (C) 2003 IEEE
Proceedings of the International Parallel and Distributed Processing Symposium (IPDPS’03)
3 Configurable Platform Design for
Communication Systems
3.1 Functional Profiling
Functions in communication systems can be broadly
classified into data processing and control functions [7].
Most communication systems perform “packet
processing” parallel operations as well as bit serial data
processing operations. They can be further classified as
operations that modify data and those that don’t alter it.
Control functions include event processing and decision
making functions. These functions are then represented as
finite state machines that can be mapped to either
hardware or software. The functions identified are helpful
in understanding the complexity and the requirements for
the system.
3.2 Architectural Exploration
Before considering the architecture topologies, the
design space for the application domain must be
identified. In this case the design space includes general
and specialized microprocessors, digital signal processors,
programmable logic devices and custom application
specific integrated circuits. For a platform-based design
methodology to be robust it must be able to handle
application redesigns and improvements without much
change to the base platform elements. Therefore, the
platform must be built on a foundation of configurable
architecture and parameterizable elements that allow for
easy integration and scaling.
Efficiency
Custom ASIC
Hybrid
(Processor +
FPGA)
FPGA
Programmable Network/
Logic Devices Communication
DSP Processors
Microprocessor
Flexibility
Fig.2 Architecture Design Space for
Communication Designs
The simplest and most common architecture employed
in traditional designs is a microprocessor or DSP with a
 set of application specific peripherals. In this scenario all
CPU CPU Memory
the system blocks are mapped to software running on the
processor or DSP. Though this provides a lot of flexibility
the serial processing model of software-based design
limits system performance to a great extent. On the other
hand, ASICs yield very high performance but require
significant NRE cost and effort. ASICs offer no flexibility
to the designer and require tremendous redesign efforts in Peripheral Controller/
the face of changing specifications or standard updates. DMA
This makes the ASIC option unsuitable for the
development of applications that are based on standards
that have not yet stabilized or undergoing development –
Peripherals
a trend that is common in today’s industry. Further, the
ASIC offers little or no ability to dynamically reconfigure
the hardware. Given these requirements programmable
logic devices like FPGAs offer an excellent alternative. Fig. 3. Design A: Single Microprocessor
High density FPGAs and readily available configurable IP
cores provide significant performance improvement by Design A consisted of a single general-purpose
allowing designers to take advantage of parallelism and microprocessor with all functionality mapped into
pipelining processing stages. software. Even initial analysis of the design suggested
that the system would not be able to handle very high
bandwidth data processing requirements. The major
Designers can also take advantage of hybrid problem was the processor bus bottleneck and the serial
architectures involving a processor and a FPGA co- processing model. Design A was not analyzed in detail
processor to achieve almost triple performance for certain further even though it may have been suitable for lower
“cycle-intensive” operations [8]. The choice of the bandwidth applications as our goal was to identify designs
processor is crucial and determines whether a system that satisfied high bandwidth requirements.
block is implemented as hardware or software. The
processor choice also determines system parameters like
voltage levels, I/O standards and most importantly the bus CPU Memory Peripherals
protocol. The new breed of specialized network and
communication processors are ideally suited for control
and some “packet processing” operations in high
bandwidth applications and have built-in network
interfaces that simplify design.
Once the microprocessor target is identified, the
software platform, which interfaces the hardware to the
FPGA
programmer through device drivers and Application Coprocesor
Peripherals
Program Interface (API), can be developed. RTOS
choices and multiple OS support for the target hardware
platform must be weighed before developing the software Fig. 4 Design B: General Purpose
platform. Processor and FPGA Co-processor

Design B consisted of a general-purpose processor

3.3. Mapping
Various iterations (Designs A, B and C) of
the design process were considered for the
configurable hardware platform and their suitability
to the application domain was studied.
along with an FPGA co-processor. Various processors
like the i960 and PowerPC family and bus protocols were
considered. The FPGA co-processor implemented on a
Xilinx Virtex FPGA acted like a DMA controller by
moving data and reducing the processor load and by being
the flexible hardware location where various high speed
and potentially different communication protocol
operations would take place. Control operations were
implemented in software running on the processor. Some
bit-serial operations, like the modulation symbol mapping
and radio interface, were moved to hardware logic on the

0-7695-1926-1/03/$17.00 (C) 2003 IEEE

Proceedings of the International Parallel and Distributed Processing Symposium (IPDPS’03)
 FPGA in order to provide the flexibility of
reconfiguration when appropriate. This helped to simplify
the serial interfaces and also reduce bus bottlenecks.
Functional Unit Processor Program Memory
Processor Bus
FPGA
Dual Port
Memory
Processing
Element
Processor
Bus Bridge
Functional
Unit
Processing
Element
Memory Unit
Processing
Element
Fig.5 Design C: featuring a memory-
centric architecture
The third iteration, Design C, was proposed to take
greater advantage of IP core reuse and further simplifies
interfaces to promote easier integration of heterogeneous
system blocks. Essentially we analyzed the system and
identified the functions which are likely to be constant
over the expected variety of operation modes – the
functions that would never be required to be part of a
reconfiguration. In order to achieve this objective, a
“memory-centric” architecture with combination of a
Virtex FPGA and a specialized communication processor
was implemented. A shared dual-port RAM that allowed
the processor and FPGA logic to read and write data
simultaneously was introduced. Further, embedded dual
port SRAM memory available within the FPGA was used
to create distributed buffers between various processing
stages. Most control functions were implemented in
software while some critical functions like timing
references were mapped to the FPGA blocks. Also to take
advantage of the optimizations in the specialized
processor the packet processing functions are retained in
software. Many communication and network processors
were considered, but the Motorola PowerQuicc II
processor family was found to be most suitable for the
application. The Motorola PowerQuicc II 8255
communication processor [9] consists of a high
performance 64-bit, 200MHz PowerPC core and a 32-bit,
133 MHz communication processor that simplifies
0-7695-1926-1/03/$17.00 (C) 2003 IEEE
Proceedings of the International Parallel and Distributed Processing Symposium (IPDPS’03)
network interfaces with support for Fast Ethernet, ATM
and T1 / HDLC protocols. The Xilinx Virtex XCV600
FPGA [10] offers high densities up to 1M+ gates, 512
I/Os and up to 16 KB of Internal Single/Dual Port SRAM
embedded memory.
The Software Platform consists of a Board Support
Package (BSP) developed for VxWorks RTOS from
Wind River Systems and device drivers for Ethernet,
UART and other common functions. This can then be
used to generate and compile the application software.
4 Applications: Emergency Response
Communications Gateway
4.1 System Overview
This section presents the results of the application of
Functional Unit
the reconfigurable platform to the development of a
broadband wireless Gateway prototype for a rapidly
deployable LMDS wireless high-speed communications
system [11] to support emergency management. The
Functional Unit system utilizes surviving network infrastructure to
provide network connectivity to field workers in the
aftermath of emergencies or disasters for applications
such as Internet Access, Audio/Video conferencing,
Geographic Information System (GIS) access. The
network topology consists of a base station or hub and
multiple field units. Field units may be of a single type
and communication protocol, but may also be from
several different responding agencies, all with different
communications protocols. To allow the communication
interface to operate with a variety of possible protocols,
the device must be dynamically reconfigurable. The base
station has a high data rate connection to the surviving
terrestrial network. The field units provide PDAs or
laptops carried by field personnel with LAN services
ranging from 10/100 Mbps Ethernet to IEEE 802.11
wireless connectivity. A radio sounder unit is attached to
each field unit. The sounder device senses the viability of
the radio path and dynamically reconfigures the base
station and field units to change the bit rates, protocol,
etc. to optimize communication based on tolerable error
levels seen in the current channel configuration. Sounder
testing, and thus possible reconfiguration typically takes
place at the rate of once every ten seconds.
4.2 Gateway Prototype Implementation
The Gateway design implements a complex time
division multiple access MAC scheme with different
uplink and downlink frequencies on the wireless link and
an Ethernet interface on the wire line side. The TDMA
MAC protocol implements various physical layer
adaptation techniques like variable forward error
correction (FEC) and optional link level Automatic
 Repeat Request (ARQ) capability. The gateways are
capable of handling data rates up to 120 Mbps. Given the
high bandwidth required and the amount of data that
needs to be transported between blocks, the hybrid
architecture of Design C was used with processing
elements implemented partly in software and partly in
FPGA hardware. The Ethernet PHY device and RS232
transceiver directly connect to the Motorola
communication processor through standard interfaces.
The serial interfaces are implemented in the FPGA. Table
1 provides a summary of the logic resources utilized by
the design and does not include test or expansion pins.
The Motorola 60x system bus protocol used by the
processor is well defined and allows multiple masters and
cache support. The system architecture is shown in Fig.6.
FPGA Element Utilization
Number of Slices 426
Slice Flip Flops 415
4 input LUTs 622
Number of bonded IOBs 256
Number of Block RAMs 16
Total equivalent gate count 273,288
Table 1. Virtex XCV600 FPGA Device Utilization
Summary for Gateway Prototype Design
5 Conclusion
Individual system components and protocols have
been simulated and found to be satisfactory for targeted
data rates and expected channel conditions. Several of the
hardware components including the modems and the
sounder have been built and tested. The overall system
controller is currently undergoing board manufacture
testing and will be field tested in December 2002.
Using the platform design strategy, the design effort
needed to develop a platform instance such as a disaster
communications gateway prototype from the baseline
platform was greatly reduced, thereby reducing
development time for the product. This includes the time
required for performing tradeoff comparisons between
various implementations strategies as described in
Designs A,B,and C. No hardware/software design tools
were used for partitioning and exploration; the system
was implemented based on estimation of complexity of
the functional blocks. However, the effort required is still
mostly manual design and does require some design
0-7695-1926-1/03/$17.00 (C) 2003 IEEE
Proceedings of the International Parallel and Distributed Processing Symposium (IPDPS’03)
resources. This effort will be further reduced once more
intellectual property blocks are available for use in
producing the system platform.
6 Acknowledgement
The authors gratefully acknowledge the contributions
of all members of the project team, including other faculty
and students at Virginia Tech. We also gratefully
acknowledge the support of the National Science
Foundation’s Digital Government program (grant
#9983463) and the National Response Center. Generous
donations by Motorola Wireless Initiative and Wind River
Systems also aided this project.
7 References
[1] The Bluetooth Special Interest Group
http://www.bluetooth.com/
[2] IEEE 802.11 Working Group for WLAN
http://grouper.ieee.org/groups/802/11/
[3] IEEE 802.16 Working Group on Broadband Wireless
Access Standards http://grouper.ieee.org/groups/802/16/
[4] Ferrari A., Sangiovanni-Vincentelli A., “ System
Design: Traditional Concepts and New Paradigms”, Intl.
Conf. on Computer Design (ICCD 1999), 1999.
[5] Kuetzer et al., “System Level Design:
Orthogonalization of Concerns and Platform-based
Design”, IEEE Transactions on Computer Aided Design
of Integrated Circuits and Systems, Vol.9, No.2,
December 2000.
[6] Rabaey J.M., et al., “Challenges and Opportunities in
Broadband and Wireless Communication Designs”,
IEEE/ACM Conf on Computer Aided Design (ICCAD
2000). 2000.
[7] Iliopoulos M., Antonakopoulos T., “ A Methodology
of Implementing Medium Access Protocols Using a
General Parameterized Architecture”. Proceedings of the
11th International Workshop on Rapid System
Prototyping (RSP 2000), 2000.
[8] Knapp S.K., “Using Programmable Logic to
Accelerate DSP Functions”, Xilinx Inc., 1996.
[9] Motorola Inc., “MPC8255 Hardware Specifications”,
rev 0.3, May 2002. www.motorola.com/
[10] Xilinx Inc., “Virtex 2.5V Field Programmable Gate
Arrays”, Product Specifications v2.5, April 2001.
www.xilinx.com/
[11] S. F. Midkiff and C. W. Bostian, “Rapidly-
Deployable Broadband Wireless Networks for Disaster
and Emergency Response”, First IEEE Workshop on
Disaster Recover Networks (DIREN '02), 2002.
 100 Mbps 10/100 Mbps Media
Ethernet Ethernet PHY Independe
nt Interface Motorola
(MII) PowerQuicc II
Host RS 232 Processor
Interface Transceiver
EEPROM
SDRAM
/Flash

60x Processor Address Bus (32)

60x Processor Data Bus (64)

Reed DUAL PORT

Solomon SRAM
Codec
Xilinx Virtex
FPGA

Turbo Codec Radio

Interface

Fig.6 Physical Implementation of Disaster Response Gateway Prototype

0-7695-1926-1/03/$17.00 (C) 2003 IEEE

Proceedings of the International Parallel and Distributed Processing Symposium (IPDPS’03)