For a PDF version of this article, click here.

In the highly competitive race for higher performance at the system level, cutting-edge technology must be incorporated, even though hardware resources and software support for new devices are often far from stable. With time-to-market crunches, limited-development resources and no tolerance for trial and error, today's project managers are urgently seeking lower-risk strategies for embedded-system development.

Innovative board vendors are anticipating the needs of their system integrator customers and offering additional products and services to help them overcome these obstacles. Successful initiatives include enhanced, board-support packages for complex peripheral functions, high-level tools for developing and installing custom algorithms on field-programmable gate arrays (FPGAs), and complete subsystem offerings to handle critical sections of a larger system.

Virtually all open architecture, board-level products for embedded systems strive to support a wide range of applications. As a result, they are designed to be as flexible as possible through programmable configuration so the customer can tailor the operation to a specific task.

Single-board computers (SBCs) are usually the heart of an embedded system. Because they tend to be high-volume commodity products, they are often delivered with an operating system and a so-called board support package (BSP). This includes drivers and libraries to support various board resources, memory management, DMA data transfer operations, communication links and interfaces to the system and backplane. Written for a specific operating system, each BSP must be fully compliant with the software development suite offered by the OS vendor so the customer can start writing his application at a relatively high level, usually in C.

Other boards in the system are often specialty boards targeted to meet specific application requirements such as data acquisition, software-defined radio, digital-signal processing, data storage, and high-speed digital interfaces. These boards usually lack a general-purpose processor and come with no standardized BSP support. Nevertheless, the SBC is often responsible for controlling and interacting with these boards across the backplane to make them work.

In the early days, vendors of these specialty boards presented customers with memory maps of each of the various resources such as the address range for memory resources and registers for control and status. A written description of the function of each bit in the control and status registers was often the only information the system engineer received in the way of a board support package. If the board contained an ASIC device, the customer was also given a copy of the manufacturer's data sheet to support any programmable registers within that device, and not much more. In this case, the system engineer was forced to become intimately familiar with the details of the hardware devices and often had to refer to schematics of the board.

As devices on boards became more complex, a few insightful board vendors listened to their customers and developed a successful strategy to handle the problem. Low-level bits and control words for the hardware devices are now abstracted using a consistent naming strategy for all these programmable variables. These variables are then arranged in logical groups and defined within C language data structures that can be easily manipulated.

High-level, C-callable library functions referencing these variables and data structures handle the most common operations — including initialization, passing of control parameters, interrupt generation and handling, data transfers and DMA operations — and built-in-test (BIT) functions. These functions are organized in several hierarchical layers with the upper level functions calling lower level functions. At the bottom layers, assembly code may sometimes be necessary.

Full source code is supplied for all functions at every level so that if the high-level functions fall short of achieving a particular mode of operation, or if the function is too slow because of unnecessary generality, the system engineer can drill down to whatever level he needs to resolve the problem. This strategy has proved to be extremely successful and is implemented in the Pentek Ready-Flow Board Support Library offerings. As an important added benefit, these libraries serve as an excellent basis for developing drivers for specific operating systems.

One of the most-popular technologies for real-time signal processing is the field-programmable gate array (FPGA). Originally used to replace glue logic and state machines, programmable logic steadily acquired higher densities and more memory. As capabilities of these devices evolved, savvy customers began to implement basic signal-processing functions such as digital filters, averagers, digital scaling, waveform generators and matrix operators.

Recognizing this important new market, FPGA vendors started adding specialized resources targeted to boost performance for signal-processing applications. Now virtually all of the latest device offerings from major FPGA vendors include ready-to-use building blocks for DSP applications. These include dedicated multiplier engines and flexible memory structures that can be tailored into block memory, dual-port RAM, FIFO memory and shift registers. Sophisticated logic structures such as logic slices help implement complex, signal-processing functions.

Once again, the mounting level of complexity within these devices challenges system engineers to reap their widely publicized benefits. While the high degree of parallelism of FPGAs can deliver a ten-fold improvement in algorithm execution speeds over general-purpose programmable RISC and DSP processors, finding the right combination of talent and tools to make it happen can be quite difficult.

With a long history of using programmable logic, hardware design engineers understand the practical issues of configuring FPGA RAM and logic blocks, and dealing with pin loading, race conditions, propagation delays, power dissipation, clocking and synchronizing issues. On the other side of the lab, software engineers are much more comfortable implementing DSP functions on programmable processors using C. These rival camps are often thrown together to rescue a faltering schedule for an FPGA-based system, and usually with mixed results.

Several solutions have emerged to address these problems. Many DSP algorithm engineers/DSP programmers create and validate algorithms and even entire signal processing systems on popular workstation tools such as MATLAB. During development, powerful signal generation and analysis tools enable designers to verify correct operation, validate dynamic range performance, and check for exception handling.

After validating a DSP system, HDL code generation tools, such as SIMULINK, interface directly with the FPGA design tools. Once in the FPGA development and verification environment, SIMULINK continues its role by providing hooks for stimulus test vectors and return paths for analysis of output signals. In this case, the signals are operating on simulation models of actual FPGA structures. MATLAB and SIMULINK are both products of MathWorks, and are well integrated through compatible links to Xilinx and Altera FPGA design environments.

Another solution to FPGA complexity is the vast collection of Internet protocol (IP) core library offerings for FPGAs. Targeted for specialized functions, each represents a highly optimized structure of FPGA resources, usually supplied without source code in object form. When installed in a compatible FPGA development tool environment, they appear as objects that can be dropped into the block diagram and connected into other design elements using sophisticated graphical editors.

Major FPGA vendors such as Xilinx and Altera offer a long list of free and licensed IP cores, but even more impressive is the emergence of a thriving new industry of third-party IP core vendors. Each vendor crafts IP core offerings using the company's expertise in specific niche technologies. This enables a broad class of FPGA users to take advantage of the extensive testing, documentation, standards compliance, speed and efficiency that might otherwise be unattainable with reasonable effort. The use of IP cores is a cost-effective strategy to significantly slash FPGA development cycles for new technology products.

Even with all of these high-level design tools, VHDL code generators and IP FPGA resources, the system engineer is still required to port his new custom FPGA algorithm into a specific COTS board with its unique set of connections to peripheral devices, buses, memory and high-speed data converters.

The board vendor usually delivers a standard, off-the-shelf version of the board with VHDL structures already in place within the FPGA to implement a basic set of operations for control, status, data formatting, triggering, gating and channel selection. If the customer tries to insert his algorithm in the midst of this VHDL code, he runs a high risk of breaking the standard functions and interfaces.

An alternative scenario would be for the customer to replace the off-the-shelf factory FPGA code with a new FPGA configuration code that re-creates all of the peripheral interface structures carefully integrated around the new custom algorithm. But this requires the customer to become intimately familiar with every peripheral device and wastes the significant VHDL coding effort by the board vendor.

A far better solution is the so-called FPGA design kit. Here, the board vendor constructs the VHDL modules for the standard factory functions as discrete building blocks, each with well-defined signal naming conventions, fully commented code and straightforward interconnections.

Even more significant is a new special VHDL module called the user block, designed with well-defined input and output data pins, control and status ports, and clocking structures. The user block is located directly in the data path to the main system interface, usually a bus or data port. In the standard factory configuration, the user block has its input and output pins tied together with a straight wire, so it is basically a transparent data pipe.

The customer receives a safe, flexible workspace, situated strategically in the center of a powerful hardware environment. If he designs his custom algorithm within the definition of the user block, he can recompile the FPGA project with all of the other VHDL modules intact and achieve a very low-risk FPGA development experience. In fact, Pentek offers its highly successful GateFlow FPGA design kit using this exact paradigm.

Researchers at the Georgia Institute of Technology have been collaborating in the development of a wireless prototype supported by the Georgia Electronics Design Center (GEDC) and the Georgia Research Alliance. The goal of this investigation is to demonstrate the feasibility of Gigabit wireless communications.

The research team has made major advances toward this goal by using a programmable software radio test bed to implement multiple-input, multiple-output (MIMO) systems employing orthogonal frequency division multiplexing (OFDM). MIMO systems use multiple antennas at the transmitter and receiver to achieve increased data throughput in high-speed data applications. In an OFDM system, a single high-speed bitstream is separated into several low-speed bitstreams, with each of the slower bitstreams modulating one of several carriers.

Key subsystems integrated into the test bed include smart antennas with switched-element architecture and with provision for switched beams, wideband digital downconverters, wideband digital upconverters, wideband A/Ds and D/As, signal processor boards, I/O interfaces to PCs, and FPGAs for more computationally demanding algorithms such as forward error correction (FEC) coding/decoding and matrix inversion.

Among others, the application software used to speed development includes the Pentek SwiftNet DSP networking and communication software, MPI Software Technology's VSI/Pro, the Texas Instruments Code Composer Studio and the Wind River Tornado Tools. There are also the Pentek ReadyFlow Board support libraries and the Pentek GateFlow FPGA design kit.

The programmable software radio test bed is housed in the VMEbus enclosure, as shown in Figure 1. With the exception of RF and IF sections, the signal-processing boards in the enclosure are from Pentek.

The test bed is used in two distinctly different modes of operation:

• real-time data capture and off-line processing and analysis;

• wireless gateway between two Ethernet networks.

Mode I serves as a means to efficiently conduct wideband wireless testing to evaluate antenna selection algorithms, MIMO antenna designs, and receiver processing algorithms — such as channel estimation, signal detection, synchronization, demodulation and decoding.

In addition, this mode permits the demonstration of high bit-rate communications using arbitrary waveform generators at the transmitter and wideband multichannel digital downconversion and recording for offline processing at the receiver.

This mode has the advantage of offering a highly flexible and convenient architecture to test a broad range of waveforms and receiver processing algorithms, without the time-consuming tasks associated with developing real-time implementations of the desired algorithms in DSPs or FPGAs.

Currently, the system operates in a 4×4 configuration (4 transmit × 4 receive antennas), with a spectral occupancy of 28 MHz yielding peak bit rates of 672 Mbps. The goal of future development is to extend the system bandwidth to 40 MHz and achieve peak bit rates of 960 Mbps.

In mode I operation, the system employs synchronized, arbitrary waveform generators to create spatially multiplexed datastreams that have been optionally encoded using FEC coding schemes and quadrature amplitude modulation (QAM) signaling constellations of OFDM subcarriers.

As shown in Figure 2, the waveform generators upconvert the complex baseband signals to the RF carrier frequency. They can then replay the sampled data at variable rates to achieve the desired modulation, width, and data transmission rate. Data captured in the Pentek 4294 Quad PowerPC processor boards is transferred to a PC for offline processing and analysis.

In the second mode, the test bed operates as a wireless gateway between two Ethernet networks. It incorporates the physical layer, media access control (MAC) layer, TCP/IP and application layer functionality. MAC is a hardware address that uniquely identifies each node of a network.

As shown in Figure 3, the system block diagram includes Ethernet hubs to independent networks, PCs providing MAC functionality, VME systems serving as physical layers, and host PCs at both ends of the wireless gateway. The system supports multiple servers and clients. Using TI DSP processors, the system has achieved real-time speed with test bed sampling rates of 8 MHz.

Multiple clients on one network can access servers on a separate network through the wireless gateway by generating a request on the associated client host PC. The request is passed via Ethernet through the hub to the terminal of the wireless gateway. The MAC layer in the gateway strips the Ethernet header and adds a header for the gateway. A preamble is added by the DSP processor prior to transmission that permits packet detection, synchronization, channel estimation and demodulation at the receiving terminal of the wireless gateway.

At the receiving end, demodulated data packets are reformatted for Ethernet transmission, forwarded to the Ethernet hub, and routed to the appropriate server.

The baseband processing at the transmitter includes QAM mapping, space-time coding and OFDM signal generation. As shown in Figure 4, this processing is achieved in the Pentek model 4291 Quad C6701 DSP processor board and associated VIM-2 modules.

Forward error correction coding and decoding can be integrated using the FPGAs of the Pentek 6250 configurable logic FPGA VIM-2 module. Cores for Reed Solomon coding and decoding have been successfully implemented in the user block of the 6250 FPGA. In their present configurations, the coder and the decoder can accommodate data rates up to 240 Mbps.

Two of the four DSPs perform the QAM and space-time coding, while the other two perform an Inverse Fast Fourier Transform (IFFT) and add the information necessary to enable proper processing by the receiver. The I and Q outputs of the Pentek 4291 are then upconverted to IF by a Pentek model 6229 digital upconverter VIM-2 module with dual D/A converters.

As shown in Figure 5, the receiver end complements the processing at the transmitting end. The IF signal arriving from the RF receiver and downconverter is fed to a Pentek model 6235 A/D and digital downconverter VIM-2 module. A Pentek model 4291 quad DSP processor performs a forward FFT to convert the received time-domain signal back to the frequency domain. This processor also performs channel estimates, demapping and data transfers. When FEC is employed, a Pentek 6250 with the Reed Solomon decoder core can be added to the processing chain.

The output is then sent to the wireless gateway PC for MAC coding and decoding and subsequent transfer to the Ethernet hub and the corresponding server.

Work on the wireless gateway is proceeding toward the development of a real-time system with a 20 MHz sampling rate that could eventually achieve peak bit rates of 384 Mbps in the physical layer. This system will use the Pentek 4294 PowerPC processor and the higher-speed, Pentek model 6228 quad digital upconverter and D/A VIM-2 module.

With a finger on the pulse of embedded system integrators, board vendors have begun offering functional subsystems consisting of one or more open architecture boards bundled together with software and firmware that implement a complete functional section of a larger system.

These subsystem offerings include complete performance specifications that can be incorporated within a proposal bid by a system integrator. This dramatically reduces risk for the system integrator in schedule and cost and creates higher perceived credibility in the eyes of the end customer.

Design of these subsystem bundles must be done carefully to ensure a high degree of modularity in the hardware and software components, since it is likely that some modifications may need to be done to meet specific program needs. Nevertheless, because he is intimately familiar with the hardware, the board vendor can optimize parameter passing and data transfer operations within the subsystem for best performance over a wide range of applications. Built in diagnostics (BIT) and example code are attractive adders.

It is also imperative for the board vendor to develop a complete subsystem application-programming interface (API) so the system integrator can easily interface with other system hardware products and software environments.

As an example, Pentek offers its RTS2501 real-time wideband recording and development platform (Figure 6). It features four 105 MHz 14-bit A/D converters, four Virtex-II FPGAs, a G4 PowerPC processor and a 160 MB/s Fibre Channel interface — all in a single 6U-VMEbus slot. A graphical user interface (GUI) example application for Windows uses the API to implement a complete four-channel, real-time recording system.

Escalating complexity is the hallmark of the embedded system market, and more than ever, expertise in niche areas of technology more clearly distinguishes one vendor from another. Abstracting that expertise so that it becomes usable by a wide range of customers is essential for adoption and deployment. Board vendors who offer clever strategies for solving system problems with these high-level solutions for hardware and software integration will win customer loyalty and lead the industry.

Rodger H. Hosking, vice president and co-founder of Pentek, is responsible for new product definition, marketing and sales, and strategic alliances with third-party hardware and software vendors. Earlier, Hosking served as engineering manager and project engineer at Wavetek and Rockland Systems. He earned a BS degree in physics at Allegheny College and BSEE and MSEE degrees at Columbia University. Hosking has published a number of articles in industry publications and presented numerous papers at technical conferences.

RSS    Save to Del.icio.us  Digg This