Mobile Devices: Developing Bluetooth IP

For Bluetooth to succeed, system and chip designers must efficiently exchange intellectual property. This problem can be tackled through the use of platform-based design techniques and higher layers of abstraction.

Clearly there has been a great deal of hype behind the Bluetooth protocol. With big communication backers like Ericsson and Nokia, Bluetooth technology has shot onto the scene and captured the attention of PC developers, mobile phone manufacturers, and a variety of other consumer equipment manufacturers.

But, behind the hype, there are several challenges to making Bluetooth a reality. One of the biggest challenges is the development and integration of intellectual property (IP) blocks for system-on-a-chip (SOC) designs. Development and integration of these blocks requires a strong interaction between the system designer building the Bluetooth-enabled end product and the chip designer building the Bluetooth processing engine.

Interoperability becomes challenging with system designers and chip designers delivering different core competencies and employing different tools and methodologies during the Bluetooth development process. This gap can hinder the overall chip design process and, in turn, the overall development of finished systems. Fortunately, new design model and abstraction techniques are available to bridge this gap and allow systemdesigners to get Bluetooth devices to market quicker.

Protocol overview

In its current form, Bluetooth is a short-range radio link intended to replace physical cables. Bluetooth operates in the 2.4-GHz band and employs a frequency-hopping spread spectrum (FHSS) technique that avoids interfering signals by hopping between channels after transmitting or receiving a packet.

Figure 1 illustrates the Bluetooth protocol stack. The Bluetooth radio, the lowest defined layer of the protocol specification, defines the requirements of the Bluetooth transceiver device operating in the 2.4- GHz band. It accomplishes spectrum spreading by frequency hopping in 79 hops displaced by 1 MHz, typically starting at 2.403 GHz. These RF components may be the core expertise of a system integrator and require analog simulation tools for modeling continuous time effects.

In the physical layer (PHY) of the Bluetooth protocol, the baseband signal is the information riding on the RF carrier that manages physical channels and links apart from other services like error correction, data whitening, hop selection, and Bluetooth security. The algorithms required for this functionality, which may be licensed from a third-party developer, are typically modeled and simulated using dataflow descriptions.

In the case of Bluetooth, the link setup, authentication, link configuration, and other protocols are handled by the link manager, which communicates with other link managers through the link manager protocol (LMP). The link manager performs its service provider role using the services of the underlying link controller (LC). The logical link control and adaptation protocol (L2CAP) is layered over the baseband protocol. It permits higher-level protocols and applications to transmit and receive data packets up to 64 KB in length. Another protocol, RFCOMM, provides emulation of serial ports over the L2CAP.

For this kind of control logic, Bluetooth chip design teams can employ finite state machine (FSM) descriptions, while licensing the software protocol stack from a third-party vendor using specification-description-language (SDL) tools. All these elements must work together with the application software, defining central parts of the eventual product features.

The Bluetooth protocol also incorporates a service-discovery protocol (SDP). This protocol provides a means for applications to discover which services are available in the Bluetooth-enabled device. It also allows determination of the characteristics of those available services.

Another key element of the protocol is the host-controller inter-face (HCI). This interface provides a command interface to the baseband controller and link manager and access to the hardware status and control registers.

Three methodologies needed

Even with the relatively small Bluetooth protocol stack, both system and chip design teams are dealing with three different modeling and simulation techniques. Combining these modeling/simulation techniques with the increasing complexity of Bluetooth SOC designs, designers need advanced design methodologies. These methodologies include integration platform-based design, the adoption of higher levels of abstraction, and heterogeneous integration of different simulation techniques. Let's start by taking a look at the benefits of platform-based design.

The complexity of designs combined with time-to-market pressure makes starting every new design from scratch an impossibility. Even reuse of synthesizable design blocks (with modification) is difficult to apply because every change in the design block requires a complete rerun of verification scenarios.

Instead, system-house and SOC design teams now use design block reuse techniques where modifications to the reused blocks are not made - a method learned from PCB design. This leads to platform-based design techniques in which the basic architectural platform is maintained through product generation.

One of the main challenges with the platform-based approach is differentiation. By working off a common SOC platform, system and chip designers run the risk of developing Bluetooth systems that are virtually the same as their competitors. Product differentiation in platform-based designs can be achieved in two ways. The first is through software. The second is by adding hardware components from the platform library using standard interfaces.

Platform-based design methodology changes the way design teams interact, even across company borders, in the design supply chain. Prominent examples of semiconductor integration platforms are Texas Instruments' (TI's) open multimedia application platform (OMAP) for wireless applications, Philips Semiconductor's Nexperia platform, and Tality's Bluetooth platform. Starting with the standard platform system, companies can create derivative designs by adding differentiating functionality either through software or by trading blocks into and out of the platform architecture. Using system-level tools, the interaction between system houses and semiconductor houses happens long before the register transfer level (RTL) and embedded software are signed off.

In this process, abstraction takes an increasingly important role. It is no longer acceptable for a semiconductor company to provide just an implementation model of the platform. Instead, abstracted system platform models are required to allow the system integrator to assess trade-offs and derivative design considerations early in the design cycle. Moreover, the silicon provider delivers a platform specification with a consistent application programming interface (API) to software developers for configuring and modifying the platform.

In a typical platform-based approach, design teams would use at least three different simulation types. The radio would be analyzed in environments simulating analog continuous time data. Data flow simulators would also be used for analyzing the Bluetooth baseband. Finally, discrete event simulators would be employed to evaluate the Bluetooth protocol, which is displayed in Figure 1 . The different models of time, which have to be simulated, are shown in Figure 2 . It is obvious that simple co-simulation between the different techniques is not practical because the simulators have different time bases, and the overall system simulation would take too much time or computer memory.

In this context, let's now consider three specific integration challenges in Bluetooth designs: 1) the interaction between the radio and baseband decoders, 2) the interfaces between baseband and protocols with control dominated functionality, and 3) the combination of hardware and software and the interaction between system houses and SOC providers.

Analog abstracts

The mixed-signal radio circuitry in the RF front-end of a wireless receiver is typically located between the antenna and the digital signal processing (DSP) algorithms. This circuitry includes noisy, non-linear analog elements like low-noise amplifiers (LNAs), mixers, and oscillators.

The RF section extracts digital data from the analog RF carriers and the analog components somewhat distort the baseband signal by adding noise. A typical design challenge is to assess the bit error rate (BER) on a given channel receiver combination depending on the architecture chosen in the analog circuitry. Co-simulation of Spice-like analog data with dataflow simulation is impractical because the simulation time is too long.

However, K-models provide a solution for this challenge. Gener-ally employed in wireless receivers, K-models are discrete time behavioral models of analog circuitry. They represent the linear and non linear baseband distortion caused by RF receivers and can be used in C++ based system-level simulation of data flow algorithms. Given the wide variation in most channels, behavioral models represent a practical balance of speed and accuracy as they abstract the characteristics of the analog circuitry for use in dataflow simulation. They do not invoke the analog simulator when executing together with C++ based models. This link provides an efficient interface between the analog, continuous-time simulation paradigm and the dataflow simulation used in DSP.

Figure 3 shows how abstraction is used to enable this link. Starting from the analog transistor mode, a K-model is characterized by obtaining frequency transfer functions at several determined amplitudes of the input signal to the non-linear RF circuit. To ensure that the K-model is accurately representing analog effects, designers should perform a transient analysis in the analog domain and compare this analysis with the results obtained from dataflow simulation obtained from the model in data flow simulators. Once characterized and validated, the K-model can be used in C++ based data flow simulation as a representation of the receiver.

After the baseband signal is decoded, it is forwarded to control-dominated system blocks that determine further processing needs such as speech or video processing or simple data storage. Control models can be simulated efficiently using the discrete event computational model. These models are executed in simulation once any of the inputs are available.

By comparison, a dataflow model is executed once all the inputs for the computation are available. In dataflow simulation, significant speed advantages can be gained over discrete event simulation because a schedule of the modules to be executed can be predetermined.

Figure 4 shows an assembled Bluetooth example. A sender and receiver path are illustrated, and the two baseband controllers are assembled with imported modules from a data flow simulator. The LC and the HCI are modeled as C and C++ models. The same is true for the testbenches driving the design. Based on the open modeling interface standard (OMI, IEEE 1499), the link between dataflow and control blocks is available between several tools for system-level design block integration.

When an OMI-packaged model is imported, the necessary logic must be generated to execute the imported dataflow model in a discrete event environment. For this purpose a trigger module is automatically inserted, which, in simulation, activates the module once all its inputs are available. This enable the assessment of integration aspects of software protocol stacks with the hardware/software co-design environment.

Figure 4 outlines the functional integration of a Bluetooth system. The protocol components and the baseband controller are the components that Bluetooth-enable an electronic device. The purpose of functional integration is to assess interaction aspects between the different system blocks. In this case, the dataflow baseband performs certain coding and decoding tasks. Functional simulation together with the protocol blocks modeled as pure C/C++, and discrete event simulation can discover deadlocks and connection issues between the control and dataflow domain.

Designers should note that the channel between the baseband controllers is not modeled using K-models. While theoretically possible, it is not practical because the overall simulation times, with long protocol sequences, would be too slow.

Trade-off analysis

Hardware and software are moving closer together, especially in platform-based design scenarios, where the actual product differentiation may often be implemented using software. Standard methods available today, such as hardware/software co-verification, address important verification aspects for detailed hardware/software interfaces.

However, their applicability as architectural trade-off analysis tools is limited by the simulation speed dictated by instruction set simulations (ISSs) that are cosimulating with slow hardware description language (HDL) or clocked C++ modules. This leads to equally slow simulation speed. Furthermore, all the modules must be implemented before these tools can be used. Both factors make these technologies impractical as hand-off points between semiconductor and system design teams.

A solution for this challenge is the efficient use of abstraction. For both software and hardware implementation there are a variety of different description and authoring techniques available. Most of these techniques allow users to start at abstract, untimed models and to refine these gradually throughout the design flow until the designer arrives at the implementation.

In the software domain, the designer can choose between tools that are targeted to specific application domains and use specific simulation paradigms. On the hardware side, design teams can start at the abstract level from behavioral HDL and generic C and C++ descriptions.

In both domains, the tools described above allow modeling at an untimed abstract level, and some of them offer a direct path to implementation. However, the automated results of code generation are only close to production-ready code in a few cases. In most cases design teams will hand-implement the design RTL and software and use the abstract models only for analysis of certain system aspects, such as the evaluation of different algorithmic options for a decoding algorithm. There are, however, rare exceptions that allow graphical entry of the micro-architecture of DSP algorithms implementations combined with HDL export to Verilog and VHDL and testbench reuse through different levels of abstraction.

Aside from how a design team arrives at the implementation, the question of system integration remains difficult. The implementation level of RTL and software is impractical for the evaluation of trade-offs because the limited simulation speed allows only the consideration of a small number of alternatives. However, new development environments are available in which SOC design teams can use models abstracting the performance of the implementations. This approach allows Bluetooth SOC designers to keep functional descriptions at the system level (independent from implementation) and to sweep over different options quickly by changing performance models.

Advanced platform-based design methodologies describe and simulate functionality in a heterogeneous fashion. While definition of the functionality is typically the responsibility of Bluetooth system engineers, SOC designers can provide, in an equally prior-to-implementation fashion, the system architecture using abstract models for CPUs, DSPs, buses, real-time operating systems (RTOSes), memories, and dedicated hardware/software implementations.

The architectural models represent abstracted performance models. Mapping between function and architecture defines which architectural resources are used for all computations and communications. Performance simulation models can be built from those three descriptions. This enables efficient trade-off simulation before implementation using characterized or estimated performance models representing the implementations.

Note that it is important to provide the design activities functional capture, architectural capture, and mapping within the same development environment at a reasonably high level of abstraction. This enables new ways of interaction between Bluetooth system designers and SOC semiconductor providers and, perhaps even more importantly, allows each party to concentrate on their core competency while still being able to work together seamlessly.

The design flow described provides the ability to perform early system performance evaluations. It also provides an efficient hand-off point in the SOC design chain. Together, the functional and architectural descriptions define the abstracted system platform. The Bluetooth system designer can change mappings, add functionality, and explore the function-architecture design space efficiently before committing to the final implementation. The functionality, which is defined independent of the implementation, can be articulated to the Bluetooth SOC developer and architecture options can be evaluated.

Once the function design space is explored using performance simulation and an optimal function/architecture pair is identified, it is paramount to export this information directly to implementation-level tools. These tools include hardware/software co-verification products, compilers, and synthesis for hardware.

A platform-based methodology also encourages IP reuse without modification. Therefore, the design export between the Bluetooth system designer and the Bluetooth chip designer must be able to automatically assemble the communication path between hardware and software, software and hardware, and within the hardware and software domains. A function-architecture co-design methodology and a tool environment must also be present to provide a path from the abstract system level (used for exploration of the design space) to the implementation level. This will facilitate hardware and software export from system-level to implementation as well as communication synthesis establishing communication between the design blocks.

Frank Schirrmeister is the director of product management at Cadence Design Systems. Before joining Cadence, Schirrmeister held various technical and management positions with Sican GmbH and Media Chip Technology. He holds an MSEE from the Technical University of Berlin in Germany and can be reached at franks@cadence.com.