CORBA for FPGAs: Tying together GPPS, DSPs, and FPGAs
| By |
|
Alternatives to custom bridges |
||
|
As signal processing systems become larger and more complex, system builders are running into a performance wall. In order to achieve the desired performance requirements of these extensive systems, modern signal processing systems often combine Digital Signal Processors (DSPs), General Purpose Processors (GPPs) and Field Programmable Gate Arrays (FPGAs).
To facilitate development of such multi-processor systems, designers can now use a distributed communications architecture: the Common Object Request Broker Architecture (CORBA). CORBA enables pieces of programs, called objects, to communicate with one another over networks—regardless of the programming language in which they are written, the operating system on which they are running, or their location in the system. This approach provides a number of advantages to system developers: Object request broker (ORB)-enabled GPPs, DSPs, and FPGAs offer a common communications paradigm among disparate engineering disciplines, important in environments in which these development groups often work in isolation.
Additional technical advantages of using ORBs across processor architectures include increased portability of algorithms and logic throughout systems, as well as an improved ability to migrate functionality from GPPs to FPGAs without structurally modifying applications. Perhaps most importantly, ORB-enabled devices give the freedom to do away with specialized interfaces for DSPs and FPGAs—allowing system architects to focus on improving application functionality while the ORBs deliver the necessary interface details for GPP, DSP and FPGA developers.
Features of ORB-enabled GPPs, DSPs, and FPGAs
- Offer common communications paradigm among “siloed” engineering groups
- Increase portability of algorithms and logic throughout the system
- Migrate functionality from GPP to FPGA at any time
- Keep the focus on application functionality by freeing developers from specialized interfaces for DSPs and FPGAs
Benefits of CORBA for FPGAs FPGAs are often used for large-scale development projects such as wireless base stations and software defined radios (SDRs)—applications typically calling for multiprocessor communications. Historically, however, FPGAs have not been supported by CORBA, requiring FPGA developers to hand-code hardware communications interfaces, an extremely time-consuming process both for the initial implementation and for changes as the design progresses.
| “Placing the ORB directly into FPGA hardware eliminates the need for a host GPP to provide CORBA-bridging services.” |
Location transparency and processing mobility Placing the ORB directly into FPGA hardware eliminates the need for a host GPP to provide CORBA-bridging services and brings the FPGA into the CORBA world as a peer to other processing devices. With custom communication services replaced by standard CORBA operations, system architects and programmers gain a single, consistent view of all system resources.
|
|
|
Figure 1 (click graphic to zoom by 1.9x) |
The most significant benefit gained by this consistent view is enabling CORBA location transparency across an entire heterogeneous system. The top-level view of a CORBA application can remain unchanged as objects are migrated among computational resources. For example, an application under development can initially implement and test all operations in standard GPP resources, providing early validation of the architecture and implementation. As the FPGA elements of the design mature, operations can easily be transparently migrated into the FPGA and validated against the existing GPP implementation.
What is CORBA? |
Support for ideal data types Eliminating the GPP bridge also removes a performance bottleneck and allows the FPGA to operate at full hardware data rates. For example, ORBexpress FPGA processes and delivers a CORBA message in a fraction of a microsecond. The message processing path is in effect fully pipelined, allowing the ORB to maintain high sustained transport bandwidth. Given sufficient I/O connectivity, tests demonstrate sustained processing rates of several million CORBA transactions per second.
This cross-device solution is ideal for environments that require high performance yet programming flexibility. SDRs, wireless base stations, medical devices, robotics and other types of high performance systems can benefit substantially from this cross-device flexibility.
Support for partial reconfiguration What puts the ORB at the state-of-the-art for component-based development is that it exploits the full potential of the partial reconfiguration feature of Xilinx Virtex FPGAs.
The term “reconfiguration” is used to describe an FPGA’s capability to be reprogrammable by loading a new bitstream from memory. Typically, the entire device needs to be reconfigured, which means that for a certain period of time (typically, milliseconds), the device is rendered inactive until the new bitstream is loaded. The term “partial reconfiguration” refers to the ability of an FPGA to reconfigure a portion of the device without affecting the operation of the rest of it. In this way, partial reconfiguration (PR) allows a designer to time multiplex the resources within an FPGA.
There are many use cases for partial reconfiguration, including:
- Supporting a multi-mode waveform in a smaller, lower-power and lower-cost FPGA by only loading the modes required at a given point in time, rather than having to load all modes even though only a couple may be in operation.
- Supporting multiple waveforms in a single FPGA, rather than having to use multiple FPGAs. In this scenario, a new waveform can be loaded into another portion of the device while maintaining an existing waveform.
- Achieving faster reconfiguration time by not having to reload the static infrastructure (such as interfaces) during reconfiguration.
- Maintaining the embedded processor such that it can continue to act as a controller even if the rest of the FPGA is not required at a given moment in time.
In the first couple of use cases, the primary benefit to the end user is having a smaller, lower-power and lower-cost platform which provides the same functionality. In the latter couple of use cases, the benefit to the end user is faster response time when a new application needs to be loaded. The ORB enables developers to more easily implement and take advantage of such partial reconfiguration through a standards-based, easy-to-use communications framework for re-loading the reconfigurable portion of the FPGA.
