Bridging the Wi-Fi/Embedded Divide

Bridging the Wi-Fi/Embedded Divide
By Mao Wang, QuickLogic, Courtesy of Wireless Net DesignLine
Apr 5 2005 (3:40 AM)
URL: http://www.embedded.com/showArticle.jhtml?articleID=160403081

Incorporating wireless connectivity in embedded systems is becoming very popular, but it faces challenges. A major concern is that the embedded processor's bus structure is often incompatible with the wireless device's interface. Fortunately, programmable logic can be used to bridge the two buses, but the selection of a bridge architecture and logic technology will have a significant impact on the design's cost, the software development effort, and battery life.

Ubiquitous connectivity is becoming widespread as consumers and enterprises get accustomed to continual access to information resources. As a result, traditional information appliances, such as PDAs, are adding telephony capability for voice and data transmission. In more traditional embedded systems, connectivity allows devices to report information to a central clearinghouse as well as obtain information from outside sources. The many benefits of connectivity are quickly turning it into a "must-have" feature.

Wireless connectivity is now an essential feature for portable embedded systems, which by definition must operate without cables. But wireless also has its benefits for stationary systems when cabling is impractical or costs are high. Systems such as point-of-sale terminals and surveillance cameras, for instance, become easier to implement when they offer wireless connectivity instead of requiring cable connections.

The Wireless/Embedded Dilemma
Choices abound for implementing wireless data connections. Designers can select from several varieties of Ethernet (802.11) as well as Bluetooth, cellular telephony, ZigBee, ultra wideband (UWB), and others for implementing a wireless link. Unfortunately, most of the chipsets for implementing these communications protocols and RF links for wireless were developed for the personal computer (PC) or cell phone markets. Because of this, many chipsets utilize either the PCI bus or secure digital I/O (SDIO) for their host processor connection.

Embedded systems, on the other hand, use a wide range of low-and mid-performance processors that often have only a simple memory-mapped interface. The interface seldom matches the bus structures of high-performance processors for which bridge chips may already be available.

This leaves embedded system designers with the dilemma that many of the wireless chipsets they need cannot directly connect to the processors they want to use. For SDIO chipsets, the serial peripheral interconnect (SPI) bus available on many embedded processors may be an option, but the performance of the interface is limited. Cost considerations as well as the existence of legacy software make changing processors an undesirable option.

The only other alternative is for designers to implement logic that will bridge the CPU interface to the wireless chipset's bus structure. This is often a challenging task. For one thing, the two buses may not have the same bit width, requiring that the bridge provide data formatting. Further, the PCI and SDIO buses do not allow for the simple memory-mapping typically used in embedded systems.

The PCI bus, for instance, requires a complex protocol for the transfer of data. The SDIO bus requires frequent polling, tying up the CPU resources. In both cases the bridge needs to provide data buffering along with the protocol logic so that the CPU can be performing other tasks during the data transfer.

Another constraint on the bridge design comes from power concerns, especially for portable systems. Most portable designs now use active power management to extend battery life. Active power management shuts down circuit blocks when they are not actively engaged in their function. This means that both the wireless chip set and the bus bridge logic must be able to be powered-down and re-activated at will. The bridge design, therefore, must be amenable to being turned off and on.

As with nearly every other design, cost is yet another constraint on the bridge design. Many embedded systems for the consumer market are under market pressure to minimize cost. For them, component cost and the costs associated with extra board space are critical elements, so the bridge design needs to be as compact as possible. This implies a single-chip solution instead of discrete logic. Yet development cost is also a major concern in many embedded systems. Most designs simply cannot justify the mask charges for an ASIC-based approach, even structured ASICs, because rapid changes in technology and feature set requirements make product lifetimes too short to amortize the costs.

FPGA Bridges Buses
One solution is to use a field programmable gate array (FPGA) to serve as the bridge device. The libraries of pre-defined functions available for FPGAs typically include most standard component bus interfaces, so the bridge design is already half done. The flexibility of the FPGA also allows developers to adapt the design to a variety of different CPUs, enabling the design to be used in multiple projects with minimal modification. Complex programmable logic devices (CPLD) also seem to offer these advantages, but they typically do not offer the memory resources needed for buffering.

Designers seeking to utilize FPGAs have several choices to consider when implementing bridges to wireless devices. One choice is the type of FPGA to use. Another is the architecture of the bus bridge; both simple and bus-master styles are candidates. The impact of these choices on the design's cost, performance, power demands, and software compatibility must be considered.

For choosing an FPGA, the market offers three base technologies: SRAM-based, EEPROM-based, and anti-fuse based (Figure 1). SRAM-based devices use SRAM cells to hold the programmed values controlling the switch transistors that make the logic circuit connections within the array. EEPROM-based devices use the same basic approach, but employ non-volatile EEPROM cells to hold the programmed values. Anti-fuse-based devices do not have memory cells or switch transistors. Instead, programming an anti-fuse-based device creates permanent logic circuit connections directly.

Figure 1: The three types of FPGA technology on the market use different ways of storing the logic configuration. Two use memory cells to activate a switch transistor while the third uses a fusible link to establish the required connection.
Each technology has its benefits. For instance, SRAM-based devices have large amounts of memory available and support dynamic reconfiguration of the logic design. EEPROM devices are non-volatile, keeping their configuration without requiring constant power, and can be reprogrammed in-circuit. Anti-fuse devices are also non-volatile, but can only be programmed once. Their major advantages are compact logic, resulting in lower cost, and low power demands.
Standby Power Rules Portable Designs
The power demands of the FPGA are one of the most important factors in embedded wireless designs. In particular, it is the system standby power that determines a design's marketability. Embedded applications that need wireless connectivity typically run off a battery and often need to provide between 200 and 400 hours of standby operation for users to consider battery lifetime acceptable. For typical battery capacities, this standby time translates into a current of between 3 mA and 8 mA when the system is in standby operation. To achieve such low standby currents, the FPGA technology choice is critical.
SRAM-Based FPGAs
SRAM-based FPGAs have several significant drawbacks with regard to standby power. The first is that the designs require at least two devices: the FPGA and a boot ROM that holds the program configuration. Two-chip designs typically have a higher standby power requirement than single-chip designs. The time required to load the configuration data into the FPGA upon power-up is also a drawback because it interferes with the system's ability to cycle power as part of active power management.
The most important drawback to the SRAM-based FPGA, however, is its inherently high power demand, particularly its standby and leakage currents. The use of an SRAM memory cell and switch transistor to control each connection point in the array adds up to a significant number of active elements in the array above and beyond the logic itself. In addition, SRAM-based devices with the logic capacity needed for bridge designs are typically manufactured with deep submicron semiconductor processes. Finer geometry processes have larger leakage currents, adding to the device's standby power demand. A typical SRAM-based FPGA's standby current is 50 mA, an order of magnitude greater than is needed to achieve acceptable battery lifetime.
EEPROM-based FPGAs
An EEPROM-based FPGA avoids the need for a boot ROM, making it an improvement over the SRAM-based technology. Yet it also contains the additional active circuit elements and uses deep submicron technology to achieve logic density, creating a relatively high standby current. Its non-volatile configurability does, however, allow the use of active power management to reduce its average power demand.
Anti-Fuse-Based FPGA
The anti-fuse based FPGA is the least power-hungry FPGA technology. The anti-fuse is a non-conducting link across connection points in the array, which is permanently converted to a conducting link during device programming. Because the connections become hard-wired, the array does not need any switching transistors or configuration memory within the array. As a result, the anti-fuse FPGA only needs power for the logic array, greatly reducing the device's standby current. Further, the lack of switching and configuration transistors means that the anti-fuse array is inherently smaller than memory-based arrays, allowing it to achieve the necessary logic density with a larger process geometry that has lower leakage current.
Defining the Bridge Architecture
Along with the FPGA base technology, designers need to consider the bridge architecture they will require. A simple bridge, as shown in Figure 2 for a PCI interface, connects the processor to the wireless chipset without other system interactions. The FPGA's internal memory serves to buffer data passing to the network connection, but the processor must fill and empty those buffers under program control. A simple SDIO bridge has similar simplicity and requirement for CPU intervention.

Figure 2: Bridging between a wireless chipset and an embedded processor can be as simple as having a bus driver with a memory map interface to the CPU, but it requires processor intervention to load and unload data from the bridge buffers.
The bus mastering bridge, like the PCI example shown in Figure 3, includes a memory controller block. This additional function enables the bridge to move data between the system memory and the wireless connection without processor intervention. This bridge architecture is more complex, but frees the CPU from having to be involved in the data transfer and leaves it more time to handle the remaining system functions.

Figure 3: A bus master bridge provides a memory controller so that the bridge can transfer data directly to and from system memory, freeing the CPU from data transfer tasks.
In evaluating the choices for both bridge architecture and FPGA technology, designers have many design parameters to consider. System performance, including the network data rate and latency, may be important in some applications. System complexity, which impacts the cost and design time required, is another factor. Finally, along with the hardware design effort, developers need to consider the impact of design choices on the software development effort.

When the embedded system needs the highest networking performance, for instance, the bus master bridge architecture is the optimal choice. The simple bridge design has both data rate and latency issues because it requires the processor's intervention to move data across the bridge.
As illustrated in Figure 4, the time required for the CPU to respond to an interrupt and retrieve the buffered data directly adds to the latency of the wireless chipset in communicating over the network. This may not pose a problem for data logging systems where communications are intermittent, but it can compromise the effectiveness of systems such as point-of-sale kiosks that may need an interactive audio link between the customer and a remote salesperson.

Figure 4: When the CPU is involved in data transfers, system latency increases significantly.
The CPU's latency in handling data moving across the bridge can also impose a bandwidth limitation on the system. As shown in Figure 5, the size of the simple bridge's buffer memory together with the system's network bandwidth requirement set an upper bound on the time available for the CPU to respond before data is lost.

Figure 5: If the CPU must fill and empty data buffers in the bridge, the size of the buffers affects how much time the CPU must spend and limits the bridge's throughput.
The larger the memory, the more time the CPU has available. Because the amount of memory available for buffers in the FPGA is limited, simple bridge designs may require external memory to achieve the performance a system requires.
A bus master bridge design has none of these issues. The FPGA logic can handle virtually any data rate that the wireless chipset can provide. The speed of the system memory then becomes the main limitation to performance.
Complexity Equals Cost
While performance demands favor the bus master bridge, system complexity concerns favor the simple bridge. All the simple bridge design requires is a basic slave interface to the wireless chipset and a simple memory-mapped bus interface to the processor, along with some buffer memory. Such designs can typically be implemented in a modest-sized FPGA although simple bridges that also require the use of external memory to meet performance requirements will be more complex.
The bus master bridge, on the other hand, needs both the CPU interface and a system memory interface (either an SRAM controller or a DMA channel). This makes it too complex for the smallest FPGAs, requiring a medium-sized FPGA for its implementation.
The choice of FPGA technology can also affect system complexity. An SRAM-based FPGA needs to be configured each time it powers up. This need forces the use of an external boot ROM to supply the FPGA configuration data. EEPROM and anti-fuse FPGAs are non-volatile, avoiding the need for this additional component.
System complexity affects system cost. A more complex design may require a larger, more expensive FPGA. The need for additional components also affects system cost, both in terms of parts costs and in board costs. Each square inch of board space adds to total system cost. While that may not seem significant in some applications, consumer devices are under such tremendous cost pressure that pennies count.
The FPGA choice also affects the system cost for bridge designs, both the cost of the component count and of the board space needed. The least expensive is the anti-fuse-based FPGA. Compared to memory-based FPGAs, anti-fuse technology is able to achieve a higher logic circuit density using a larger process geometry.
This cuts component cost in two ways. First, the higher density produces a smaller die for a given level of complexity, and smaller die size translates directly into lower component cost. The other savings comes with the cost of the fabrication technology. Deep submicron processes are expensive to implement and mask costs for chips are high in comparison to older process technologies. The compact nature of anti-fuse arrays allows them to be implemented on older technologies, resulting in a greatly reduced cost per unit die area as well as lower mask cost.
Bridge Architecture Selection Sets Software Effort
While simple bridges are easier designs to implement, choosing the simple bridge design to reduce hardware complexity complicates software development. The bus master bridge design provides a direct path to memory that matches the typical wireless chipset's intended environment: a PC. As a result, existing drivers and other software for the wireless chipset will run with minor modification on embedded systems with a bus master bridge.
Systems using a simple bridge, however, will need entirely new drivers to handle the need for buffering. Creating such drivers will require both time and expertise that the design team must provide. Wireless chipset manufacturers are often hesitant to support the rewrite of their existing drivers for these unintended applications.
Perhaps surprisingly, FPGA technology choices can also affect software development. The SRAM-based FPGAs require time to load their program from the boot ROM before they are ready for operation. The system start-up software supplied with the wireless chipset may not be able to handle the delay, causing a software failure during system initialization. This, too, forces additional software development.
By considering such costs along with power, performance, and the complexity of both hardware and software design, designers will be able to choose the architecture and FPGA technology best suited to their designs. The architectural choices allow tradeoffs among hardware complexity and cost, software development effort, and performance. The technology choices favor the anti-fuse approach for its lower power and implementation cost. The right combination of technology and architecture, however, can provide embedded system designers with a bridge to wireless connectivity, regardless of the CPU their system employs.
About the Author
Mao Wang is an applications engineering manager at QuickLogic. Mao holds a B.S. degree in electrical engineering and a M.S. degree in engineering management from Santa Clara University. Mao can be reached at wang@quicklogic.com.
Copyright 2005 © CMP Media LLC