Design Methodology and Tools for Wireless System Design

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 communications, 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 support 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 presentation 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 communications. Today, we are on the threshold of a far more penetrating introduction of wireless technology 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 underlying 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, bandwidth, 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-specific 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 systemson-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 comprehensive design methodology that enables correct design in a short design cycle, while trading 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 confines 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 computation and architectural vision. Based on these concepts, we have formulated a comprehensive design methodology, as pictured 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 abstraction, 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-timeonly 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 informal phase of the specification process. The Unified Modeling Language (UML) is a standardized 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 Interface with a capturing of the design requirements ( requirement analysis ) and the relations between the system to be voice commands/ status designed and the external world. One way Permissions 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/ designed in Berkeley, is shown in Figure enable/ Physical and disable Media Access 3. These initially vague requirements are Link Protocols Control (MAC) iteratively defined till a more precise definition radio channel of the system modules and pro- cesses, their interactions and Slot dependencies is derived. For example, a Database more defined object-diagram of the digital intercom is given in Figure 4. The diagram is simple, yet it includes all of the FIGURE 4. OMT model of digital intercom and its components. major structural blocks and their relationships 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 composition, relationship i.e. the objects attached to the line are parts of the object next to the diamond. 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 communication 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 complemented 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 specification 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 protocols 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 documentation, 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 higherorder 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 provides 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 architecture selection) and (semi-)automatic synthesis is more readily achieved. Once again, we differentiate 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 extensive performance and energy models so that the decision can be based on quantitative information. One of the premier tools in this area is the Felix environment, that is currently under development at Cadence [8]. Felix allows for the simultaneous definition of both behavior (in a mixed CFSMdataflow format) and the target architecture (Figure 7). Adding associations between the two makes it possible to perform rather accurate performance and energy estimations. Protocol Synthesis FIGURE 7. Example of hardware mapping process in Felix. Selected pieces of behavior are associated with specific hardware modules 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 platform (software executed on a micro- or DSP processor, ASIC accelerator module, or reconfigurable array) (Figure 8). When a software solution on a processor is considered, it is possible to SDL (Telelogic) design flow disconnects (hand translations) in italics generated C code hand generated OS interface and Env functions SMV hand translation Synchronous FSMs compiled library OS (Custom) Processor VHDL ASIC or FPGA Synthesis 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 hardware 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 FIGURE 9. Netlist of CDMA correlator datapath, as generated from SIMULINK description. 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 algorithm (which is very often the case when an ASIC implementation is chosen). The MathWorks Simulink 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. This netlist can then be directly fed into logic synthesis tools or datapath compilers. Observe also that a one-to-one mapping into predefined library modules is the typical approach for the analog sub-functions. Summary 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 programmable 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 reconfigurable architectures such as the Berkeley Pleiades. 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 appropriate 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, Prentice-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 Wideband 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.