XUP

FPGA Technologies

Recent FPGA have grown to replace ASICs in most low volume situations. While working at Raytheon, all of the embedded systems I worked on contained FPGAs as a central portion of there design. FPGAs have a faster development time, lower cost, and are more flexible in the field. Only in certain limited circumstances does it make sense to develop ASICs: high volume and very high performance. An emerging technology of FPGAs is called dynamic partial reconfiguration. Dynamic partial reconfiguration is a technology that allows FPGAs to be reprogrammed while running.

Reconfigurable System Design

To software engineers I like to use the example of memory when explaining partial reconfiguration. Memory is divided into two basic sections the read-only portion ROM, and the dynamic portion RAM. While self-modifying code is used in some instances, it is almost always discourged due the added complexity and potential for error. Taking this paradigm into hardware is a natural adaptation. In a reconfigurable computer there should be static portions and dynamic portions. The static portions hold what is needed to operate the software platform (RAM, PROC, Basic IO.) and the dynamic portion holds specially optimized hardware capable of accelerating the throughput of the system.

Dynamic Partial Reconfiguration

I'm doing research in dynamic partial reconfiguration and reconfigurable computing in general in order to better utilize these features. The goal of this is to be able to have an always up cluster that can have dynamic portions loaded over the Internet in order to make certain parts of a program much faster or bring in outside data IE: video. Further improvements could be made by integrating Impulse C or System C HDL's. The design relies on the development of a wrapper driver that can be used to

Possible Issues I Need to Address

Possible Ways to Address these Issues

The programing model is a tricky issue. We want to make it simple for users to put HDL into their programs. Possible ways include enhancements to gcc that allows inline HDL, System C or Impulse C. Problems with this approach is how do you verify your HDL is valid, how can there be guarantees that external ports exist, and how do you make sure that any modifications are safe from an OS security perspective.

First of all we need a possible way to compile all HDL code that is included in other higher level languages and verify that the code can be inserted into the FPGA at the OS Level. There is a need to have logic in the dynamic reconfiguration kernel driver that guarantees that a bitstream can be loaded into the FPGA and that it cannot circumvent the security of the system. Furthermore there needs to be guarantees that the bitstream will not open security holes to other parts of this system or cause a system malfunction.

The following pieces of the stack will need significant work.