Tools Matter In Mixed-Processor Software Development

Mixed-processor systems are growing more common as standard system-on-a-chip (SoC) architectures, like the Texas Instruments (TI) OMAP, become available. OMAP combines a conventional ARM processor with a TI DSP.

Unfortunately, programming a DSP is much different from developing software for most general-purpose embedded processors, such as Arm's ARM, MIPS Technologies' MIPS, and the IBM/Motorola PowerPC. Developing applications for a mixed environment becomes difficult for programmers familiar with one computing platform or the other.

It's very common, though, notes Marc Brown, Rational Software's developer tech marketing manager. Developers now implement DSPs from TI and Motorola with conventional CPUs in a variety of areas, including portable devices, automotive, and communications environments.

Joseph Dubin, TI's OMAP tools product marketing manager, indicates that customers are using the standard OMAP chips (see "Standardized CPU/DSP Devices," p. 80) to add communication support to existing DSP applications, or adding more sophisticated signal processing to an existing controller application. Of course, new applications are being developed to take advantage of both parts of the OMAP chip.

Regardless of the particular CPU or DSPs involved in a project, there are a number of ways to develop software for these platforms (see the table). The first employs conventional tools, such as integrated development environments (IDEs), compilers, and operating systems that most developers are familiar with. This often means that different tool chains, languages, and OSs will be used for the CPU side and DSP side. But some products, like OSE's namesake OS, span processor architectures.

An alternative is to use an integrated solution designed for a specific CPU/DSP combination. TI's Code Composer Studio (CCS) is a notable example. These integrated solutions can take advantage of features and quirks of a specific platform, but they tend to target a limited number of platforms. For instance, CCS doesn't work with Motorola's StarCore and DSP line of processors.

The last methodology uses modeling tools, which can be divided into two categories. MatLab from Mathworks dominates the first group, while the second bunch are Universal Modeling Language (UML) tools, like I-Logix's Rhapsody, Rational's Rose, and Telelogic's Tau. Modeling tools allow problems and solutions to be abstracted, making development more independent from the target platform. This also simplifies migration to other platforms.

Normally, the modeling tools are used in conjunction with conventional or integrated tools. UML tools are often employed with MatLab because MatLab is better at modeling programmatic algorithms.

Conventional Development Tools: Give designers a challenge and they will bring all their expertise to bear. This typically includes programming expertise in a language like C or C++, OSs, and development tools. When attacking a CPU/DSP system, the language (regularly C or C++) may be the same for the two processors, while the OS and development tools usually change. These additional systems could take a significant amount of time to learn, dragging out the project.

OSE Systems and Quadros Systems offer the same OS kernel on DSP and general CPUs. Quadros Systems' RTXC Quadros actually comes in multiple configurations. Therefore, a developer can choose the level of OS complexity and functionality with the same interprocess communication features. This lets a developer pick a single-stack implementation that might be suitable for the DSP and support multiple CPUs. RTXC supports the Motorola StarCore and DSP56xxx, ARM, PowerPC, and ColdFire processors. RTXC works with many third-party tools, like Motorola/Metroworks' CodeWarrior, Green Hills Software's Multi, and Altium's Tasking EDE.

OSE has special versions of its OSE real-time OS for CPUs and DSPs. The OSE Soft Kernel for DSPs is a full-OSE kernel, significantly easing migration of some applications from one processor to another. The OSE Link Handler for DSPs matches a similar link handler for general CPUs.

Links can traverse multiple CPUs and even networks, so OSE's solution is very powerful in large systems, such as telephone switches. But this type of application can be complex to debug, making OSE Illuminator for DSPs a handy diagnostic tool. It's a set of plug-ins for debugging and monitoring, containing extensive third-party support that works with other OSE Illuminator tools.

One problem with rolling your own system is that the developer must contend with CPU/DSP interaction. Debugging environments for the two processors may be different, and there may not be any interaction between debuggers supporting each processor. That complicates the tracking down of synchronization-oriented problems.

It's great to choose your own platform and tools. Still, trading choices for a more integrated approach has advantages.

Integrated IDEs: The integration that we're talking about here takes place between the development tools and the target platform. TI's OMAP products have a fixed target with an ARM CPU and TI DSP processors. This lets the company customize CCS to take advantage of the hardware in a way that's difficult when you design from scratch.

For example, Leland Szewerenko, senior technical staff member at TI, indicates that the CCS debugger can set up hardware breakpoints that will simultaneously halt both processors.

Having development software that is tightly integrated with the software has other advantages as well. The OMAP processors communicate via shared memory and some bridge hardware. CCS can monitor the information going across the bridge without stopping the processor. A less integrated approach might require instrumented code to capture and forward this information to the PC being used to debug the hardware.

Szewerenko indicates that developers take advantage of the OMAP architecture in three ways. One is ARM developers looking to add a DSP support. In this case, the DSP is often considered a black box. This works well with TI's XpressDSP architecture, which has numerous third-party algorithm plug-ins. Combined with TI's DSP/BIOS and CCS development environment, a developer can concentrate on programming the ARM processor.

Also, developers connect existing DSP applications to a network using the ARM as the communication processor. Although it's more difficult to black-box the ARM, it's a straightforward process to implement a standard OS or just a TCP/IP stack with a simple communication algorithm.

Finally, some developers take control of both sides. Modeling tools can be very useful here. They can also help those unfamiliar with DSPs, and with applications where the underlying hardware hasn't been chosen yet.

Modeling Matters: The Mathworks MatLab and Simulink tools have no peers, but they're complementary to integrated IDEs like CCS and UML tools. MatLab can generate code for compilation or use with other tools.

MatLab can be employed for a wide variety of applications, including support for conventional processors and DSPs. A major advantage of modeling tools is target platform independence. The model for the application can be developed and even tested without selecting a target. This makes the tool ideal when hardware isn't available yet or hasn't been finalized.

Modeling tools are good for rapid prototyping too. Portions of an application can be created and simulated without deciding whether an algorithm will be run on the CPU, DSP, or both.

MatLab is integrated with most third-party DSP development tools. Because it's excellent at implementing sequential algorithms that are more difficult to perform via UML, MatLab is often employed in conjunction with UML tools for DSP development.

The UML Connection: UML has tackled tough problems for years. It simulates everything from business processes to CPU/DSP environments. Major UML products like I-Logix's Rhapsody, Rational's Rose Realtime, and Telelogic's Tau take UML one step further by generating executable applications from UML specifications. This is what Bruce Powell Douglass, I-Logix's chief evangelist, calls "semantic depth." It allows applications to be tested as UML models, which can then be converted to C, C++, or Java code.

UML products can generate different code for different parts of the target hardware. This is significant because a DSP usually requires C or C++. But the bulk of an application that runs on the CPU may be running Java. There could even be device-specific features written in C or C++. Moving parts of an application from one language to another under UML is simply a matter of making a few choices. Converting source code by hand can take days or weeks.

The one caveat for DSP development with these tools is that DSP-specific frameworks aren't part of any of the products. Rather, UML models are targeted at a platform-independent model (PIM). Once a target is chosen, a platform-specific model (PSM) can be created. The tools then generate code based on the PIM-to-PSM translation.

Luckily, the time to generate the necessary PSM support is measured in weeks. Modify the hardware design, switch DSPs, or split a portion of an application across processors, and it's normally a matter of just regenerating code. Matthew Graney, director of tech marketing at Telelogic, says that this ability to partition a system in different ways has allowed developers to check out hardware designs prior to their implementation to see if they meet the application's needs.

UML may be overkill for very simple CPU/DSP applications, especially for platforms like TI's OMAP where DSP algorithms are purchased. However, UML provides significant benefits on even medium-size projects in such areas as testing and architecture management. UML product integration with development tools like CCS and MatLab make trying UML an easier choice because it works with tools that developers would have to use anyway.

UML lends itself to building and managing test cases as part of the development process. This should be done with any type of development process, but it's often lacking in conventional development environments because it can't be easily managed.

Rational's Quality Architect Realtime, part of the company's Rose Realtime product, formalizes model-oriented testing. Test Realtime works with the UML tools, bringing more conventional code analysis and testing procedures to the mix.

Choosing to go with a set of UML tools isn't a trivial issue. There are increased software and training costs, but the payoff in flexibility, application reliability, and testing typically make this a good tradeoff. Keep in mind that training is critical. UML techniques will seem foreign to most programmers and designers, yet training normally reveals the relationship to object-oriented experience that new UML users already have. Either pay for good training up front, or pay later in longer development times, as on-the-job learning is often much harder.

Mixed CPU/DSP development is becoming more mainstream. Development tools are trying to keep pace, but the hardware is still ahead of the software.

See associated figure.