Dynamically reconfigurable system design
Dynamic reconfiguration involves disconnecting and establishing physical links at the boundaries of reconfigurable modules at runtime. But it also means to control the logical connections of IP cores. This makes the NOC approach highly attractive for reconfiguration (see Figure 1). Besides fixed physical interfaces, it comes with stacked abstraction layers. Each layer may be substituted by another implementation.
A NOC allows for a unified communication methodology. Packet based communication facilitates message passing being a fundamental part of an object oriented approach. A shift from physical interconnection details to a high level abstraction of IP core communication is achieved. It must be stressed, that even if NOCs adapt concepts of Internet communication, they focus on throughput, low power consumption and small scale communication. Consequently, a full blown TCP/IP stack is not reasonable here.
Accelerators and Decelerators
Implementing a certain computing problem often aims at performance improvements. Thus, a hardware realization is called accelerator. Accelerators may come in multiple implementations supporting different levels of parallelism, power and area consumption. On the contrary, the software implementation of an IP core is called decelerator. It is required to emulate the hardware behavior when reconfigurable resources are exhausted or not existent at all. But they are also useful when improvements of an accelerator are not necessary at the moment.
Accelerators and decelerators of an IP core share the same functional interface. Speaking in object oriented terms, they understand the same methods or Messages.
Distributed Object system
Generalizing the idea of IP cores being remote objects, leads to distributed object systems, such as CORBA, DCOM and Java RMI. From the application point of view, all objects seem to be located on the local host. But objects are allowed to be on remote machines, concealed by client proxies. Objects can be allocated and deallocated at will. Objects can be shared and can migrate between the client and remote hosts. A lookup or directory service assists locating objects within the network. But what does that mean if applied to dynamically reconfigurable systems?
If an application wants to use an IP core, it simply creates an instance of it. The proxy and, if enough resources are available on the FPGA, the accelerator are loaded. The decelerator equals to an object on the local machine. As shown in the following example, communication with the core is simply done by method calls. The NoC is hidden by the proxy and the skeleton. If the application does not want to use the core anymore, it just destroys the instance and reconfigurable resources are freed.
// Load an IP core, Decelerator or// Accelerator; InitializationmyCore = myCore::createInstance();
// Do something with it
// Remote method invocation
myCore->doSomething();
// Unload the IP core
// Free reconfigurable resources
myCore->releaseInstance();
Obviously, a dynamically reconfigurable system may be understood as a distributed object system in the small. Even if this analogy does not simplify dynamic reconfiguration, it definitely aids developing future concepts and architectures.
..: Download the linked paper for a detailed project description :..