Bluetooth demands system tools

Superior radio performance raises the bar designers must jump to create commercially successful products. Technical standards specify minimum performance requirements, but to win, systems must be designed to exceed those minimum standards. Success represents trade secrets of great value. That's especially true in the Bluetooth application because the unlicensed 2.4-GHz industrial, scientific and medical frequency band on which Bluetooth rides is already crowded and is expected to get even more so. (Bluetooth operates in the 2.4-GHz ISM band worldwide, though only portions of this band are currently available in France.)

The only way to guarantee a winner is to stress-test the design under many conditions and fine-tune it, adding new innovations as appropriate. It makes sense to start with a fast simulation of a generic Bluetooth transmitter, receiver and typical indoor propagation-channel models to meet the basic radio performance. Next, the channel can be further disrupted by adding additional interferers such as simulations of IEEE-802.11 wireless-LAN signals, microwave ovens, cordless phones and neighboring Bluetooth devices wit hin worse-than-typical propagation channels.

Just as specs are evolving, so too are system-level design tools. Synopsys' Cossap, for example, is now being eclipsed by the company's CoCentric System Studio product. CoCentric System Studio can import all existing Cossap designs without modification and, furthermore, the designer can also take advantage of crucial new capabilities such as nestable control-flow modeling. CoCentric System Studio works in conjunction with the CoCentric SystemC Compiler to provide the ultimate concept-to-RTL SystemC design flow. Integration is facilitated by a new age in C-based system-level design automation.

Bluetooth systems are usually not intended to be standalone products; rather, an electronic consumer product is expected to have a Bluetooth link to other wireless devices. Clearly there is great incentive to integrate Bluetooth silicon with the main system-on-chip (SoC) silicon. Traditionally this had been done at the register-transfer language level. Today t here is great motivation to have this modularity raised to the C-language level.

The wide adoption of SystemC as a C-based hardware-modeling language makes this a reality. Under close inspection, SystemC is nothing more than a set of C++ class libraries and a simulation kernel. The hardware system it models can be accurately simulated by compiling and executing the code using any C++ compiler. SystemC source code is available at no cost from www.systemc.org.

Only eight months after the Open SystemC Initiative was unveiled, Synopsys introduced its CoCentric SystemC Compiler. This design tool reads in a SystemC description and outputs the gate-level netlist for an ASIC or FPGA. It can also write out HDL, which enables a system-level designer to use his or her favorite RTL tools, for further development, if so desired. RTL simulators can be linked to CoCentric System Studio simulations.

Pointed questions
The Bluetooth system provides a poi nt-to-point connection-only two Bluetooth units involved-or a point-to-multipoint connection. Two or more units sharing the same channel form a "piconet," where the unit controlling the traffic is a master and the other units are slaves. A piconet can have up to seven active slaves and an unlimited number of inactive slaves (those which are locked to the master but do not receive any data other than the control data for synchronization). There may be multiple piconets with overlapping coverage areas, a configuration called "scatternet." Each piconet can only have one master. Slaves can participate in different piconets on a time-division multiplex basis, and a master in one piconet can be a slave in another.

Since the ISM band requires spectrum-spreading techniques if the transmitted power level exceeds 0 dBm, the Bluetooth standard employs a fast frequency-hopping (1,600 hops/second) scheme. In countries where the ISM bandwidth is at least 80 MHz, 79 hopped carriers, or channels, spaced 1 MHz apart have been defined. In France, 23 channels are used. The modulation is Gaussian-shaped binary-frequency shift keying, resulting in a symbol rate of 1 Mbit/s. The Bluetooth standard is based on channels that use a frequency-hop/time-division-duplex (FH/TDD) scheme.

Bluetooth can accommodate the transport of both speech and data. The data (including speech) to be transmitted is stuffed into packets. A number of packet types (with different lengths, forward error correction and cyclic redundancy checking) are defined.

On the public Bluetooth Web site (www.bluetooth.com) is a plethora of evaluation boards and test equipment to jump-start designs. For example, Synopsys' CoCentric Bluetooth Reference Design Kit can be used in a concept-to-RTL system-on-a-chip design flow based on SystemC.

Basically, a reference design kit (RDK) consists of a reference system-level model for the complete physical-layer baseband design, including block diagrams, documentation, testbenches a nd scripts for both transmitter and receiver as well as pertinent channel models. Three immediate benefits are:

• faster time-to-market,
• environment for radio performance optimization,
• standards-compliance reference.

With the CoCentric reference design kit, a designer starts with a fully working system model, a method that accelerates time-to-market and reduces the risk of misinterpreting the specification. Implementing a product based on a technical standard is a big task, especially for manufacturers that have not been involved in the invention and standardization of that spec.

The kit provides models for all transmit functions defined in the standard as well as a reference implementation of a typical receiver that meets the performance specifications laid out in the standard. Receiver design is not part of the Bluetooth standard. The availability of a working receiver in the kit that meets the performance specifications can save users significant engineering hours.< /p>

The kit supports a jump-start for the design of the differentiated portions of a Bluetooth solution. And it supports all currently defined HV, DM and DH packets. Depending on packet length, a packet can be transmitted in one, three or five slots. Normally a different hop frequency is used for each slot. If a packet needs more than one slot, the hop frequency is fixed for the duration of the packet. Subsequent slots are alternately used for transmitting and receiving, which results in a TDD scheme.

Two types of physical links have been defined, namely the synchronous connection-oriented (SCO) link and the asynchronous connectionless link (ACL). The SCO link is a symmetric, point-to-point link between the master and a specific slave. Typically used for voice data, the SCO link reserves consecutive slots and can therefore be considered a circuit-switched connection.

A master can support up to three SCO links to the same or to different slaves. A slave can support up to three SCO links to the same master or one or two SCO links to different masters.

The ACL, meanwhile, provides a packet-switched connection between the master and all active slaves in a piconet. In the slots not reserved for SCO links, the master can exchange packets with any slave on a per-slot basis. The ACL is typically used for the transmission of data bursts. The master uses a polling scheme to control ACL connections. Between a master and a slave only a single ACL can exist.

SCO packets are never retransmitted, while packet retransmission is applied for most ACL packets to ensure data integrity. An automated repeat request (ARQ) scheme signals the master that the previous packet transmission has failed.

In the first stages of our SoC design implementation of the Bluetooth baseband standard, some assumptions are made. This simplification allows us to devote more simulation time to verify the intrinsic radio robustness of our design before committing to higher levels of integration.

• A single connection between one master and one slave is simulated.
• The connection is already established.
• The packet length is known in the receiver.
• The modeling of encryption is not necessary at this stage since it has no impact on the radio performance.

An ARQ scheme simulation of DH packets can be exemplified in the transmitter and receiver of the Bluetooth baseband standard. The packet type could be replaced by other packet types. The SCO link simulation is similar except for the feedback path used to send the ARQN bit to the transmitter.

The standard Bluetooth packet consists of a 72-bit access code, a 54-bit packet header and the payload, which can be up to 2,745 bits long. The particular format depends on the packet type. (Refer to the Bluetooth document for the algorithms to generate the access code, the packet header and the payload.) Packet generation includes data whitening and forward error-correction coding. Three error-correction schemes are defined for Bluetooth : 1/3 rate FEC, 2/3 rate FEC and an ARQ scheme for the data.

The 1/3 rate FEC code is a simple 3x repetition code. This code is used in the packet header and in the payload of HV1 packets. The 2/3 rate FEC code is a shortened Hamming code that can correct all single-bit errors and detect all double-bit errors. This code is used, among other places, in HV2 and DM packets.

The ARQ scheme, including retransmit filtering, must be applied to packets with CRC in the payload. For such packets the payload is retransmitted until a positive acknowledgment is received or a time out is exceeded. A retransmission is required either because of a failed packet transmission or because of failed transmission of the ARQN bit in the packet header of the return packet sent by the destination. In the latter case the destination receives repetitions of the same packet, which already has been successfully decoded.

To filter out the retransmission, the SEQN bit is added in the header. For a successfully deco ded packet this bit is alternated. In case of retransmission, this bit is not changed. Hence the destination can filter out already decoded packets by comparing the current SEQN bit with the previous one. If the two SEQN bits are the same and the previous packet has been successfully decoded, the current packet can be discarded.

The last step in the transmitter is the generation of the hop frequency. The simulation of frequency hopping is computationally intensive and is therefore only advised for fading-channel simulations.

Simulated channel
The data stream is then transmitted through a simulated communication channel, allowing the introduction of one or more of the following impairments:

• Fading: Since the Bluetooth standard does not define an indoor fading channel, we used a six-tap flat Doppler spectrum as defined in the UMTS standard as well as the fading model proposed by Saleh and Valenzuela.

A similar UMTS channel model was developed from the Synopsy s UMTS-FDD (3G/W-CDMA) Reference Design Kit and the Saleh model draws on experience gained in creating the Synopsys DECT RDK.

• frequency offset,
• additive white Gaussian noise,
• co-channel and adjacent-channel interference as defined in the Bluetooth standard,
• channel interference by other radio transmitters, such out-of-band signals from a GSM mobile phone.

Performing communication simulations under many channel conditions is an important process in increasing the robustness of the overall design, particularly the receiver. Since radio robustness will help select the winning commercial solutions, this is a crucial design step.

Other interference sources-such as foreign Bluetooth devices, IEEE-802.11 wireless-LAN transmitters, HomeRF and a new breed of 2.4-GHz ISM cordless phones in the United States-can be simulated to stresstest the Bluetooth design.

The analog front end of the receiver consists of a fourth-order Butterworth prefilter, an automatic gain c ontrol block and an incoherent demodulator. On the demodulated signal, timing adjustment is performed. Timing synchronization is based on the following assumptions:

• A 20-ppm sampling-clock offset does not require clock tracking, because the sampling-time variation over one burst is negligible (< 0.1 percent of a symbol).
• The estimation of the timing can be performed through correlation of the incoming signal with a synchronization word.

The timing synchronization is achieved with a correlator using the access code as the correlation sequence. The correlator performs N correlations, where N is a parameter, and searches for the maximum-magnitude value. The position of the maximum-magnitude value is taken as the timing offset.

Single sample
In addition to correcting the timing offset, the correlator does the downsampling to one sample per symbol. The resolution of the correlator is one sample. In our example we used the oversampling rate (NS = 8) as sample rat e of the input signal to the correlator. This should be sufficient for the Bluetooth standard. A higher resolution could be achieved by interpolating the input data prior to correlation.

The following frequency synchronization is achieved by means of dc offset compensation, which involves the computation of the dc offset value and subtraction of this value from the input samples. For the computation of the dc offset value the known symbols of the access code are used-in particular, the four (dc-free) symbols from the preamble, the last six (dc-free) symbols from the sync word and the four (dc-free) symbols from the trailer. Altogether, the maximum number of known symbols for dc offset computation is 14.

Finally, threshold detection is performed and the data stream is passed to the packet-decoding unit. This unit generates the ARQN bit, which is retransmitted to the packet-encoding unit via an uplink channel. For reasons of simulation run-time efficiency, only the ARQN bit itself is retransmit ted rather than the complete packet. However, in the uplink channel the ARQN bit can still be disturbed with a user-defined probability.

The packet-encoding unit receives two ARQN bits, the possibly disturbed one and the original. By comparing both bits, the packet-encoding unit decides whether the ARQN bit was correctly received (if the two bits are equal) or not.

This is a simplified simulation of the ARQ scheme, which still allows errors in the reverse link to be taken into account. The generation of a packet in the receiver and the decoding of a packet in the transmitter can therefore be omitted, increasing the simulation speed.

Using a Synopsys CoCentric System Studio-based design, computer simulations can be performed for the characterization of the Bluetooth baseband SoC design.

In particular, these simulations must include performance tests for co-channel interference (CCI) and adjacent-channel interference (ACI) as specified in Section 4.2 of the Bluetooth core specif ication. Performance tests for fading channels are also executed.

CCI, ACI requirements
For compliance with the Bluetooth core specifications, the receiver must satisfy certain requirements in terms of the CCI and ACI performance. For a given channel-to-interference ratio and a given noise level, a bit error rate of 10-3 at the demodulator output must be achieved.

The Bluetooth industry has created a technical conformance-testing regime, called the Bluetooth Qualification Process, so that Bluetooth products can be certified as genuine implementations of the Bluetooth standard. Now that the qualification process is in place, a frenzy of design starts is expected.