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 disparateprocessors must interoperate with one another, which presents severalchallenges.
In larger development projects, DSP programming groups often operatein a separate silo from the GPP and FPGA programmers. This is a problembecause the groups must coordinate their efforts in order to design anoptimal 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 canresult in substantial code re-writes for each programming group,greatly slowing time-to-market.
These challenges, important as they are, are not unique to DSPsystems. Many other industries must integrate disparate platforms intoa single system. To meet this goal, these industries rely on adistributed communication architecture known as the Common ObjectRequest Broker Architecture (CORBA). Thanks to recentdevelopments,programmers can now take advantage of this technology in real-timesignal-processing systems.
What is CORBA?
CORBA is an open,vendor-neutral standard created by the Object Management Group (OMG ) consortium. CORBA enablespieces of programs, called objects, to communicate with one anotherover networks—regardless of what programming language they are writtenin, what operating system they are running on, or where they arelocated in the system.
CORBA is often described as a “software bus” because it is asoftware-based communications interface through which objects arelocated and accessed. The basic idea behind CORBA is the concept oflocation transparency: It makes no difference whether an object iscalled within the same processor or on a remote processor. This conceptis illustrated in Figure 1 .
1. Location Transparency
CORBA uses a client-server model to manage communications betweenobjects. The client/server interfaces are defined using the InterfaceDefinition Language (IDL). TheIDL is language-neutral and platform-independent: IDL definitions canbe mapped into any popular programming language, such as C or Java.This allows objects to communicate regardless of the language andplatform underlying the objects.
Data communication from client to server is accomplished through awell-defined object-oriented interface. The Object Request Broker (ORB) determines the location ofthetarget object, sends a request to that object, and returns any responseback to the caller. Through this object-oriented technology, developerscan take advantage of features such as inheritance, encapsulation,polymorphism, and runtime dynamic binding. These features allowapplications to be changed, modified and re-used with minimal changesto the original object. The illustration below identifies how a clientsends 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 andstraightforward. Objects package both data (called properties) and theprocedures (called methods) that operate on that data. As a result,these packages become convenient units of processing for the purposesof distribution and reuse. Object Oriented Design encourages thedefinition of objects based on the application problem, e.g., “powerspectrum” rather than solution .An object-oriented approach is ideal for homogenous, multi-processorsystems, as it allows developers to focus on the desired functionalityrather than the details of the underlying hardware.
Real-time CORBA adds deterministic behavior—its primary goal isachieving end-to-end predictability in a distributed system.Predictability is relatively easy to achieve on a single-processorsystem through use of priority-base scheduling. Predictability isharder to achieve in a multiprocessor, networked system because theprocessors do not share information about the priorities of theirtasks. Real-time Object Request Brokers (ORBs) solve this problem bypropagating the priority information. The result is distributedpriority inheritance and the ability to schedule distributed processesto achieve predictability.
The heterogeneous nature of CORBA is important in prioritypropagation. Consider the fact that every Real-Time Operating System(RTOS) has its own range of priorities. In one RTOS, the priority rangemay be 0 to 255, where 255 is the highest precedence. Another RTOS mayhave a range from 0 to 63, where 0 is the highest precedence. Manuallycoordinating priorities across different operating systems ischallenging because your code has to know which operating systemsyou're using. The Real-time CORBA standard simplifies matters bydefining a universal priority range—just one way CORBA provides aportable and transparent approach to building distributed systems.
Real-Time CORBA introduces a range of Real-Time CORBA Priorities.Real-Time CORBA Priority maps into native operating system prioritythroughout the system in a consistent manner, and specifies how toreconcile communication requests from the client application, throughthe middleware layer, over the network, and up to the serverapplication without unexpected priority inversions. When a clientinvokes an operation to a server, the client's native operating systempriority is mapped to a Real-Time CORBA Priority, which is carried aspart of the message to the server. The following illustration shows thereal-time priority mapping function of the client/server application,through a CORBA implementation.
(Click to enlarge)
3. End-to-End Predictability for the Activity
When the Server receives a message, the server-side ORB maps thepriority to the server's operating system native priority level, andinvokes the operation on the server at the same relative priority levelas the client. The result is distributed priority inheritance,providing end-to-end predictability in the same manner that would beexpected for an operation in a single process.
Priority propagation ensures that the RTOSes can be scheduledconsistent with overall priority. However, the network can still be asource of priority inversions. A high-priority message may have toawait the completion of a large low-priority message. That represents amessage-based priority inversion. To avoid this bottleneck, Real-timeCORBA supports Priority-Banded Connections. Priority banded connectionsallow the software developer to separate different types of traffic bypriority, and to dedicate separate connections between the client andserver for each priority “band”, where a band can encompass any set ofCORBA Priority levels. This allows greater predictability for traffic,and allows for a mix of real-time and non real-time data on thecommunications transport. Priority banding also helps to bound andminimize the chances for any priority inversions.
What is CORBA/e?
For systems that need small memory footprint and deterministicexecution, DSP programmers can use the latest generation of CORBA:CORBA/e (CORBA for embedded). An Object Management Group (OMG)standard, CORBA/e provides an architecture for distributed processingthat fits systems from the largest server farms to the smallestnetworked DSPs.
The CORBA/e Compact Profile fits easily on a typical 32-bitmicroprocessor running a standard Real-Time Operating System (RTOS).The CORBA/e Micro Profile is even smaller and fits on the kind oflow-powered microprocessor or DSP found on mobile or hand-heldequipment. As with standard CORBA, CORBA/e provides the benefit of codereuse. Developers do not need to re-write code for all systems on anetwork when they want to make changes, thus preserving theirinvestment in existing applications.
Why CORBA/e for DSPs?
CORBA/e enables DSPs to become first-class devices in mixed systems.This means that the portability of the CORBA interface provided to DSPslets DSP developers and the system architect optimize functionality inthe DSP with the same ease they now have in the GPP. CORBA/e is ideallysuited to the challenges of today's mission-critical environments:
Standalone systems are a thing of thepast. DSPs need to communicate and interoperate with GPPs, FPGAsand other DSPs. The systems in which they operate are networked andhighly interconnected. Software must cope with communications andinteroperability issues, while delivering the same reliability andperformance as the isolated embedded systems of the past. Even systemsthat appear to be standalone often need a communications infrastructureto merely report their status to a central control system. CORBA/emakes this interoperation manageable. What's more, it provides easyaccess to a variety of sophisticated transports tuned to embeddedtargets including Shared Memory, PCI, PCI Express, Rapid IO, Firewire,and Ethernet. CORBA/e also allows DSP programmers to “plug-in” theirown custom transports.
Platform flexibility is essential. It was once acceptable to target embedded software to a specificprocessor on a particular board. Today, there is increased pressure topreserve investment through development of reusable code that can beused with different targets. DSP programmers may need to target manydifferent processors at the same time, and they may need or migrate tonew compilers, operating systems and processors over time. Without anappropriate infrastructure, these requirements make a projectsusceptible to repeated code changes. CORBA/e insulates DSP developersfrom the headaches of rewriting code with every processor and systemchange.
Multicore Processors. Embeddedsystems increasingly usemulticore DSP processors. Developers currently writing code forsingle-core systems will need to migrate their applications from singlecore processors to processors containing two or more DSP cores. CORBA/eenables a seamless migration to multiple cores through the benefits oflocation transparency.
Embedded systems interact with thereal world in real-time. Devices with DSPs require interactionsthat are predictable in time as well as in function. CORBA/e providesdistributed predictability by recognizing and propagating priority inits own processing and across the system.
Power, weight, size and speed areconstrained. CORBA/e is specifically designed to supportboard-based and networked systems with the smallest footprint and thehighest performance requirements.
Reliability must be built-in . DSP programmers are rightly skeptical about adopting code they don'twrite themselves. Robust implementations of CORBA/e like ORBexpress RT and ORBexpressDSP have been field-tested in the toughest environments, provingtheir reliability time and time again.
Application flexibility throughrefactoring. DSP programmers and their GPP programmer counterpartscan build a CORBA/e application as if it were a standalone application.They can then distribute the application across multiple resources withminimal effort. The programmers can also change the distribution of theapplication with ease, making it possible to defer deployment decisionsuntil late in the design process. Deferring deployment decisionsenables optimized resource allocation and the flexibility to adjust tochanging conditions. Most importantly, it allows DSP programmers toeasily move unnecessary algorithms off of a DSP to a GPP or FPGA inorder to ensure that the DSP performs only those tasks for which it isoptimized.
Time to market is critical. Economic pressures are requiring greater productivity from systemsdevelopment. By supplying a high-performance communications framework,CORBA/e enables greater productivity because it is no longer necessaryfor DSP programmers to write their own communications protocols and tore-write those communications protocols every time there is a change insoftware or hardware architecture. By providing a reliable, flexiblearchitecture, CORBA/e eliminates one of the most tedious andtime-consuming parts of distributed application development. Thisensures that a system architect can move algorithms among a DSP and aGPP to achieve greater total system efficiency without incurring anysignificant code or communications protocol rewriting—even if thesemoves come very late in the development process.
Embedded systems are called upon to interoperate in many ways: Anautomobile, a circuit-board assembly unit, or even a sophisticatedoffice copy machine may contain multiple embedded DSPs and GPPs,connected by a network. In an assembly plant or chemical refinery,process controllers may interoperate with many small sensor units, andone or a few large servers or mainframes.
When embedded in automobiles, airplanes, weapons systems, hand-heldradios and cellular telephones, and other devices, software must workas reliably as the hardware. This is challenging because the typicalembedded DSP environment is networked, forcing its software to dealwith communications and interoperability issues without compromisingreliability and performance.
The interoperability and dependability of networked embeddedapplications can only come from a proven, standard middleware. The newavailability of CORBA/e-based ORBs for DSPs is exactly what is neededfor these applications.
CORBA/e offers an architectural solution for DSP programmers andembedded system architects to keep up with the rapid pace oftechnological change in processors, models, and particularlycommunications bus types. CORBA/e lets developers protect theirinvestment in development work despite rapidly accelerating change.
The benefits of CORBA/e for DSPs may be summed up this way:
- A proven, high-performance architecture used in the mostdemanding environments.
- DSPs become first-class devices in system processing.
- High-performance and speed within a small footprint.
- Reduced risk—changes can be made late in the software developmentprocess without rewriting code, while preserving existing investmentsin application development.
Joseph M. Jacob is a senior vicepresident withObjective Interface Systems