Eclipse platform eases SoC development

Tensilica decided to address the complexity arising from intertwined software and hardware development by introducing a new development tool called Xtensa Xplorer. The company is targeting the tool for SoC modeling uses and software development with configurable processors.

One of the most imposing barriers to the creation of such a development tool has always been the mountains of work required to get even the most basic software development platform working. Microsoft Developer Studio has set a high standard and level of expectation with developers that impose tough requirements for visual software development tools. For a tool of this type to make the grade, it must provide syntax-aware editing, project and build management, file browsing, integrated source-code management (SCM) and a host of other features.

Given these requirements, the return-on-investment analysis of developing an integrated hardware/software solution compelled us to leverage an existing software platform into something better. The owners tightly hold most of the proprietary visual platforms for software development. After a detailed analysis of available open platforms, developers chose the Eclipse tool platform-described on the Eclipse.org Web site as "an open, extensible IDE [integrated development environment] for anything and nothing in particular"-as the base for Xplorer. Eclipse reduced the investment required to bring Xplorer to market by allowing Tensilica's development team to spend most of its time producing differentiated features for Xtensa Xplorer rather than producing yet another code outliner.

IBM developed Eclipse and placed it into the open-source community. Although Eclipse is the backbone of many enterprise-level development products, like IBM's WebSphere, the Eclipse platform itself is not enterprise-specific and can be adapted easily to other development tasks.

At its heart, Eclipse is a Java-class loading-and-binding microkernel. At a practical level, a special directory called the plug-in directory sits within each Eclipse installation. In this directory sit code packages called plug-ins. A plug-in has Java executable code and a special XML file that binds the Java code distributed in the plug-in to specific Eclipse functions. This XML file also advertises additional points where other plug-ins can extend the features provided by the new addition to Eclipse.

Let's consider a practical example demonstrating how the Eclipse microkernel shapes the tool development process. Xtensa Xplorer provides, among other things, a specific user interface configuration for performance viewing. Eclipse supports multiple named configurations of the user interface and calls these "perspectives." This new configuration, the benchmark perspective, has a special set of windows that display performance information in particular ways. Each of these windows is called a view and is bound to the Eclipse platform with a statement in Xplorer plug-in's XML file. The XML reference causes Eclipse to recognize and load the views specific to Xtensa Xplorer without recompilation of the base Eclipse package.

Moreover, the benchmark perspective is itself extensible. Because Xtensa processors are configurable, one of Xtensa Xplorer's project design goals was to allow developers to optimize performance in specific embedded applications through tool-driven exploration of many possible processor configurations. In practical terms, we wanted the user to be able to say, for example, "Ch eck this application's performance with all these different cache configurations." However, we did not wish to limit the search to cache configurations. We also wanted to permit user-directed exploration in other areas of the processor's configuration space, and we wanted the ability to add additional searches without having to release a new version of the Xplorer benchmark perspective.

The base Eclipse IDE framework advertises functions to which additional code can be bound. This ability to advertise these "extension points" is not only limited to the base Eclipse plug-ins but also is open to all installed plug-ins. To permit such multidimensional exploration of processor configurations, the benchmark perspective, which is bound to Eclipse via extension points, advertises its own extension points that allow additional plug-in code to direct the processor configuration search.

So the Eclipse microkernel binding features are not just a mechanism for the developer to execute code. They also ser ve as an encapsulation layer that encourages easy extension for new tool applications.

Eclipse-the IDE Platform

A solid run-time loading-and-binding mechanism seems to be a great start for a software platform, but there is much more to an IDE. While Eclipse is the basis for many Java-oriented development products, a sharp line separates Eclipse's IDE framework and Eclipse's Java development tools (JDTs). The Eclipse IDE platform provides interfaces, basic tools and action tasks associated with an IDE. The platform provides functions such as SCM integration, application launching, application debugging, source-code editing and browsing. However, a bare Eclipse platform is language-neutral.

Taken straight out of the box, a vanilla Eclipse is little better than an editor with a navigator. That's because the Eclipse environment relies on language-specific code, called tooling, to extend those basic functions with support for specific languages. Although our project team developed Xtensa X plorer using Eclipse and the JDT, Java development is not a focus for the Xtensa Xplorer tool because embedded software developers generally do not use Java to create code for processors incorporated into SoCs. Instead, Xtensa Xplorer focuses on C and C++ software development, the languages favored by embedded software developers chasing the SoC niche.

The C tooling that is shipped with Xtensa Xplorer is based on the CDT (C/C++ Development Tooling). CDT is newer than the rest of Eclipse. QNX and IBM Rationale donated most of the code and development effort to place the initial version of CDT into the open-source community under the Eclipse.org umbrella. CDT includes a C/C++-aware editor, integration with the GDB debugger, C-project navigation and basic integration with GNU-based binary tools. Xtensa Xplorer supports C/C++ and assembly language development and most of the underlying code for this portion of Xtensa Xplorer comes from the open-source CDT effort.

Building on this base, Xtensa Xpl orer leverages the Eclipse and CDT code to deliver the tools needed for building SoCs using custom processors. Xtensa Xplorer users can download configured and extended processors from the Xtensa Processor Generator and then create C projects based on those processors. They can run the resulting executable code under the Xplorer debugger and, once the application is working correctly, profile the code using a tailored instruction-set simulator to identify any performance issues. A key advantage to using configurable, extensible processors is that the designer can significantly boost application performance by adding specialized instructions to the processor that speed execution of inner code loops, so this profiling capability is a key component of Xtensa Xplorer.

Xtensa Xplorer adds to Eclipse and the CDT a benchmark perspective to display profiling information with the source code and the disassembled trace listing. Profiled code cycle counts and cache misses can be displayed alongside the C source and the addresses associated with cache-miss penalties. Given this insight into their code, developers can bring up the Tensilica Instruction Extension language editor to create custom processor instructions that accelerate the design's performance. They can then iterate, using the integrated debugger, to ensure correct operation of the new processor instructions, and then use the benchmark perspective again to view the new performance results as well as the flow of data through the processor's pipeline.

Once developers have optimized the processor cores used in the SoC, they can begin to construct the SoC at a system level. Xtensa Xplorer aids this construction by allowing developers to organize the system memory map in a tabular form. This map defines the logical connections between memories and processors in the system, including the physical-address ranges that each processor uses for each memory block.

Once the system is constructed using the memory map editor, Xplorer will automaticall y generate source code for a system-level simulation model of the multiple processor (MP) system. The source code generated uses Tensilica's system-modeling API, XTMP, and the code generated by Xplorer can be compiled unmodified to create a simulator of the system specified with the memory map editor. The resulting simulation code can be compiled with native code compilers to produce a working system-level simulator.

The developer may also use Xtensa Xplorer to build software for MP systems. Users specify what C applications are to be built for which processors in the system, and Xplorer will automatically build them. This greatly simplifies the creation of multiple executables. Once all the binaries are built, Xplorer allows the user to easily run and debug MP applications using either a simulator, real hardware or emulation hardware.

One would be hard-pressed to find an area further away from enterprise computing than SoC hardware/software codesign. Yet, Tensilica's experience with the Xten sa Xplorer development program provides firsthand evidence that Eclipse is an ideal base upon which to build development tools of almost any sort. Tensilica is not alone in discovering this in the embedded market. Operating system vendors QNX Software Systems Inc. and Timesys Corp. are already shipping embedded products based on Eclipse and RTOS industry heavyweight WindRiver joined the Eclipse consortium last May.

Christopher Songer is director of platform engineering at Tensilica Inc. (Santa Clara, Calif.).