Design Methodology and Tools for Wireless System Design

Jan M. Rabaey
Berkeley Wireless Research Center, University of California, Berkeley
(510) 643 8206
jan@eecs.berkeley.edu

ABSTRACT
The remarkable breakthrough that wireless systems have experienced in the last decade seems to be
only the first wave of a wireless revolution that will have a profound effect on industries such as commu-
nications, computing, and consumer. The underlying premise is that wireless will be the preferred way
of connecting various electronic devices and systems. Designing the optimized radio modules that sup-
port the range of applications, services, and bandwidths while staying cost-effective proves to be a
major challenge and requires an integrated design flow augmented with the appropriate tools. This pre-
sentation will forward a vision on how such a flow could be constructed.

INTRODUCTION
The advent of the first and second generation wireless systems has firmly established wireless
connectivity as a viable alternative to wired connections in the domain of voice communica-
tions. Today, we are on the threshold of a far more penetrating introduction of wireless technol-
ogy in our daily lives. The third-generation wireless systems will add high-bandwidth data
transmission to the cellular environment, hence making ubiquitous internet access a definite
possibility. On the other side of the spectrum, initiatives such as Bluetooth pave the way for
another range of applications that can ultimately lead to effortless communication between a
wide range of appliances, sensors, control and display devices (as would for instance be needed
to construct a “smart home”). From this bewildering range of opportunities emerges an under-
lying need for cheap and low-energy radio connectivity. Depending the applications at hand,
the required radio’s present a wide spectrum of requirements in terms of service model, band-
width, flexibility, energy and cost. Rather than building a single radio that fulfills all these
needs, it is our projection that there will be a sustained need for “application- or domain-spe-
cific radio’s”, optimized for the application at hand.
Unfortunately, designing integrated radio’s is non-trivial. Some of the reasons why this is so are
summarized in Figure 1. A typical radio combines a profound mix of design paradigms and
technologies: RF, analog, and low-energy digital (in other words true mixed-mode design),
hardware- and software, and data- and control flow, operating over a wide range of data and
time granularity. The design has furthermore to adhere to a series of stringent cost metrics. As
such, radio’s present one of the first and most challenging applications for true hybrid systems-
on-a-chip. Observe that this discussion in this paper focuses only on the radio terminal, and
ignores the additional complexity imbedded in the basestation and networking components of a
wireless system.
To make the concept of the ubiquitous radio become true requires the development of a com-
prehensive design methodology that enables correct design in a short design cycle, while trad-
ing off between the various cost metrics (such as flexibility, area and energy). Given the
complexity of the above task, such an ambitious flow can only be successful if it relies on the
 FIGURE 1. Radio design combines data- and control flow, and addresses a wide range of data and time
granularities.

following three basic underpinnings:

• The design process should to a maximum extent rely on reusable modules. Reuse helps to raise the level
of abstraction and simplifies the composition task, encapsulating the “nitty-gritty” details within the con-
fines of a module.
• The design process has to be raised to higher levels of abstractions, that match well with the functions to
be implemented and that allow for early verification. Starting the design process with C and/or VHDL
descriptions bounds the design exploration space, leading to suboptimal solutions. At the same time, it
makes the design verification process substantially harder.
• Rather than supporting every possible implementation platform and combination of processing module,
the design methodology must have build-in constraints and present a clearly defined model of computa-
tion and architectural vision.
Based on these concepts, we have formulated a comprehensive design methodology, as pic-
tured in Figure 2. While this picture seems to be overly complex (a reflection of the task at
hand...), it adheres strictly to the concepts outlined above: it starts a very high level of abstrac-
tion, provides a clear interface between behavior and structure (which is essential for effective
reuse), and presents a limited number of implementation architectures (and their interfaces). In
the rest of the presentation, we will highlight some of the aspects of this design flow. The focus
will be on the higher abstraction levels as we believe that this is where the higher benefits will
be reaped.

SYSTEM LEVEL SPECIFICATION AND VERIFICATION

Specification
System design usually starts with a high-level model of some kind (boxes on a napkin, for
example) and proceeds through a process of refinement, simulation or emulation, verification,
implementation, and test. Much of the process is ad-hoc: the boxes on the napkin become sche-
 FIGURE 2. Overview of Wireless System Design Flow

matic blocks or code segments; the schematics and code are hand-generated while the napkin
wipes up the spilled coffee and gets tossed in the trash. By the time all the gritty details of
implementation are taken care of continuity with the original system description has pretty
much been lost, causing a lack of design oversight (the big picture) and a surplus of one-time-
only design artifacts (code, hardware, etc.).
To combat the ad-hoc nature of the system design process, we propose a design flow that relies
heavily on abstract object-oriented modeling techniques (OMT) [4]. High-level abstract models
based on object technology can be an excellent starting point for complex mixed hardware and
software system design. Models of this type offer graphical representations and present various
degrees of formality in both functionality and communication semantics. This formality lends it
self well to system verification, and the object nature of the model creates the opportunity for
design reuse. Out of the possible options, we have embraced UML as the vehicle for the infor-
mal phase of the specification process. The Unified Modeling Language (UML) is a standard-
ized formalization of OMT, that has emerged from the object-modeling community, and was
originally intended to be used in the early development phases of large software projects [5]. It
is our belief that the concepts of UML are applicable to a much wider scope of design problems,
in this case a mixed hardware-software design.
 Use cases

Sequence Diagrams

Class Definitions

FIGURE 3. Snapshot of UML description of Digital Intercom System, using the Rational Rose environment.

A design process based on UML starts

User with a capturing of the design require-
Interface
ments (“requirement analysis”) and the
relations between the system to be
voice commands/
status Permissions
designed and the external world. One way
Database of describing these interactions is through
control System “use cases”, which enumerate the typical
Control scenario’s that the system will execute
Slot Set
Database [2]. An example of the early specification
slotset of a digital intercom system, that we have
Data Path/ enable/
designed in Berkeley, is shown in Figure
Physical and disable Media Access 3. These initially vague requirements are
Link Protocols Control (MAC)
iteratively defined till a more precise def-
radio channel inition of the system modules and pro-
cesses, their interactions and
Slot
Database
dependencies is derived. For example, a
more defined object-diagram of the digi-
tal intercom is given in Figure 4. The dia-
FIGURE 4. OMT model of digital intercom and its
components. gram is simple, yet it includes all of the
major structural blocks and their relation-
ships with each other. A simple line represents a one-to-one relationship (association) while the
circles add multiplicity (zero or one). A line with a diamond represents an aggregation, or com-
position, relationship i.e. the objects attached to the line are parts of the object next to the dia-
mond. Shaded areas represent the “environment”, or parts of the intercom outside of this model.
As we progress further into the modeling process, refinements should conform to this drawing.
If they cannot, the system analysis needs to be reconsidered.
At this point we have the general system structure without detailed semantics. For instance,
what is the form of communication on an association, and what information does the communi-
cation convey? How are elements in an aggregation connected, and what information do they
exchange? The choice of the semantics to effectively describe a component or interaction
between components depends heavily on its nature. While modules in the radio’s transport
channel are better described using dataflow semantics, protocols and asynchronous module
interactions are more readily modeled using communicating finite state machines. At this point,
it makes perfect sense to partition the design based on this differentiation and use environment
that are uniquely geared to each of those models.
One may wonder if the partitioning will introduce an extra requirement for co-simulation and
co-verification. In our experience, this is not a real necessity at this abstraction level. Both
domains are substantially different in their goals and requirements. At this point, having a clear
and explicit definition of the interfaces between the dataflow and control domains comple-
mented with an abstract definition of their behavior is a sufficient and necessary condition.
Protocol Specification and Verification
The UML object model can be extended with a semantic backbone to yield a protocol specifi-
cation and verification environment: the Specification and Description Language (SDL) [1].
SDL is a mature technology that was originally developed for protocol definition. In 1992, OO
concepts in the style of the OMT model were integrated into SDL. For our system, we are using
an SDL methodology called SOMT, for SDL-Oriented Object Modeling Technique. Figure 5
shows a revised view of Figure 4 in SDL with message paths for system control and MAC pro-
tocols shown in more detail. The environment has been abstracted away. This drawing is the
first stage of SDL development - it is a complete description of system structure and message
semantics at the top level.
In SDL, dynamic behavior is described by a state diagram. In addition to providing documenta-
tion, the diagram (along with message semantics) gives us the ability to actually execute the
model, i.e. track control through procedures and flow constructs given input (messages) from
the environment. State space exploration (verification) is another possibility. Both of these
techniques can be used to test the models function and correct many errors at what is still a high
level, before targeting to specific technologies begins. Also important is that the clear semantics
of the model drastically simplifies the design synthesis process.
Data Transport Channel
While some form of communicating finite state machine model presents the perfect choice for
protocol specification, the data transport channel (with a more-or-less stream oriented nature) is
more readily captured in a dataflow paradigm. Observe that at this level of abstraction, no real
difference exists between analog and digital modules. The dataflow domain has received major
attention over the last decade(s), and tools such as SPW and Ptolemy have helped to popularize
the concept. The problems with these environments is the lack of linkage to either the higher-
order descriptions of communication algorithms (which are typically expressed in algebraic
format) and to implementation. It is our belief that Matlab (from MathWorks) presents a mean-
 FIGURE 5. Top-Level SDL
description of Digital Intercom
protocol. Message names are
shown within brackets near the
path to which they are assigned.
Message sets are in parentheses:
REMRX (all signals received by a
Remote), REMTX, BSRX, and
BSTX.

ingful alternative that addresses most of the above issues. First of all, the algebraic component
of Matlab is the tool of choice for most communication system designers. Secondly, the SIM-
ULINK layer presents a clean block-level dataflow description environment. Finally, it pro-
vides all the necessary hooks for linkage to implementation (such as finite precision and netlist
export). As an example, Figure 6 shows the algorithmic block diagram of a wideband-CDMA
adaptive correlator [6].

FIGURE 6. Dataflow description of wideband CDMA adaptive correlator.

DESIGN SYNTHESIS
The advantage of the unambiguous semantics is that enlightened hardware mapping (or archi-
tecture selection) and (semi-)automatic synthesis is more readily achieved. Once again, we dif-
ferentiate between the control- and dataflow components.
Architectural Mapping
This area has achieved much
attention in recent years.
Selecting the right architecture
for a component of a design
requires the presence of exten-
sive performance and energy
models so that the decision can
be based on quantitative infor-
mation. One of the premier
tools in this area is the Felix
environment, that is currently
under development at Cadence
[8]. Felix allows for the simul-
taneous definition of both
behavior (in a mixed CFSM-
dataflow format) and the target
architecture (Figure 7). Adding FIGURE 7. Example of hardware mapping process in Felix. Selected
associations between the two pieces of behavior are associated with specific hardware modules
makes it possible to perform
rather accurate performance and energy estimations.
Protocol Synthesis
With an appropriate hardware platform selected, we can commence the synthesis process. The
actual flow differs substantially depending upon type of source code and the choice of the plat-
form (software executed on a micro- or DSP processor, ASIC accelerator module, or reconfig-
urable array) (Figure 8). When a software solution on a processor is considered, it is possible to

SDL
design flow disconnects
(Telelogic) (hand translations) in italics

generated ‘C’ code

hand translation
hand generated
OS interface and
Env functions SMV Synchronous FSMs

compiled library
VHDL
OS
(Custom)
ASIC or FPGA
Synthesis
Processor

FIGURE 8. Protocol synthesis flow

automatically generate executable C-code from the original SDL description. On the other
hand, the situation is substantially more complex when an ASIC or FPGA target is selected [7].
The main problem is that SDL presents an asynchronous FSM model, while virtually all hard-
ware implementations present a synchronous FSM paradigm. The mapping from one to the
other is a non-trivial and ambiguous operation, that either requires user guidance or requires
some constraints on original SDL description. As a result, the step from SDL to Synchronous
FSM is currently performed manually. Once a synchronous description is obtained, both formal
verification (using SMV [3]) and automatic synthesis to implementation are possible.
Data Transport Channel
Similarly, many implementation routes exist for the
dataflow component of the radio. One of the options
is to produce C- or assembler code for a program-
mable DSP processor. Another option is to directly
produce a control-dataflow graph that serves as the
input for a wide variety of behavioral synthesis
tools, as well as description of choice for reconfig-
urable architectures such as the Berkeley Pleiades.
Another option is to directly generate a module
netlist, which is rather easy to do if the chosen
architecture is a one-to-one mapping of the algo-
rithm (which is very often the case when an ASIC
implementation is chosen). The MathWorks Sim-
ulink environment allows for a direct export of the
functional netlist into an EDIF format, including an
expansion of the high-level data types into signal
busses. For example, Figure 9 shows an expanded
netlist view of the adaptive correlator of Figure 6.
FIGURE 9. Netlist of CDMA correlator This netlist can then be directly fed into logic syn-
datapath, as generated from SIMULINK
description.
thesis tools or datapath compilers. Observe also that
a one-to-one mapping into predefined library mod-
ules is the typical approach for the analog sub-functions.

Summary
In this paper, we have proposed a high-level design flow for the design of wireless system. The
key aspects of the flow include
• Raising the abstraction level and introducing (in)formal capturing techniques at the earliest time in the
design process.
• Clear distinction between the control- and dataflow components of the radio, and the use of the appropri-
ate modeling, verification, and synthesis approaches.
• The use of well-defined and encapsulated implementation platforms and maximum utilization of reuse.
While the picture sketched above is experimental and far from complete, it is our belief that a
structured approach of this style is essential if ubiquitous wireless connectivity is to become a
reality.
Acknowledgments
The author would like to acknowledge the contributions of Robert Brodersen, Fred Burghardt,
Chunlong Guo, Jim Rowson, and Brian Limketkai to this paper.

References
[1] J. Ellsberger, D. Hogrefe, A. Sarma, SDL: Formal Object-oriented Language for Communicating Systems,
Prentice-Hall, 1997
[2] I. Jacobson, M. Christson, P. Jonsson, G. Overgaard, Object-Oriented Software Engineering: A Use Case
Driven Approach, Addison-Wesley, 1992
[3] K. McMillan, Symbolic Model Checking, Kluwer,1993
[4] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen, Object-Oriented Modeling and Design, Pren-
tice-Hall, 1991
[5] M. Fowler et al., Uml Distilled: Applying the Standard Object Modeling Language, Addison-Wesley, 1997.
[6] Ning Zhang, Craig Teuscher, Hungchi Lee, Bob Brodersen, “Architectural Implementation Issues in a Wide-
band Receiver Using Multiuser Detection”, Proceedings 36th Allerton Conference on Communication, Control,
and Computing, Urbana, Sept. 1998.
[7] F. Burghardt et al., “System Design Using Object Modeling Techniques: A Case Study“, UC Berkeley internal
document.
[8] J. Rowson and A. Sangiovanni-Vincentelli, “Interface based Design“, Proceedings 34th Design Automation
Conference, Anaheim, pp. 178-183, June 1997.