|
EDGE Handsets: Baseband Processing Methodologies
By Alan Varghese
The EDGE protocol has quickly gained acceptance in the wireless market. As designers begin to rollout EDGE-based systems, they must re-architect the baseband portion of their mobile phone designs so that they can support voice and data functionality.
As the wireless industry moves through the early stages of the 21st century, there is a clear trend to move away from developing voice-only products toward producing next-generation architectures that support voice and data services. To accelerate the move to converged voice/data products, the wireless industry has developed a variety of air interface protocols. One of these, the Enhanced Data Rates for GSM Evolution (EDGE) specification, has stirred much interest in the wireless market.
EDGE has often been dubbed a 2.5G specification and is seen as an intermediary step to third-generation (3G) systems, such as wideband code-division multiple access (W-CDMA). By implementing the EDGE protocol, current North American time-division-multiple-access (TDMA) and Global System for Mobile Communications (GSM) developers can design handsets that deliver 384-kbps data rates. This enables voice services, Internet connectivity, and multimedia content to reside on a single handset. Engineers developing EDGE-based handsets will face a variety of design challenges. In particular, engineers will encounter many headaches and new design methodologies when developing the baseband section of an EDGE-enabled wireless product.
Current Solutions
To begin any detailed evaluation of EDGE-based baseband architectures for wireless handset designs, it is important to first look at the current baseband architectures being employed in today’s TDMA handset designs.The TDMA baseband section highlighted in Figure 1 can be broken down into seven blocks. The first block houses the RF-to-baseband interface. During base station to mobile-downlink transmission, the RF signal is digitized at the minimum Nyquist rate. In the uplink, the reverse process occurs — the digitized samples from the digital signal processor (DSP) are converted to an analog signal for up-conversion.
The second baseband block sports the DSP with ROM, RAM, and the coprocessor. Of these components, the DSP is the central figure in the baseband block, performing many functions that correspond to the math-intensive physical layer of the protocol.
To highlight the importance of the DSP, the primary tasks this component handles when processing a MIPS-intensive digital traffic channel (DTC) should be examined. When processing the receive slot of a DTC in a TDMA design, the DSP first performs coarse synchronization where it looks for the SYNC word of the slot. This is done in order to establish coarse timing reference, frequency error, and automatic-gain-control (AGC) settings. Then the processor performs fine synchronization, establishing symbol timing and initial channel coefficients for the equalizer. The p/4 differential-quadrature-phase-shift-keying (DQPSK) signal is demodulated using a differential detector or with an equalizer if the channel has significant delay spread.
The DSP will then run digital-verification-color-code (DVCC) and slow-access-control-channel (SACCH) decoding sequences. DVCC is a parameter that identifies that the correct base station transmission is being received. SACCH is slow control information sent in the same slot as voice or fast-access-control-channel (FACCH) information. Next, voice/FAACH deinterleaving and decoding occurs. These functions correspond to the interleaving and channel coding done at the transmit end for time diversity and bit-error-rate (BER) performance.
The DSP also performs speech decoding, echo cancella-tion, speech encoding, SACCH channel coding/interleaving, voice/FACCH coding and inter-leaving, as well as burst formatting. In the burst-formatting stage, data bits and other fields such as SYNC, SACCH, and CDVCC are formatted in order to occupy the correct positions in a 324-bit IS-136 slot.
Table 1 lists approximate values of the processing MIPS and memory required to handle a DTC in a TDMA design. Note that if the number of MIPS are added up, the total comes close to 37 MIPS. If engineers used a coprocessor for a portion of the channel decoding, they could reduce the MIPS required for that function from 5 MIPS to about 2 MIPS. But then there are other smaller items that are not noted here, which consume additional MIPS. Therefore all told, a second-generation IS-136 DSP needs about 37 MIPS of processing power.
In the baseband design, the DSP is complemented by the microprocessor, which is a component optimized for decision-directed code and for sensing and controlling external events. This embedded processor delivers the interface layer with the DSP, Layer 2 and 3 protocols, as well as the user interface software. The processing required for IS-136 requires the microprocessor to be clocked at approximately 10 MHz.
Rounding out the blocks
The audio interface is the next block in a traditional TDMA baseband architecture. This interface includes the 8-kHz audio codec, filters, and amplifiers.
The audio interface is followed by the power-management block. The main functions it supports are battery charging and monitoring, voltage regulators for all circuits in the baseband and RF, power ON control, drivers for LEDs, and the vibrator.
The final block in the baseband portion of a TDMA cell phone is devoted to memory. The first is the Flash memory block, where all the code for the microprocessor resides. The typical IS-136 handset needs about 16 Mbits of Flash memory, depending on the mix of applications supported. The second memory component is the static-RAM (SRAM) block, which is used for buffering, registers, and scratch- pad memory. This memory block ranges around 2 Mbits in TDMA handset designs.
Integrated Functions
Today, most implementations of the baseband contain three integrated chips and a handful of discrete components. The two predominant implementations of the integrated chips are:
One where all the analog functions are on one chip, the DSP and microprocessor on another, and the memory devices are on the final IC (see Figure 2).
One where the RF interface, audio interface, DSP, and microprocessor are all on one chip, the memory blocks on the second chip, and the power management functions on the last one (see Figure 3).
Both of these implementations have their benefits and drawbacks. In the first setup, one major benefit is the grouping of analog functionality on a single IC. By bundling all analog functionality together, advanced technology processes can be easily applied. On the downside, the first implementation calls for the DSP to sit on a separate chip. Due to this, designers will face lines between the RF interface and the DSP as well as between the audio interface and the DSP. This takes up routing space on a printed-circuit board (PCB), can add additional noise, and also burns power when driving the capacitance on these lines.
Power-management functionality may also be a problem in the first implementation. In this implementation, power-management functions are combined with additional circuitry on the same IC. This may cause heat-handling problems within the packaging design. Finally, toggling voltage regulators at an IS-136 subframe rate may cause noise in audio circuits.
The second implementation also offers its pluses and minuses. On the positive side, this implementation enables connections between the RF interface, DSP, and audio interface on the same chip. By combining this functionality on a single IC, designers can improve routing space on the PCB and improve the transfer of information between these blocks.
On the downside, the second implementation requires analog and digital circuitry to reside on the same chip. Therefore, chips housing this functionality may experience layout and isolation problems. Second, since analog voltage scaling tends to lag behind digital, this topology prevents an engineer from taking advantage of leading-edge digital processes.
Approaching EDGE
Now that a current cell-phone design has been reviewed, the best ways to move from current TDMA designs to EDGE designs can be evaluated. Rather than jumping straight into specific implementations, it would be preferable to think in terms of design methodologies and then migrate from there to algorithms, hardware, and software, ensuring an optimum solution.
To achieve enhanced data rates, the EDGE protocol employs an eight-level PSK (8PSK) modulation and multislot transmission technique. Additionally, in order to meet the carriers’ requirements for a phone that can roam globally, EDGE-enabled handsets must support 850-MHz Advanced Mobile Phone System (AMPS), IS-136 in the 850- and 1900-MHz bands, along with GSM and EDGE in some combination of the 900-, 1800- and 1900-MHz bands. The wireless handset’s baseband section must support FM, DQPSK, and Gaussian minimum-shift-keying (GMSK) modems, along with the IS-136, GSM, and half-rate vocoders.
For designers, supporting multislot transmission and multiple modems/vocoders can be troublesome. Multislot transmission results in increased processing. In fact, early estimates suggest that EDGE phones will require about 2 to 5 times the processing power of today’s 2G IS-136 products, depending on the particular class of operation. By increasing the number of vocoders and modems, designers will be challenged to implement the baseband portion of an EDGE phone in a cost-effective manner as well as in a scheme that occupies the smallest PCB footprint.
Despite these design headaches, engineers are moving forward in their quest to develop EDGE-enabled mobile handsets. During the development of these products, there seem to be three methodologies, or ways of thinking in order to develop EDGE designs. Each methodology will be explored in terms of system design and potential risks.
Methodology 1
In the first methodology, engineers follow the same design used to develop current TDMA handsets, in order to leverage the advantages of reuse. Under this approach, the same hardware and software platforms are employed. The only difference is that the platforms are beefed up in order to handle the requirements for EDGE.EDGE and its applications will affect most of the blocks shown in Figure 1, but this discussion will be limited to only the more significant ones, beginning with the DSP MIPS requirements.
As previously stated, EDGE designs must support multislot capabilities to transport data. Since the first EDGE handsets will probably not support full-duplex transmission, the processing required for up to Class 12 operation should be considered, which implies a total of five slots (four receive slots and one transmit slot).
Table 1 highlights some of the key DSP MIPS requirements that a designer using methodology 1 may encounter when developing an EDGE baseband architecture. To calculate the amount of MIPS required while the system operates in the receive mode, engineers must add the DSP MIPS required for synchronization, equalization, and channel decoding. From the information provided in Table 1, when these functions are combined, the EDGE baseband architecture will require 15 DSP MIPS when operating in receive mode.
This calculation, however, does not consider that the equalizer for 8 PSK will be more complicated due to the high data rate. Also there will eight different channel-coding modes that can be switched according to the channel quality. As a result, the DSP MIPS total may be closer to 20 MIPS for each slot and therefore 80 MIPS for all four slots.
On the transmit side, the required amount of DSP MIPS can be computed by adding the MIPS needed to perform channel encoding and burst formatting. Based on Table 1, this DSP MIPS total equals 1 MIPS.
When the transmit and receive MIPS requirements are combined, the total MIPS count for Class 12 operation equals 81 MIPS (80 MIPS for receive and 1 MIPS for transmit). Including additional overhead to account for control code, a designer probably needs close to 100 DSP MIPS. If designers choose a lower-MIPS DSP, they may need to off-load some of the processing, such as the Viterbi decoding and the Viterbi portion of the equalizer, to a coprocessor.
Additional Needs
In addition to increased MIPS requirements in the DSP, methodology 1 will require expanded memory and microprocessor requirements. This analysis will start with the ROM and RAM requirements.
On the memory side, an engineer must realize from Table 1 that an IS-136 modem/vocoder combination requires approximately 20 kwords ROM space.The digital control channel, AMPs, and tables and coefficients will take another 20 kwords. In EDGE designs, however, a designer must add two additional modems — the GMSK and 8PSK modems as well as the (AMR) vocoder. Since the 8PSK modem and the AMR vocoder are much more complicated, designers should expect their EDGE baseband designs to require an additional 60 to 80 kwords of ROM in all. Therefore, total DSP ROM for the EDGE baseband described in methodology 1 is 100 to 120 kwords.
On the RAM side, a designer will need approximately 7 kwords of additional RAM for the additional functionality that EDGE systems require. Hence, total DSP RAM is roughly 14 kwords.
Due to the increased amount of processing for data coming in at 2.5G rates, and the control software required to switch between all the different standards and operating modes, an engineer will need to run the microprocessor three to four times faster than the IS-136 rate. Therefore, the microprocessor must operate at approximately 30 to 40 MHz. The engineer will also need another system clock at 13 MHz or a multiple in order to support GSM.
Flash and SRAM memory must also be increased to support methodology 1. Flash-memory devices must move from 32 to 64 Mbits to support voice and data capabilities. SRAM, on the other hand, will move from 4 to 8 Mbits. Both memory devices must also support burst and page modes in order to keep pace with the 30-to-40-MHz-microprocessor clock speeds.
Methodology 2
When designers move from methodology 1 to methodology 2, they must move up one level of abstraction and rethink their whole partitioning of algorithms, hardware, and software. Under this approach, designers must think in terms of high-level virtual design. They must use prototyping tools that take in system requirements and output optimal partitioning. These tools will perform RF, baseband, and call-processing simulations as well as produce behavioral prototypes of the EDGE system. By doing this, designers can find the best mix of hardware and software. Thus, the hardware could be synthesized into a combination of ASIC, DSP, and laser-programmable gate arrays (LPGAs) in order to find the overall best solution in terms of die size, speed, and flexibility. ASICs and LPGAs are used for high-data-rate tasks and DSPs for low-rate tasks or portions of the algorithms that require many decision points.
Methodology 2 delivers several benefits to the designer. This methodology enables designers to build custom hardware that can perform many tasks in parallel, thus outperforming the DSP. Typically, DSPs use heavily loaded buses to communicate with memory and arithmetic logic units; this approach burns a great deal of power in a baseband architecture. By employing methodology 2, designers can create custom data-path processors that allow data to flow from one parallel operation to the next with minimal loading and without instruction fetching overhead.
Prototyping tools may some day progress to the point where we can feed in system requirements and it will spit out possible hardware and software partitioning and implementations, PCB layouts and routing, mechanical packages, phone form factors, and even bill of materials cost. Unfortunately, prototyping tools that deliver this functionality are still a few years away.
Methodology 3
Under the final methodology, an engineer needs to think in terms of new and innovative methods and architectures. Methodology 2 solved the problem of finding the optimum combination of hardware and software. Now in addition to this optimization, engineers must attempt to find a solution to the basic problem in any system — hardware solutions are fast but inflexible while software solutions are flexible but suffer in performance.
There is a world that is unfolding in research universities and small startups across the country. It is a world where hardware is as adaptable as software and it can be changed on the fly in nanoseconds. Additionally, it is a world where hardware is optimized to match the specific software running on it, reducing power consumption, PCB footprint, and producing a platform that can be adapted for multiple applications. This is a new technology that has been given names such as reconfigurable logic (RL) and adaptive logic.
Methodology 3 may consist of a sea of programmable logic blocks with programmable interconnects and distributed memory, along with a microprocessor running a RTOS that brings up the specific hardware configurations at specific times. The architecture may be reconfigured at a micro-level or at a macro-level. Reconfiguring at the micro-level involves bringing up successively different hardware that is optimized for either equalization, channel decoding, or speech decoding at specific times within the received slot. Macro-level implies that the hardware can be reconfigured by the handset vendor or carrier to change from an IS-136 phone to a GSM phone to an EDGE phone, or that it can be reconfigured to run different applications software in an optimum fashion.
The risks
As engineers start employing new methodologies for EDGE design, it is important to evaluate the associated risks. By doing this, they can choose the best methodology for their application.
Methodology 1 requires minimal risk. Since hardware and platforms stay the same, engineers know the challenges and design issues they will face. Additionally, this methodology produces a baseband architecture that is mature and friendly to high-volume production processes.
When designers move from methodology 1 to methodology 2, risks begin to increase. In methodology 2, the basic platform has changed, forcing designers to learn and implement new design approaches and run into potential manufacturing problems. Additionally, the prototyping tools required to implement methodology 2 are far from mature or perfect.
By far, engineers employing methodology 3 face the largest risk. It has taken the DSP and ASIC world almost 20 years to get to the level of maturity it has today. Additionally, there are thousands of firmware and software support houses for the industry’s leading DSPs. The RL market is a new industry filled with young players and new technology. Therefore, engineers must consider the maturity and the stability of the technology, as well as the production capabilities of the companies developing these solutions before turning to methodology 3.
|
Puzzled by a network processing design issue?
