Feature Archives | Feedback

A Solution in Search of a Problem

By Arnie Berger, PhD
Director of R&D, Applied Microsystems Corporation

Several years ago, I was involved in one of the most enjoyable projects of my professional career. I was the system designer and co-Project Manager for the development of a hardware emulation device called Teramac. Teramac was capable of emulating over 1 million logic gates at 1 MHz. The name came from "Tera" (10exp12 gate operations per second) Multiple Architecture Computer. The machine had 1728 custom-designed Field Programmable Gate Array chips (FPGA's) interconnected in such a way that a logic gate in any arbitrary FPGA could connect to a logic gate in any other FPGA.

The project was canceled before the full-size system became operational. However, something really struck me about this technology. It came from a comment made by another engineer/scientist on the project. He said that even though Teramac only ran at 1 MHz, it could be configured to solve certain classes of problems thousands of times faster than general-purpose supercomputers, running at much higher clock speeds. The example he gave is DNA string matching, such as those being done at the Human Genome Project. A specially configured, algorithmic processor designed for string matching, could outperform a CRAY Supercomputer at this particular task.

So, what does this have to do with anything? Well, we know that the use of FPGA's in embedded systems has been growing steadily. Most designers use them as substitutes for ASICs, because the economics don't justify the investment in a hard-wired silicon device, or as a prototyping substitute for the eventual ASIC. However, wouldn't it be interesting ( to say the least ) if we could harness some of the FPGA horsepower just waiting to be tapped.

The research community has been following a separate track, exploring the uses and architectural possibilities of large arrays of FPGA's (e.g., Teramac) which could be reconfigured as needed to solve different classes of problems. I'm also aware of at least one commercially available measurement instrument that changes some of its internal logic based upon how the front panel buttons are pressed.

The notion that the hardware in an embedded system can be as flexible as its soft ware presents use with some extremely compelling opportunities. The challenge is finding the problems that having reconfigurable hardware could solve effectively. What does having this reconfigurable piece of silicon buy the embedded system designer? Is it worth paying about a 6X penalty in silicon floor space to have this non-dedicated, dynamically reconfigurable logic take up space that might be better utilized by a serial port? I think it is, and as we figure out just what these problems are, the use of the FPGA will increase even more.

One obvious example would be to examine an ASIC design for those functions which can only take place serially. This could be collecting a data stream, processing it, and then passing it along. These three functions could be handled by a single block of reconfigurable hardware, instead of having three dedicated function blocks that each will only do one single operation on the data stream. Another possibility would be to configure the FPGA block for rarely used tasks, such as field service.

Motorola recently announced an FPGA IP block for use with their ASIC-embedded M-Core processor. ASIC designers can reconfigure a portion of the hardware of their ASIC as fast as the processor could reload a memory image. In my opinion this is an extremely significant technology step forward.

Perhaps the most intriguing application of the technology goes back to my Teramac conversations. Suppose we look at our ASIC device as an algorithm. Its function is to solve a specific problem, such as completely controlling the operation of a color ink-jet printer. The designers partition the algorithm into a hardware component (the ASIC and the IP) and a software component (the embedded firmware). Since ASICs are designed by compiling a software language, Verilog or VHDL, and our embedded firmware is also a compiled language that looks an awful lot like an HDL language, the partitioning decisions come down to where the program code will ultimately be executing. Now it gets interesting because it is only a matter of time before unified compilers will begin to emerge.

These unified compilers will be able to generate either the hardware description code ( in the form of the FPGA configuration file ) or the software code, depending upon the nature of the algorithm, and the constraints specified by the designer. The natural execution environment for such a compiler is a processor core and an FPGA array. The compiler specifies the object code for the processor and the configuration mapping for the FPGA. As a simple example, suppose that the user needs to execute a floating point function. Do you use your C++ library routine, or do you compile a numeric coprocessor into your FPGA?

Today, there are several companies that offer products that allow the designer to create a graphical state diagram of an algorithm and then do the partitioning into hardware (HDL) and software (C++). I will go out on a limb and assert that without too much incremental effort, the partitioning can be unified. Now the HDL-generated code compiles to the FPGA programming map. The end result is that the designer ( HW or SW, the distinctions are getting fuzzy ) ends up with a single code image description of the algorithm, partitioned into separately executable images. Don't like the performance trade-offs? No problem, just recompile with a different set of constraints. The possibilities are endless.

Click HERE to link to the full article.


		Click here to get your listing up.