SoCs: DSP World, Cores -> 3G wireless SoC requires emulation

Basically, the UMTS has several design advantages. For example, it supports existing mobile services and fixed telecommunications services up to 2 Mbits/second with global roaming. It also supports unique mobile services such as navigation, vehicle location and road traffic information services. In addition, the UMTS terminal is to be used indoors and outdoors; it offers mobile terminals ranging from a low-cost pocket telephone to sophisticated terminals to provide advanced video and data services.

Since the high-speed multimedia service is one of the major features of UMTS, wideband CDMA has been chosen to be the radio access method for its flexibility in achieving different high-speed communications.

To accommodate the high signal-processing demands for 3G wireless designs, user prototypes require dedicated hard ware, either FPGAs or ASICs. DSPs alone do not have enough computing power.

Essentially, there are four main digital blocks in a 3G wireless system. They include the logic algorithm, DSP, microcontroller and RF. Each of these blocks must be designed and verified and then integrated into the SoC design.

Typically, the logic algorithm is created and modeled in an RTL language. The logic algorithm can be synthesized and prototyped with high-density FPGA devices such as the Xilinx Virtex V1000 devices. The V1000 FPGA devices will hold up to 150,000 ASIC gates plus memory; with 12 devices on the MP3C, 1.6 million-plus ASIC gates can be put into one MP3C system. High-level RTL will be synthesized into the FPGA devices in the prototype.

The Aptix Module Verification Platform (MVP) allows the designer to test the logic in a high-level testbench. This analysis will allow the designer to quickly evaluate and correct the logic for optimum performance.

The design's DSP can be provided as a soft core or a hard core. In a soft core, high-density FPGA devices can be used to prototype the DSP device. In a hard core, the test chip can be mounted on a module and used in the emulation system, or an evaluation board from the manufacturer can be used. Lucent has made its DSP16410 standard evaluation module compatible with the prototype environment.

The microcontroller, like the DSP, can be provided in either soft or hard core. JTAG-based emulators allow the firmware engineers to test against the FPGA logic prototype. This allows early hardware-software integration of the design. Popular controllers such as the ARM 7TDMI can be used as evaluation boards from ARM or modules from vendors such as Aptix.

The RF subsystem can be developed and cabled to the digital SoC prototype. The analog nature and speed of the design do not work well in FPGA devices.

Basically, the MVP links the System Explorer hardware to the designer's workstation through a dedicated high-bandwidth link and al lows the designer to test the logic in a high-level testbench. A communications card plugs into the PCI bus of Sun or Hewlett-Packard workstations. The MVP enables the designer to instantiate hardware-mapped blocks within the system-level model created in the simulator. It sends data from the simulator to the prototype and returns the circuit's response to the simulator. Co-emulation enables the designer to exercise the emulation hardware thoroughly without creating extensive sets of test vectors.

In the Lucent project to emulate a 3G channel estimator and Rake decoder, a hardware prototyping platform from Aptix and a Lucent data pump were used. Lucent found that in order to accommodate the high signal-processing demands for wideband CDMA, prototyping in dedicated hardware, either FPGA or ASIC, would be required. Since FPGAs offer more flexibility than ASICs in turnaround time, Lucent's design team chose a prototyping platform that incorporated a highly complex system using more than one Xilinx FPGA. The Aptix solution, which included Lucent's using the MP3C hardware platform and MVP, enabled Lucent's design team to tailor modifications to fit its needs.

Because of the uncertainty of the design complexity for this prototype, Lucent had to have a hardware prototyping system that was flexible enough to accommodate several different hardware modules. The system also could not be too expensive. After exploring several different products, Lucent decided to use the System Explorer MP3C platform from Aptix for several reasons:

• It supports as many as 12 FPGAs with 1,920 configurable pins.

• It has high system I/O pin counts: 640 board I/O and 160 bus I/O.

• It has eight clock phases distributed to all FPGA sites with modular, user-definable clock-generation circuitry.

• There are programmable FPIC routing switches interconnecting all the components.

• Integrated hardware probing connectors for logic analyzer debug are included.

• The sys tem enables real-time verification for system clocks up to 30 MHz.

• There are many hardware modules to choose from, including FPGA (Xilinx, Altera and Lucent Orca), microprocessor, microcontroller, DSP and memory.

• MVP is used for co-simulation with simulators.

For the project, Lucent used the following modules in the prototype: two Xilinx XC40150XV modules (with up to 150,000 gates) for the rate channel estimator and data pump interface; one Xilinx Virtex 1000 module (up to 1 million gates plus memory); a single dual-port static memory module (1.5 Mbytes) and a single MVP module (with 400-bit I/O).

All the modules use one system clock at 4 MHz, but all the designs on the FPGA are capable of running in real-time. The choice of this clock is based on the speed limitation set by the data pump and MVP module.

In order to achieve the highest flexibility in the signal generation, Lucent did not use a hardware signal generator. Instead, Data Pump software was use d to generate all the signals from the information bits through the channel model. Since the host PC cannot generate the signals fast enough to meet the high computation requirement of the channel model, the real system speed is about 500 times slower than real-time.

The design was developed using VHDL. Synopsys and MTI tools were used to synthesize and simulate the design. However, to test the design on the FPGA, Lucent needed the combination of speed and flexibility that is usually beyond the capability of common co-simulation environments. In this project, Lucent used the Data Pump software to bridge the gap.

Under Data Pump, two files define every simulation: a simulation file (.sim) and a graph file (.grf). Inside the simulation file, signal source and signal sink can be defined to be a file or a formula, from the network or a hardware device. Signal data will be fetched from the signal source and sent to the hardware. The results will be fetched back from the hardware and sent to the si gnal sink. At the same time, the graph subsystem can be activated to manipulate the data and show high-level graphs.

Signal concepts

To achieve even higher flexibility, Lucent introduced signal source encoder and signal sink collector concepts in Data Pump. These are used as plug-in modules to change the signal format and filtering results received from the hardware.

The source encoder is used to encode the signals format before Data Pump sends them to the hardware. The signal sink collector is used to collect "real" results from the hardware. Since the hardware might run at a different data rate than Data Pump, the signal sink collector is used to filter out redundant data; it also enables Data Pump to adapt to a different data rate.

The Lucent UMTS prototype used 128 bits of the MVP interface to input the received signal. The oversampling rate is 4, and every sample is 4 bits for I and Q. So in every Data Pump frame, Lucent sent in four chips' worth of data, or 4 x 4 x (4+4). Since every UMTS frame has 40,960 chips, the designer needed to send 10,240 Data Pump frames for every one UMTS frame. There are 600 information bits per UMTS frame; therefore, the decoder will produce an average of 600 bits for every UMTS frame interval. The designer reserved 24 MVP I/O bits for the decoder output data with 1 flag bit to indicate whether it was real data. For every UMTS frame, the designer will receive 600/24 = 25 decoder results; that is, 25 out of 10,240 Data Pump frames will contain decoder results. After the collector amasses all 600 bits of data, it calls the graph subsystem to do the BER calculation and display the graphical data.

Using the Aptix reconfigurable prototyping hardware and software, Lucent finished the major part of the UMTS receiver prototype in nine months.

See related chart