2009

2009 International
International Conferences on Embedded
Conference on Embedded Software
Software and
and Systems
Systems

A Co-Design Flow for Reconfigurable Embedded Computing System

with RTOS Support
Xiao-Wei Wang, Wei-Nan Chen, Ying
Wang, Cheng-Lian Peng Xiao-Wei Wang
School of Computer Science and Technology Shanghai Branch Navy Equipment Technology
Fudan University, Shanghai, China Institute, Shanghai, China
Email:{051021035,clpeng}@fudan.edu.cn
Abstract--Reconfigurable system provides both within the FPGA, which presents intriguing
possibilities for novel system architectures and
flexibility of software and performance of
applications. So, over the past decade, the
hardware. It is a significant trend in embedded reconfigurable computing platform has been an
application domain. Some new reconfigurable emerging approach in scientific research and in
technologies and technology-dependent tools have practical application to meet these requirements
[2]. The design and implementation of dynamic
been developed, but the whole design flow for
reconfigurable systems (DRSs) is exceptionally
run-time reconfigurable systems with real-time challenging.
operating system support is not proposed. RTOS The hardware/software unified RTOS
process ensures portability of the co-designed
plays an important role in the system and the
reconfigurable embedded computing applications
co-design flow. The special requirements for and minimizes the performance loss by providing
reconfigurable embedded systems with RTOS standardized means of interfacing and unified
effective programming model [3]. But ˈ the
support are analyzed, and a novel co-design flow is
co-design flow for the reconfigurable embedded
proposed in this paper. A design case is presented systems with the RTOS support was not
here, which shows the co-design flows of the proposed. We analyzed the special requirements
implementation of an adaptive signal filtering for such systems and proposed co-design flow in
this paper.
system on a commercially available reconfigurable
This paper is organized as follows: related
platform. The results show that using run-time work will be presented in section2. Section 3 will
reconfiguration can save over 66% area when discuss the special requirements of design flow
for reconfigurable embedded computing with
compared to a functionally equivalent fixed system
RTOS support. Our co-design flow will be
and achieve 24 times speedup in processing time presented in section 4.Section 5 will describe the
when compared with a functionally equivalent adaptive filtering system using commercial
off-the-shelf reconfigurable devices and the
pure software design.
results will be presented. Finally, the conclusions
.Keywords: Reconfigurable embedded computing
will be given in Section 6.
system, Co-Design Flow, RTOS Support, unified
hardware task interface II. RELATED WORK
I. INTRODUCTION The traditional design flows for mixed
hardware-software embedded systems are to
Modern embedded systems such as select architecture, decide where in the
consumer appliances and military devices present architecture different pieces of the application
ever-increasing computational power, flexibility, will be implemented, design the hardware and
easy-to-upgrade and easy-to-maintenance software pieces, and finally integrate the pieces
requirements amidst tight budgets and Space, together [4,5].If the design criteria are not met,
Weight, and Power (SWaP) challenges[1]. the functionality, architecture, and mapping can
Modern SRAM-based FPGAs can be be modified6, 7]. System-level design covers
dynamically and partially reconfigured at runtime, various issues, such as partitioning, task
without interrupting the operation of other logic

978-0-7695-3678-1/09 $25.00 © 2009 Crown Copyright 465

467
DOI 10.1109/ICESS.2009.84
scheduling, and synthesis. An SW/HW reconfigurable technologies of different
partitioning and online task scheduling approach
is presented [8][ 9].
Nikolaos S.Voros and Kondtantinos Masselos
described the system level design of
reconfigurable system-on-chip [5], but they did
not include the co-verification of the dynamic
part of the reconfigurable system and they
neglected the difference of the systems with real
time operating system support. Most of the
co-design methods were missing OS layer
abstraction for reconfigurable application [10]. Figure1. A generic system-level design flow

David Andrews proposed unified

types and vendors at abstract level, and designers
multithreading programming model for operating
need to include them in the architecture models.
system support and implemented some critical
System partitioning needs to analyze and
operating components in hardware such as mutex
estimate the functions of the application for
and signal semaphore. But they did not discuss
software, fixed hardware, and reconfigurable
the design flow of the reconfigurable system [12].
hardware. The parts of the targeted system that
Zhoubo proposed unified multiple task
will be realized on reconfigurable hardware must
programming model and implemented a
be identified.
operating system prototype using ucosII for
In hardware/software partitioning and
reconfigurable platform,but did not proposed
mapping phase, for reconfigurable computing, a
implementation flow for partial reconfigurable
new dimension is added to the problem. Which
system[15].Xilinx proposed early access partial
part of the system that will be implemented on
reconfiguration implementation flow, but it did
reconfigurable hardware must be identified
not include system co-design flow[18].
according to the specification If the application
We proposed the co-design flow for
has several roughly same hardware accelerators
embedded reconfigurable computing system with
that are not used in the same time, a dynamic
RTOS support based on the analyses of the
reconfigurable block may be a more optimized
special requirements including system level
solution .If the application has some parts in
design flow, detailed design and implementation
which specification changes are foreseeable, the
flow.
implementation choice may be reconfigurable
III. SPECIAL REQUIREMENTS OF CO-DESIGN hardware. If there are foreseeable plans for new
FLOW FOR RECONFIGURABLE COMPUTING generations of application, the parts that will
SYSTEMS change should be implemented with

A. special requirements for system-level reconfigurable hardware.

design B. special requirements for detailed design

A generic system-level design flow is In this phase, the individual portions of
showed in figure1 [5].In system specification hardware, software and reconfigurable hardware
phase; designers need extra effort spent on are designed and verified. Reconfiguration
identifying parts of the application that server requirements include communication mechanism
as candidates of implementation with for software and static hardware and
reconfigurable hardware. In architecture reconfigurable mechanism to handle context
definition phase, designers need to model the multiplexing.

468
466
 The integration and co-verification combines task interface, efficient communication methods
between tasks and optimized allocation and
the reconfigurable hardware components with
partition algorithms for reconfigurable hardware
other hardware and software components into a resource .The co-design flow must consider
single platform, which also accommodates hardware resource that will be used for operating
external IP and provides co verification of overall system components and software interface for
reconfigurable hardware modules.
design. The reconfigurable hardware is simulated
in a HDL simulator or emulated in an FPGA IV. CO-DESIGN FLOWS FOR
emulator. Specific HDL modeling rules need to RECONFIGURABLE COMPUTING WITH RTOS
be followed for multiple dynamically SUPPORT
reconfigurable contexts. The reconfigurable The co-design flow for reconfigurable
hardware modules must be implemented using embedded computing system is different from
the specified technology, including the required conventional hardware/software co-design flow
control and support function for reconfiguration. and it is also different from the conventional
C. The special requirements for co-design flow for reconfigurable system-on-chip.
implementation design The programming model and unified

Dynamic reconfiguration requires reconfigurable hardware module interface have

configuration bitstreams of multiple contexts to to be considered before discuss the operating
be managed. Specific design rules and constraints system for reconfigurable system.
must be followed for multiple dynamically
reconfigurable modules. Reconfiguration A. Hardware and software unified multiple
overhead is determined by configuration task programming models
bandwidth, frequency, and configuration
granularity in the design. The generation for In conventional co-designed system, FPGAs
partial bitstream files depends on the specific are used as hardware accelerator. User
tools. If Xilinx’s FPGAs are used, we need
application program directly manage and use
Xilinx’s partial reconfigurable tools and have to
obey the partial design flow to generate partial them. Without reconfigurable hardware resource
reconfigurable bitstream files. abstract and resource management,
D. The special requirements for OS support reconfigurablity and task potential parallelism

The use of a runtime resource allocation unit can not be used sufficiently. The conventional
will get the full benefits of dynamic RTOS have to be improved for the
reconfiguration on high density FPGAs. In reconfigurable embedded computing system. A
addition to runtime resource allocation, other
unified multi-task model (as POSIX thread
services provided by an OS such as abstraction of
I/O and inter-applications communication will specification) was widely accepted. Under the
provide additional benefits to the users of a model, the hardware function modules are
reconfigurable computer. This will reduce the viewed as hardware tasks, and the RTOS
difficulty of application development and
deployment. Reconfiguration result in the manages hardware tasks as well as the software
complexity of the system control requires RTOS ones. The RTOS for RC provides unified
for synchronization, communication, and application program interface (API) and
concurrency management. OS for RC provides
the following capabilities: transparent hardware necessary hardware components, which makes it
and software communication services and easy to communicate between function modules,
configuration management. Another important including communication and synchronization
RTOS advantage is the abstraction to increase
between tasks. Because it is naturally transferred
portability and to facilitate reuse of code and
repartitioning. from conventional method, it is easy to be
RTOS for reconfigurable computing system accepted by designers.
needs effective programming model, appropriate
abstraction of hardware tasks, unified hardware

469
467
B. Unified hardware task interface library parameters according to system’s structure and
To enable the RTOS to effectively manage application requirements. UHIF combine with
hardware tasks, special functions have to be user hardware task as macro module. A set API
added to the implementation of the hardware. functions are proposed to make it easy to use
Hardware units respond to the basic hardware tasks as usual software task.
communication primitives. We proposed a set of C. RTOS for reconfigurable computing system
virtual hardware task interfaces, which compose
RTOS introduces an abstract layer between
unified hardware task interface (UHIF) library to
the application designer and the systems
satisfy the requirements of typical data
software. The software part of RTOS for
stream-based applications. The interfaces can
reconfigurable system includes the software task
adjust

Figure 2. co-design flow for reconfigurable system with RTOS support

470
468
interface, task scheduler and resource manager. can be captured, which make it easy to
The hardware part of RTOS is called the schedule .The reconfiguration way is determined
hardware task manager, usually implemented on by the reconfiguration specification.
the FPGAs, including the communication 2) Detailed design
controller, standard hardware-task interface, The specifications are refined and verifications
configuration interface and hardware-task are planned according to target implementation
configuration controller. technologies and processors type etc .The
hardware designs include system circuit board
Linux is widely used in real time embedded
and FPGA hardware design. For the unified
application. We improved it for reconfigurable
management of the hardware tasks and software
system based on FPGAs by extending the
tasks, HW/SW unified interfaces are needed. The
standard Linux kernel to support dynamic
interfaces stride on the boundary between the
reconfigurable embedded system. The services of
reconfigurable hardware tasks and the software
RTOS are provided to deal with input and output,
tasks. Software includes operating system
load and execute pre-designed circuits. User
components for reconfigurable hardware design
application processes can therefore be either
and application. We improved linux2.6.24
software programs running on processors, or
version kernel, a part of the standard kernel is
hardware implementations running on FPGAs.
improved and drivers are added. Because the
We term hardware implementations on FPGA as
reconfigurable embedded system with operating
hardware tasks. RTOS maintains a consistent
system is more complex than usual embedded
unified interface for both software and hardware
system, every part should be verified respectively,
processes. Therefore, to the rest of the system,
such as FPGA design and verification, software
communicating with a hardware process is no
design and verification. The base design of
completely different from communicating with a
FPGA is the static part of the reconfigurable
normal software process. This homogeneous
system on which the operating system and
handling of hardware and software in the kernel
application program run. The application
forms the foundation of coarse grain
software must verify on operating system.
hardware/software co-design boundary.
The implementation flows of reconfigurable
D. Co-Design Flow for reconfigurable system are tedious, and it is hard to debug
computing system with RTOS support reconfigurable hardware. So, the correctness of
1) System level design reconfigurable hardware must be ensured. Each
The requirements including RTOS are version of the hardware task must be verified in
captured and analyzed in the specification phase. static condition. That is to say, in order to ensure
The results are fed to the next phase of design the correctness of the function and the timing
flow. In the partitioning phase, the function of order, every reconfigurable module must be
application is partitioned in software, hardware integrated into the system as a static part to be
and reconfigurable modules. The operating verified and tested before it is used as
system support is one of the most important parts reconfigurable hardware task.
of software under unified multi-task The co-verifications integrate the
programming mode. In higher abstraction level, a reconfigurable hardware tasks, static hardware,
reconfigurable module is viewed as a task of the and software components into whole system. The
RTOS to schedule. co-verification environment is provided for the
System-C and MATLAB can be used to create overall design. The reconfiguration parameters
the system model. By running the model, enough are inserted into the co-verification phase. Some
information of the communication between tasks commercial tools such as

471
469
MATLAB,CoDeveloper and synthesis tools are
used to co-verify the design.
3) Implementation design
In implementation design phase, the
embedded system components containing circuit
board, FPGA configuration bitstream files, OS
images and application software executable files
are prepared. If commercial devices are used, the
bitsreams files of hardware tasks will be
generated by the device provider’s tools. If
Xilinx virtex family FPGAs are used, designers
Figure 3 Adaptive filtering system
may use the modular based design flow to
generate all the bitstreams of the FPGA and use The specification of the application is clear. It
Xilinx embedded development kit(EDK) to is adaptive filtering system for sound signal. The
compile software, generate board support sample frequency, high passes frequency, and
package(BSP) for RTOS and combine the low pass frequency are pointed out clearly. The
hardware and software into one image file. flexibility requirement for the application is to
The unified interfaces are inserted into the adaptive different signals. In system level design,
system as IP cores in embedded development kit. we capture the reconfiguration requirements that
The hardware’s bitsreams and software’s images were to satisfy the flexibility and performance.
are downloaded to FPGA to verify, and the To make it easy to port the application and share
dynamic reconfigurable tasks are verified by the FIR and other hardware resource, RTOS is
downloading into FPGA through configuration required.
port such as Xilinx’s SelectMap,ICAP,JTAG etc.

V. . A CASE: CO-DESIGN FLOWS FOR

ADAPTIVE FILTERING SYSTEM-ON-CHIP

A. application and target platform

We use a real case to demonstrate our design
flow for reconfigurable embedded system with
RTOS support. The design case is an adaptive
filtering design that targets to meet all the
objectives (low pass, band pass, and high pass)
on the Xilinx virtex-5 (XC5VLX50T-FF1136) Figure4 Two PRRs in the system FPGA Editor View
FPGA on ML505 board. The application and PlanAhead Device View
architecture shows in figure 3. The FIR filters are Adaptive filtering system implemented by a
special kinds of digital filters and have a wide reconfigurable hardware. The FIR filters may
applicability because they have a good need a large number of resources to satisfy the
characteristic such as linear phase and stability. desired specification. The partial reconfiguration
They are employed in the majority digital signal technique can be used in this case since the
processing (DSP) based electronic systems. various types FIR filters have so many
B. system design and implementation similarities in their structure. Therefore, partial
reconfiguration addresses the reduced
reconfiguration overhead, coefficient flexibility

472
470
and area efficiency for higher order FIR filters. times faster than pure software implemented
Reconfigurable FIR filter offers both the FIR.
flexibility of computer software, and the ability
TABLE I. RESOURCE REQUIRES FOR FIR
to construct custom high performance computing
circuits. Resource Reconfigurable Static
We selected Mircoblaze7.0b with MMU Type Requires Requires
support because the system needs RTOS. We LUT 849 2547
improved uclinux to make it support RC. All FF 1346 4038
versions of FIR (low pass, high pass and band SLICEL 291 873
pass FIR) were generated in MATLAB with SLICEM 120 360
System Generator, which can create DSP48E 16 48
cycle-accurate and bit-accurate model for DSP RAMBFIFO 0 0
application and co-simulate the hardware and
software model. After successfully simulated, we TABLE II. EXECUTION TIME

integrated the FIR module with the base system Software FIR 79849600 cycles 631.5ms
of the FPGA and connected the FIR with
Hardware FIR 3240105 Cycles 25.9ms
Microblaze by unified hardware task interface
Speed up 24.38
After base design completed, the improved
uclinux was ported into the system to verify the TABLE III. CONFIGURATION TIME
RTOS and application software.
Reconfigurable Hardware 6374683cycles 50.997ms
We used Xilinx’s EAPR flow to generate the
FIR
partial bitstreams of the different version of FIR
with different parameters. We verify the partial
bitstreams by download to FPGA through JTAG C. Comparisons with other approaches

port. Application software was downloaded to In addition to partial reconfigurable

FPGA to test and verify the configuration implementation, a fixed hardware
function. Then,RTOS image combine the implementation and pure software
bitstream file of the static full to generate ace file implementation were made as a reference design.
to verify the RTOS in reconfigurable system. In the fixed hardware implementation, the
The next step, we co-verified the partial processing blocks were mapped onto static
reconfigurable modules and the software with accelerator and 3 versions of FIR requirs triple
RTOS. Two partial reconfigurable regions (PRR) resources as table1 shows. That is to say, we
placed in the system as figure 4 shows. There are saved about 66% of the resources for adaptive
3 reconfigurable modules (PRMs) for each PRR. FIR by reconfiguration.
The most resources required for FIR are listed in For the full software implementation, the
table1, and the executing time cost for FIR is design was implemented as an application on
listed in tableII The configuration overhead are linux, and the data are transferred through FSL
listed in table III. bus using Xilinx Microblaze customized
We used one third of resources to implement instructions. All ran on Microblaze at 125 MHz,
the three versions of FIR by dynamic partial data store in BRAM and the RTOS and
reconfiguration. The processor Microblaze ran at application software ran in DDR2.The processing
125MHz.We tested the time cost including data time of one data was 631.5ms, which was over
transfer time for FIR computing using timer at 24 times of the processing time in partial
125MHz, reconfigurable hardware FIR ran 24 reconfigurable case.

473
471
 [7] Florent Berthelot,Fabienne Nouvel,and Dominique
As we know, reconfigurable hardware tasks Houzet 㧘 A Flexible System Level Design
need to be reconfigured when the scene changed, Methodology Targeting Run-Time Reconfigurable
FPGAs, Volume 2008.
while the software implementation only need few [8] B. Knerr, M. Holzer, and M. Rupp㧘 RRES: A Novel
cycles to jump to another process. We use Xilinx Approach to the Partitioning Problem for a Typical
Subset of System Graphs,Volume 2008
internal configuration access port (ICAP) to [9] Chun-Hsian Huang,Pao-Ann Hsiung,
Software-Controlled Dynamically Swappable
implement dynamically reconfiguration. Hardware Design in Partially Reconfigurable Systems,
Volume 2008,
VI. . CONCLUSION AND FUTURE WORK [10] S´ebastien Pillement, Olivier Sentieys 㧘 DART: A
Functional-Level Reconfigurable Architecture for High
The main advantages of reconfigurable Energy Efficiency, Volume 2008,
[11] Aric D. Blumer and Cameron D. Patterson 㧘
embedded system with RTOS support are the Exploiting Process Locality of Reference in RTL
combined flexibility, performance, portability Simulation Acceleration, Volume 2008
[12] WeiWang,Qiang,WuWei,Hardware Software
and resource sharing. The implementation this Co-design for Dynamic Reconfigurable Computing
with Collaborative Supports of Architecture and
kind of system requires extra efforts in every Operating System, Proceedings of the 2007 11th
design stage. In this article, we present a design International Conference on Computer Supported
Cooperative Work in Design
flow for reconfigurable system with RTOS [13] Kamana Sigdel, Mark Thompson, Andy D.
support, which combines design support at Pimente,Todor Stefanov,System-Level Design Space
Exploration of Reconfigurable Architecture,
system level for partitioning and mapping, Springer-Verlag Berlin Heidelberg 2008
[14] Carlos Paiz, Boris Kettelhoit, and Mario Porrmann, A
programming model, unified hardware task design framework for FPGA-based dynamically
interface library. A set of FIR filter are used in reconfigurable digital controllers, 1-4244-0921-7/07
2007 IEEE.
case study. Compared to completely fixed [15] Zhou Bo, Wang Shiji, Qiu Weidong, SHUM-UCOS: A
real-Time operating system for reconfigurable systems
hardware implementation, reconfiguration using uniform multi-task model [J]. Journal of
reduced over 66% of resource; compared with Computers, 2006, 29(2): 208-218 (in Chinese)
[16] Zhou Xuegong,LiangLiang,Huang Xunzhang,On-line
full software implementation, reconfiguration is scheduling and placement of real-time tasks for
over 24 times faster. The commercial reconfigurable computing system [J]. Journal of
Computers, 2007, 30(11): 1901-1909 (in Chinese)
off-the-shelf FPGA platform caused limitation [17] J.A.Williams and N. W. Bergmann, "Embedded Linux
as a platform for dynamically self-reconfiguring
on the implementation of dynamic systems-on-chip," in Proc. Int. Conf. on Engineering of
reconfiguration. If we added the configuration Reconfigurable Systems and Algorithms (ERSA '04),
Las Vegas, Nevada, 2004.
overhead, the speed ratio down to 12.We will [18] Xilinx,”VirtexII FPGA platform
datasheet”,May,2007,http://www.xilinx.com
improve our system to reduce the configuration
overhead in the future.

. REFERENCE
[1] John Wemekamp, Emerging Trends in Mil/Aerospace
Embedded Systems,Controls Embedded Computing
Ecnmag.com May 01, 2007
[2] Tarek ElGhazawi, Esam ElAraby, and MiaoqingHuang,
The promise of high-performance reconfigurable
computing, Computer, February, 2008
[3] David Andrews, Ron Sass, Erik Anderson, Achieving
Programming Model Abstractions for Reconfigurable
Computing, IEEE transactions on very large scale
integration(VLSI)system, VOL. 16, No. 1, January,
2008
[4] IAN ROBERTSON and JAMES IRVINE,A design
flow for reconfigurable hardware, ACM Transactions
on Embedded Computing Systems, Vol. 3, No. 2, May
2004, Pages 257–283.
[5] NikolaosVoros,Knostantinos,Masselos, system level
Design of reconfigurable
Systems-on-Chip,2005,Springer
[6] Yang Qu,Kari Tiensyrj Juha-Pekka Soininen,and Jar
Nur 㧘 Design Flow Instantiation for Run-Time
Reconfigurable Systems: A Case Study㧘Volume 2008

474
472