Semiconductor

Reconfigurability: Logical Computing

The ability to change the internal logic of computer-based systems can enhance the system performance while reducing device counts. The software trails the hardware in capabilities.

By R.T. "Tets" Maniwa

Many designers are beginning to implement algorithms in hardware instead of software. One technique they are using is reconfigurable logic. Although the present designs are best suited for temporally displaced functions, next-generation hardware and software will enable dynamically reconfigurable computers to change internal configurations to suit computing requirements as the programs call for different resources.

Reconfigurable logic can be designed to operate in a manner similar to software: in blocks or modules with an overlay feature to allow reuse of memory space in the case of the software and gates for reconfigurable logic. Some examples of this type of operation are shown in Figure 1.

The logic can be set up by the boot program to load the FPGA with a configuration to perform built-in self-test (BIST). Upon successful completion of the testing, the reconfigurable logic is changed to perform its other functions. Another of these functions could be to change the data paths and buses for different functions. One part of the data path might require 22-bit-wide operations, and the next part 32 bits. Fixed hardware needs to be designed and built to handle the widest words, which leaves some of the hardware idle for those operations of smaller bit width. The reconfigurable logic can also be set up to perform the bit alignments and be arranged as the DMA controller to transfer data blocks across the reconfigured buses.

A single FPGA, according to Steve Casselman, president of Virtual Computer Corp. (Reseda, CA), is powerful enough. "We try to pick a part of the code that fits into the FPGA," he says, "and then reconfigure the FPGA as different parts of the algorithm need to be processed. This is much more manageable than trying to get many FPGAs working together on one application. The programming time for a single FPGA is hours, versus days or weeks for multiple FPGAs. Look at this as similar to a microcomputer, a single microprocessor plus memory and try to get the logic tightly integrated into the program."

Examples of adaptive hardware algorithms, such as changes in the functions of the logic dependent on the software process, are virtually unlimited, but they require substantial changes in both the hardware and software approaches to the problems. The tools for developing and operating in-system reconfigurable logic are still in a state of relative infancy. Current efforts are in using higher level languages such as C to describe the algorithms and set up a basis for the router software to make the interconnections.

Appropriate architectures need to be developed for reconfigurable computing. "Current products," says Bradley Fawcett, strategic planning manager at Xilinx (San Jose, CA), "are general-purpose arrays. The next generation of hardware products will need attribute-specific features. The software issues could be tougher than the hardware issues because of the lack of an industry-standard hardware platform and robust software to automatically fit an algorithm into an FPGA." Fawcett further speculates that rather than the sequential programming languages now available, the industry needs a data flow control language.

An example of a highly reconfigurable co-processor might be personal computer hardware configured as a graphics/Windows accelerator while in GUI mode, but getting reconfigured as a math accelerator when doing a Spice run. The operating process would change the math accelerator to be optimized for floating point functions at one time, then for matrix calculations at another time. All of this would be transparent to the user. It would be a major headache for the hardware and software developers, however. The operating system will need to store register contents, control states, and sequences of the resident and non-resident programs and the hardware configurations while the hardware is changing.

Figure 1. The basic concept for a FPGA-based reconfigurable computer allows the appropriate configurations and resources to be connected to the processor as required.

Another possible example would be an FPGA and FPID combination as a digital signal processing engine for fast Fourier transform (FFT) processing. An FFT uses a sequence of many complex number operations to perform signal processing functions. One implementation of the FFT sequence uses an intricate process to get the various coefficients into the proper order, called bit-reversed order. This requires a re-sequencing of the address bits. An FPID can perform the bit flipping in a few clock cycles, and the associated FPGA can be set up to perform the multiplication and at the same time process and hold the coefficients for the complex subtotals. This combination of devices could perform the calculations in a small fraction of the time of even the fastest DSPs. In fact, many of the reconfigurable, albeit very specialized, computing platforms perform these types of coprocessing functions in the giga-op ranges.

Reconfigurable logic is widely used for ASIC emulation. After configuring one or more FPGAs to operate as the target ASIC(s), the engineers use the hardware to confirm functionality, yielding a software development platform that closely approximates the final system configuration. The PGA netlists are then combined and converted to an ASIC device to meet the final system size, speed, and power limits.

A great problem that can be encountered in the complex chain from the HDL to synthesis to the ASIC netlist and finally to the FPGA netlist for the ASIC emulator is any bit error. "This could be due to problems in one of the many conversions in formats and languages involved," points out Amr Mohson, CEO of Aptix (San Jose, CA). "This type of error is extremely difficult to locate and correct, and it has made emulators difficult to use and has been a barrier to greater acceptance of emulation."

Finally, an interesting reconfigurable computer might be a neural net evaluation engine with the ability to modify the internal tap weights as a part of the learning process. This would be a true self-learning machine, since the internal tap weights will not be known once the machine is in operation for some time. This type of part would be very interesting to try to test, since only the initially loaded base structure would be known, and the operating configuration would be different.

Today reconfigurable logic allows the user to make changes in internal functions as required, with minimal down time. Hardwired systems require board or component changes, moving a jumper, changing a switch, or replacing a PROM or PAL. The in-circuit programmable devices allow for changes in functionality while the system is running. In telecommunications embedded systems, new protocols and interfaces come into existence during the operating life of a system. By implementing the interface logic with an FPGA, the system can operate with the additional functions through on-line upgrades and reconfiguration, thereby minimizing down time and the costs and complexities of multiple system configurations. This reduces the need for multiple daughter boards and the headaches of hardware revision control as the new interfaces and protocols are implemented.

Issues for implementing reconfigurable computing Despite limited use, reprogrammable logic has not gained widespread acceptance. The majority of applications use the logic in one configuration at a snapshot in time, then change the programming for the next block of functions. The research community is working on some of the issues, but the current state of the hardware is vastly outpacing the software. The logic design is viewed as a semistatic function block changed only when the designer determines that the logic is not working. The software tools develop a single logic implementation and discrete changes for that single version of hardware. These versions are developed and tested to bring that function to operation in the system.

According to Stan Kopec, director of marketing at Lattice Semiconductor (Hillsboro, OR), designers need to approach in-system programming with a different mindset. "In the past," he says, "hardware design worked with fairly static methodologies and technology. The hardware became a fixed entity at some point in the process. With in-circuit programming, the designer has a different character; he needs to think about the system-level functions and needs to understand the system functions during the logic functions' transition. The designer needs to know what happens to the rest of the system­and the interfaces to the rest of the system­during the reprogramming and configuration cycles."

Many issues still confront the designer despite the great potential for higher-level functions within a reprogrammable part. One issue is the size of the available devices. Many FPGAs until now were just too small to hold a whole ASIC, or the complete algorithm for some function. This problem is addressed by the latest devices with high gate counts, good routability, and many other function-enhancing features. The larger devices allow more functions to be loaded and can reduce the need for the fast and frequent changes to the programmed logic.

"The smaller systems are good for signal processing and image processing," says Steve Guccionne at the University of Texas at Austin. "But a dedicated board may be a better value if this is the only function to be performed. Very large systems may be easier to program with a high-level language, and indeed may require a high-level language to function. The main issue is the need for large data sets to keep the data pipeline full. How can you manage the data and still have the time to reconfigure the logic?"

In addition, the current state of partitioning algorithms cannot facilitate the desire for larger FPGA devices. Some ASIC emulators use less than 20 percent of the total available gates. This is at least partially a result of channel congestion and the available routing resources constraints, as well as total FPGA partioning and utilization. This low utilization causes lower processing speeds, an increase in the number of FPGAs required to emulate the ASIC, and increased board area for the additional devices that exacerbates the speed problems. In addition, the multiple low density FPGAs create additional problems in partitioning and interconnect complexity. Many FPGA resources need to be committed to the I/O functions to perform inter-chip communication in these large array emulators.

Figure 2. The temporally displaced processes allow new configurations to be loaded between processing periods.

"The limiting item will be the ability to route the devices," says Joel Rosenberg, marketing manager for programmable logic at Atmel (San Jose, CA). "The next generations of FPGAs will require different capabilities and structures to make routability, connectivity, and utilization at acceptable levels."

After routing and interconnect complexity, the time to down-load a new internal configuration is the next bottleneck. This time is constrained by the serial download process from an EPROM and/or processor and is measured in ms to seconds. Many of today's applications do not need to reduce the reprogramming time, since they are intended to be distinct time functions where the FPGA is programmed in non-overlapping schedules. Saving registers, system status, and other functional data while changing the internal configuration, is a necessary step towards highly dynamic reconfigurable computing, but is not necessary for time displaced operations.

This is similar to the problems with controlling virtual memory. "The descriptions and locations of the various partitions and overlays need careful control in order not to lose the data," says Jeff Hutchings, director of engineering at Metalithic Systems (Sandy, UT).

"Until now, we have always thought of the hardware as a given, fixed parameter of a computer," says Christian Iseli at the Swiss Federal Institute of Technology (Lausanne, Switzerland). "With the advent of FPGA chips, however, it is our belief that this concept will change. We think that computers of the future will have configurable hardware that will be dynamically adapted to the application they run. That is why we think that some kind of hardware description language will be needed as part of the software development environment of the future. In fact, to allow for a smooth transition from the current software development environment to the next, it would be best if those hardware description languages resembled, as much as possible, current high-level languages."

Tets Maniwa is Integrated System Design's technical editor .

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

integrated system design  July 1995