Producing an Effective WLAN Prototyping Platform

Producing an Effective WLAN Prototyping Platform
By Maryse Wouters, IMEC, CommsDesign.com
August 28, 2002 (9:04 a.m. EST)
URL: http://www.eetimes.com/story/OEG20020828S0010

With wireless LAN (WLAN) adoption continuing to soar, design engineers are being pushed to develop more standalone 802.11 radios as well as embed more 802.11 radios in a host of consumer electronics devices. With that in mind, developers are crafting WLAN systems that handle the 802.11b, a, and g specifications.

Building a multi-protocol WLAN system is not an easy task. Designers must achieve high levels of integration while still meeting the demanding specifications laid out by the 802.11 committee. On the standards front, prototyping platforms can help. Through these platforms, designers can ensure that their system design meets the performance requirements of a WLAN before committing to final silicon.

Rapid prototyping for current and next generation WLAN systems can only be achieved by defining platform concepts that shortens the development time. These concepts also make the platform more accessible for the application engineers by raising the abstraction level of the hardware and software. In this article, we'll detail the key ingredients designers need to implement when developing a WLAN prototyping platform. We'll also detail several platforms that have been developed using these concepts.

Generic Platform Requirements
When defining any prototyping platform, it is important to layout the basic requirements needed by a particular application. In the case of WLAN system designs, engineers should look for platforms that deliver modularity in hardware board design, modularity in software driver development, flexible integration of intellectual property (IP) cores, and programmable gigabit communication links between components and between boards. Additionally, the platform must support programmable routing of gigabit communication links between components on the board and between two boards.

The WLAN platform should also comply with a standard PC family bus interface. By doing this, a robust prototyping system can be built by plugging several boards in a standard chassis available from many suppliers. The standardized PC bus interface is used for control information exchange and for direct memory access (DMA) between a peripheral processor and the boards in the chassis. Being compliant with a PC standard, the system can be extended with off-the-shelf PC add-on boards, like video adaptors and digital signal processor (DSP) boards.

Achieving Modular Board Design
Modular board design reduces the prototype platform development time because designers can start with a fixed basic schematic netlist for the design of each board and with a fixed and proven routing in the layout. Modular board design means that the same board architecture is used for each board in the system. The only difference between two boards is the component selection to implement the application IP cores. All other components are reused.

Figure 1 displays a typical modular board design architecture. The common components for each board are the central FPGA, the gigabit inter-board data links, the CompactPCI connector, the clock distribution network, the power management unit, and the configuration logic. Typically, the application IP cores for telecommunication systems are a combination of ASICs, DSPs, and soft IP cores that can be mapped on FPGAs. Daughter cards can also be used to keep the base platform generic and board reuse.

The data routing between components is programmable on the central FPGA. The FPGA is the communication control center of the board. It contains a generic communication model that implements a programmable routing of payload data transfer and a control bridge between the application IP cores and the PC bus. This implies for the board routing that all I/O pins of all components are connected to the FPGA pins. Direct routing d oes not occur between two components.

Connecting all the pins to the central FPGA also eases the debugging process. For example a programmable logic analyzer unit on the FPGA can monitor the data on the I/O pins and store it in memory. This data can then be processed and analyzed off-line.

Integrating Application IP Cores
Once the generic platform is setup, it's now time to begin integrating application-specific IP cores, such as an 802.11 MAC, into the WLAN prototyping platform. Application IP cores are easily integrated by adding the footprints of the components related to the application IP cores in the basic board schematic and by connecting the I/O pins of the components to the central FPGA.

In the test and prototyping phase the application IP cores are evaluated separately and the system is built gradually. The communication model on the central FPGA is flexible to add new components in the system. The processor programs the communication links that are active.

The most co mmon interface used for the payload data is based on a synchronous first-in, first-out (FIFO) memory interface. Through this interface, common clocks are used for read and write together with empty and full flags.

The FIFO connected to the data output of a component is called an initiator while the FIFO connected to the data input of a component is dubbed a target. To transfer payload data between the initiator and target FIFOs, an arbiter is required to provide flow control in the WLAN prototyping platform. A shared payload bus is also needed

The flow control parameters of an initiator FIFO are the address of the target FIFO and the number of words that has to be transferred. The user can activate a communication link by programming these parameter. Once data enters in the initiator FIFO a request signal is sent to the arbiter to gain access to the shared payload bus. The arbiter sends a “grant” when the bus is free. If the target FIFO is not full, the data is transferred. If the FIFO is full, the data transfer is aborted without loss of data.

The arbiter is based on a round-robin system. It supports every clock cycle a data transfer requested by another initiator FIFO. This means that request signals of the components are handled sequentially.

Since components share the same bus, designers must turn to a high-speed bus when developing a WLAN prototyping system. For a Virtex-II FPGA with speed grade --4, designers can achieve a maximum bus bandwidth of 1.28 Gbps, which allows designers to connect up to 20 FIFOs on the same bus.

Interboard Payload Link
When developing a WLAN prototyping system, each board should have a standard PCI family connector so that it can be plugged into a slot on the backplane of the rack (Figure 2). The PCI bus transports data and control information between the boards in the rack.

A standard PCI bus is 32- or 64-bit wide and operates at 33 and/or 66 MHz. The access time to the shared PCI bus depends on the processing state of the PCI arbiter that grants the bus to a board in the rack. For WLAN systems, no latency is tolerated when transferring payload data between boards. This reduces the functionality of the PCI bus towards command and control instructions as well as to handling direct memory accesses (DMAs).

For payload data transfer between boards, designers should implement serial gigabit data links alongside the PCI bus. These data links can be achieved with off-the-shelf serial transmitters and receivers that currently support data rates up to 1.4 Gbps. The connections between the boards can be made at the front panel over twisted pair, coaxial cables, or fiber optic cables. Note: FPGA developers are also reacting to the need for gig abit links by integrating serial transceivers on upcoming FPGA designs.

Proving the platform for WLANs
Based on the platform concepts discussed above, designers can develop a library of boards for prototyping current and next-generation 802.11 WLAN systems. Let's see how.

In the physical layer of the WLAN standards three distinct parts can be recognized: the digital baseband modem, the radio front-end, and the medium access control (MAC). Typically, ASICs and FPGAs are used to implement the baseband functionality like the forward error correction (FEC) scheme and the modulator/demodulator. The analog radio front-end can be discrete or integrated as a system in a package. The MAC layer, which coordinates the access of multiple terminals to the common radio channel, runs in software on the DSP for the non-time critical functions and on a dedicated embedded MAC processor to handle the time critical functions. This results in a WLAN terminal platform set-up with a peripheral processor board a nd two boards that are built following the modular platform concepts. This platform will include a general-purpose digital board with programmable hardware for the baseband functionality and a general-purpose front-end board with a socket for analog front-end daughter boards. The terminal configuration is shown in Figure 3.

An implementation of the board library is done by IMEC for prototyping and demonstration of research results in the field of multimedia and WLAN applications. For the prototyping platform the CompactPCI interface was chosen because of its form factor 6U (width = 160 mm, height = 233 mm) and its robustness. The standard 19-in. rack with CD-ROM, power supply, and hard disk makes the platform transportable.

The IMEC boards are shown in Figure 4. In this figure, the modular board d esign with the common components like the central FPGA, the dedicated high-speed data links, the CompactPCI connector, and the power management unit are clearly visible on both boards. The layout and the critical routing between the central FPGA and the CompactPCI connector are reused for both boards.

The multi-million gate FPGA as application IP core makes the digital baseband board generic for use in different application domains like multimedia and WLAN. For WLAN, the baseband orthogonal frequency division multiplexing (OFDM) modem is mapped on the FPGA. An implementation of a 72-Mbps programmable WLAN OFDM baseband modem enhanced with adaptive loading functionality has been developed and mapped on a Xilinx XC2V6000 FPGA. The implementation consumes 48% of th e slice resources and 86% of the multiplier resources. The OFDM modem encompasses all functionality of the 802.11a physical layer except channel encoding/decoding. Adaptive loading is an enhancement on the standards to improve the performance without adding redundancy in the data stream. It exploits the frequency diversity of the channel by assigning an optimal bit loading to each subcarrier.

During prototyping, the RF front end is developed using a daughter card that plugs into the digital board. In this way, families of discrete and integrated front ends can be evaluated on the same digital motherboard. An extra benefit here is that noise coupling is avoided.

The digital board's central FPGA housed on the board with the RF front end can still implement system specific functionality to close the control loops over the analog and digital domains like automatic gain control (AGC) and I/Q imbalance compensation and to do up/downconversion to IF.

The 1.4-Gbps serial links are used to execute commu nication links across the boards. It's important to note that multiple antenna systems, such as SDMA and MIMO, can be prototyped by putting several front-ends and one WLAN baseband modem in the chassis.

About the Authors
Maryse Wouters is team leader of the telecommunication and multimedia system integration team at IMEC. She receiver her MS degree in Electrical Engineering from K.U, Leuven in Belgium. Maryse can be reached at woutersm@imec.be.