Programmable Logic

FPGAs and Drop-in Modules

A design for a digital audio transmission system is aided by existing core modules.

by Steve C. Durham and Brian J. Warren

Current analog FM radio broadcasting systems are approaching the limits of technical improvement. And, with the introduction of digital audio technology--compact disks, digital audio tape, etc.--technical standards have been set far beyond those achievable with FM systems.

Digital audio broadcasting (DAB), which allows CD-quality sound to be transmitted to a home or automobile receiver, is staged to become the next generation of AM/FM radio. The digital link serves as a vastly superior and viable replacement technology for existing systems. In addition to audio broadcasts, DAB allows the background transmission of data such as fax transmissions, stock reports, or any other one-way communication--data which can be downloaded in the background at the same time that music is playing. Another key feature of DAB is dynamic reconfigurability--the ability to add, delete, or modify data and audio services without impact to remaining transmissions. In addition, the digital nature of DAB makes it possible to interface with computers and other digital systems. To bring the advantages of this technology to the marketplace, the engineering team at CoDesign (Portland, OR) set out to develop a high-quality DAB system. The team decided to use PCI-based architecture for the system, leveraging the personal computer interface and dynamic configurability offered by PCI technology. The system was implemented with FPGAs and drop-in PCI modules from Xilinx Inc. (San Jose, CA), thereby simultaneously providing for essential reconfigurability and minimizing development time. In addition, a few functions were implemented using a semi-custom ASIC approach.

The DAB system and digital transmitter The high-level DAB system is similar to traditional communications systems in that it is fundamentally composed of a transmitter and receiver. The resulting link, however, goes far beyond conventional AM/FM broadcasting systems in that it connects the listener to CD-quality music and to data services. The transmitter encodes CD audio as well as data into a digital broadcast stream. This stream is modulated and broadcast to fixed and mobile receivers. The receiver decodes the digital data, then either plays the high-quality music or routes the data service information. Our design team was given the task of designing and developing the digital transmitter section of the system. The DAB transmitter is a multi-level encoder that adds layers of processing protection to the digital source data in order to faithfully transmit it in the broadcast environment.

To accomplish this task, the DAB transmitter groups the data into 24 msec blocks containing a set of bits in a specified format. This format has three parts: (1) a header section for receiver synchronization; (2) a data encoding section that adds the data to a special set of codes, which makes the signal more resistant to such broadcast hazards as noise, interference, and multipath; and (3) a multiplexing section to combine several sources, such as radio programs and data services, at the output. The flow diagram for the transmitter shown in Figure 1 illustrates the partitioning of these transmitter functions into three basic "card" types: header generator, data stream encoder, and multiplexer (referring to the partitions as "cards" reflects the intended implementation of each partition as a PCI card).

The partitioning of the header generator, data-stream encoder, and data multiplexer into card-types offers several advantages. Since the number of data stream encoder cards (type 2) will differ for any given system, this partitioning eases reconfiguration by the simple addition or deletion of type 2 cards. Also, the partitioning of the header allows the control of the other functions without requiring real-time input.

Figure 1. The partitioning of functions and data flow into three basic card types facilitates eventual PCI implementation.

The broadcast station for the system consists primarily of a technician with a PC, an open PCI slot, and the Windows '95 or NT operating system (see Figure 2). The basic system requires one header generation card (type 1), one multiplexer card (type 3), and a transmitter card (type 2) for each of the audio and data services being offered. It is isolated from the local PCI bus through a PCI-PCI bridge. The system enables a high level of control by the operator while permitting "plug and play" system configuration, and it places priority on the efficient use of the PC's resources.

Hardware flexibility, efficient bus utilization, and ease of user interface were our goals from the outset of this design. In addition, we had several other development requirements and schedule constraints. We established a very aggressive one-year schedule for system development. To compound this challenge, our development staff was very limited. Finally, the system specification was not frozen and was likely to undergo further revision throughout the development cycle--meaning a flexible design methodology was clearly indicated.

Transmitter design process After reviewing the system requirements, the design constraints, and the basic architecture of the design, our team started work on the transmitter. Even though the design concept was fairly clear to us, we still had to make refinements to the design methodology and hardware implementation. To make these changes, we devised a methodical design process that included functional partitioning and timing analysis.

In the first step, we broke the design down into functional blocks so that the blocks could be examined independently of each other for appropriate silicon implementation. The header section, which contains the master controller functions and the system clock, controls data stream processing. Hence, the system is governed by "data push," rather than "data pull." That is, interfaces at each block send the data to the next stage and react to the completion of data input, rather than store the input and wait for action from the output. The design of the transmitter's system not only called for a proper functional architecture, it also required the hardware in the header section to have the appropriate controller architecture. The functional components of the data stream encoding and multiplexer sections are also delineated for subsequent timing analysis and silicon implementation.

After partitioning the entire design into functional blocks, we then performed timing analysis. The flow of data through the audio channel as well as other data services was real-time, but relatively slow. Also, it was only a single bit wide. Fortunately, hardware implementation for the data encoding functions of the transmitter could be based on design flexibility, rather than other non-performance criteria. Likewise, the header section, which only processes data flows, allowed us to choose devices on criteria other than speed.

The multiplexer section operates at a data rate of several MHz and is 16 bits wide at the level of the FI symbol generator and the symbol sync generator. Hence, performance requirements limited our choices of technology for this section.

Key implementation decisions Before we commenced with the next step, we had to decide whether we were going to use ASICs, microcontrollers, or FPGAs. We tried to avoid an ASIC implementation of functions because of the inherent design risk if changes were required. Microcontrollers allow improved flexibility over ASICs but are constrained in the way functions are carried out--often resulting in a sub-optimal trade-off between area and speed for certain applications such as DSP algorithms. Because of the critical importance of reconfigurability and, perhaps the even greater importance of design flexibility due to requirement changes, we picked FPGAs for this system. In addition, drop-in FPGA modules (specifically, the Xilinx LogiCore PCI Interface) offer significant savings in the area of training, development, and verification time. FPGA technology matches the performance of low-end ASICs and provides the ability to meet the short design cycle with limited resources and with minimum design risk.

Further, given the PCI-based architecture of the system, we had to decide whether to develop the PCI capability or to deploy off-the-shelf technology. Due to the schedule and manpower limitations of this project, and also to the availability of pre-defined drop-in PCI modules, we chose to use drop-in modules.

An FPGA-based DAB transmitter implementation With only a few exceptions, all functions within the DAB transmitter were implemented using Xilinx 4013 and 6200 FPGAs that were backed with memory for large memory structures. A block diagram which could represent any of the three card types already described is shown in Figure 3. The diagram illustrates the use of the 4013 array with the PCI drop-in (LogiCore) module and the user-designed back-end bus interface. The PCI target module was pre-verified, and was essentially dropped in with only a few minor changes. With the complicated PCI target taken care of, the team then focused its efforts on a simple back-end bus interface. The back-end interface employs several user-programmed functions, including a Xilinx drop-in FIFO module for the pass-through interface.

Figure 2. The transmission portion of the DAB system provides a PC-based interface and employs PCI for user control and resource management.

We also implemented the FIB assembler (part of the header generator function) using the reconfigurable 6200 FPGA. The assembler essentially takes a packet of input data, attaches header information, then calculates a CRC (cyclic redundancy check) in real time. One problem we faced was that the packet size and the CRC calculation for that packet must change instantaneously. Because of the range of possible packet sizes and the need to maintain both data structures during the transition, this function would prove far too silicon-intensive using ASIC or controller approaches. In contrast, a reconfigurable FPGA handles this problem well, dynamically restructuring itself when transitions occur.

Despite the attractiveness of FPGA technology for the design objectives of this project, a number of functions required implementation with alternative technologies. One such function was a fast Fourier transform (FFT), which forms part of the FI symbol generator in the multiplexer section. The repeating structure of an FFT, a "butterfly," is made of a group of multiply-accumulators (MACs), and hundreds of butterflies are required for the performance of this section of the design. Although an FPGA could handle the clock rate, the density is insufficient for all of the required butterflies. The SHARC processor from AMD Inc. (Sunnyvale, CA) was determined to be the only processor that could perform the operations in time, and, hence, it was the choice for this function.

In addition to the FFT, two other functions were implemented in non-FPGA technology. The audio compressor's data complexity was too high for a flexible FPGA implementation, so a semi-custom ASIC solution was chosen. Finally, a RISC processor was chosen to implement the main controller function of the header generator.

Pros, Cons, and the future The system is currently under development, and it is meeting or exceeding all design objectives. The constraints on the design team might have been insurmountable without the capabilities offered by FPGA technology and the drop-in module. Clearly, dynamic reconfigurability and flexibility are fundamental to the design of the DAB system, and an FPGA contains both features. The reconfigurability of FPGAs allow the design to effectively reuse the same silicon for changing algorithms, thereby reducing system cost. In addition, the use of the Xilinx drop-in PCI module has resulted in substantial productivity gains for the design team--an estimated reduction in effort from six man-months to one man-month.

For all its strengths, the design solution is not without room for improvement. The implementation requires designers to have at least intermediate-level expertise in the areas of PCI knowledge and in Xilinx FPGA design. While this is not seen as a major drawback, a more fool-proof system would be desirable so that design teams could have more flexibility in allocating resources.

Figure 3. FPGA drop-in module and configurable logic facilitate a flexible and efficient system design.

Unforeseen system requirements created problems, but they should be rectified over time. The system requires Windows '95, from Microsoft Corp. (Redmond, WA), as one of two possible operating systems for the transmitting PC. Unfortunately, this operating system is penetrating the market at a much slower rate than originally expected. Additionally, PCI is widely heralded as the preferred communications bus standard for coming years. However, the transition from other standards is sluggish, and many host systems still do not support PCI. Both of these issues are seen as temporary, as both Windows '95 and PCI are gaining substantial momentum in the marketplace.

The design team was not overly constrained by cost considerations on this project. If we had been, perhaps more effort would have been dedicated to identifying functions that could have been implemented with an ASIC approach. The FPGA-intensive implementation virtually eliminates NRE expense, but it can be costly in the long run if production volumes are high. Finally, the design environment, while certainly effective for the task at hand, could be improved if it offered more implementation flexibility for designers.

In closing, the DAB system, based upon PCI architecture and enabled by FPGA technology, provides a significant new capability to the marketplace. DAB is an exciting new technology--one that stands to replace standard AM/FM broadcast systems in the not-too-distant future. In fact, the first wide-scale DAB systems are scheduled to be rolled out in Europe in October of 1997. Given the rapid evolution of the DAB segment of the communications industry, the flexibility and speed of design afforded by the described approach are pivotal to the success of DAB systems developers in bringing this technology to the market.

Steven C. Durham senior software engineer at CoDesign (Portland, OR).

Brian J. Warren senior design engineer at CoDesign.

To voice an opinion on this or any Integrated System Design article, please e-mail your message to michael@asic.com.

integrated system design  January 1997