|
Signal processing systems often include multiple types of processors, such as Digital Signal Processors (DSPs), General Purpose Processors (GPPs), and Field Programmable Gate Arrays (FPGAs). These disparate processors must interoperate with one another, which presents several challenges.
In larger development projects, DSP programming groups often operate in a separate silo from the GPP and FPGA programmers. This is a problem because the groups must coordinate their efforts in order to design an optimal system architecture and to allocate functionality optimally. This coordination can be time-consuming and challenging. What's more, any changes to the system architecture or functional allocation can result in substantial code re-writes for each programming group, greatly slowing time-to-market.
These challenges, important as they are, are not unique to DSP systems. Many other industries must integrate disparate platforms into a single system. To meet this goal, these industries rely on a distributed communication architecture known as the Common Object Request Broker Architecture (CORBA). Thanks to recent developments, programmers can now take advantage of this technology in real-time signal-processing systems.
What is CORBA?
CORBA is an open, vendor-neutral standard created by the Object Management Group (OMG) consortium. CORBA enables pieces of programs, called objects, to communicate with one another over networks—regardless of what programming language they are written in, what operating system they are running on, or where they are located in the system.
CORBA is often described as a "software bus" because it is a software-based communications interface through which objects are located and accessed. The basic idea behind CORBA is the concept of location transparency: It makes no difference whether an object is called within the same processor or on a remote processor. This concept is illustrated in Figure 1.
1. Location Transparency
CORBA uses a client-server model to manage communications between objects. The client/server interfaces are defined using the Interface Definition Language (IDL). The IDL is language-neutral and platform-independent: IDL definitions can be mapped into any popular programming language, such as C or Java. This allows objects to communicate regardless of the language and platform underlying the objects.
Data communication from client to server is accomplished through a well-defined object-oriented interface. The Object Request Broker (ORB) determines the location of the target object, sends a request to that object, and returns any response back to the caller. Through this object-oriented technology, developers can take advantage of features such as inheritance, encapsulation, polymorphism, and runtime dynamic binding. These features allow applications to be changed, modified and re-used with minimal changes to the original object. The illustration below identifies how a client sends a request to a server through the ORB:
2. Illustration of client sending a request to a server.
There is much mystique in the software development community around "object-oriented development." But the reality is much more mundane and straightforward. Objects package both data (called properties) and the procedures (called methods) that operate on that data. As a result, these packages become convenient units of processing for the purposes of distribution and reuse. Object Oriented Design encourages the definition of objects based on the application problem, e.g., "power spectrum" rather than solution, e.g., DFT. An object-oriented approach is ideal for homogenous, multi-processor systems, as it allows developers to focus on the desired functionality rather than the details of the underlying hardware.
|
