Meeting Embedded Needs With Java

Software Java Solutions Run Everywhere Any processor with a couple of megabits of RAM can handle Java applications. Only a Java virtual machine (JVM) is necessary. All JVMs are not created equal, but that's the beauty of a software approach. For more speed, check out native code operation. It's even possible to mix and match Java bytecode and native-code application execution in the same JVM (Fig. 1).

Software Approach
+ Works on most hardware
+ One JVM can be replaced by another
+ JVM features tradeoffs versus memory requirements

−Native code is larger than bytecode
− Usually lower performance than hardware implementations

Key to a software approach is flexibility. A variety of alternatives are available for different processors, operating systems (OSs), and development environments. Java applications can be easily added to existing systems using the software approach, as long as sufficient memory is available.

Sun Microsystems has done a great job of partitioning embedded Java with its Java 2 Micro Edition (J2ME). Its JVM specifications are from the Java Community Process (JCP), allowing other companies to create compatible JVMs (see "Embedded in Electronic Design, Java 2," Dec. 3, 2001, p. 70).

For example, IBM's J9 is compatible with Sun's JVMs. J9 incorporates advanced features like just-in-time (JIT) and ahead-of-time (AOT) compilers. J9 works with IBM's Visual Age Micro Edition (VAME).

Third-party, cleanroom JVM implementations like Hewlett-Packard's (HP's) Chai appliance platform give developers a licensing alternative to Sun. As with most JVM products, Chai includes a host of options, such as the chaifarer XML Web browser and chaiawt graphical front end. Platform-specific versions exist, like ChaiVM for the HP Jornada handheld PC.

Some JVM vendors concentrate on specific Java environments, instead of addressing the full range like Sun and IBM. For example, the Jeode from Insignia Solutions targets the personal and embedded Java spaces. Aplix JBlend refines this further, targeting the mobile device space.

All Java environments need to contend with Java-specific features, such as garbage collection. The software approach lets NewMonics easily add a generational, real-time garbage collector to its Perc JVM (see "Real-Time Garbage Collection Speeds Embedded Java," p. 60).

A number of OS companies license or support third-party JVMs. Others have their own JVM, like Wind River's JWorks. The advantage of this approach is tighter integration with the underlying OS and development tools.

Esmertec's Jbed real-time operating system (RTOS) eliminates the need for a third-party RTOS. It provides a pure-Java environment that's comparable to hardware implementations, with the flexibility of using a supported conventional processor like the ARM, PowerPC, or Coldfire.

Hiding Java
Sometimes embedded Java can be so hidden, developers must dig for it. Transvirtual's XOE is a platform for XML-based development. It's built on Transvirtual's PocketLinux and JVM's Kaffe, which are almost hidden by XOE from a JVM standpoint. Espial has a range of Java platforms, like its device-top environment targeted at smart Internet devices. It adds value by providing a variety of applications and environments, like the Espresso GUI toolkit and the Escape browser.

Regardless of the JVM selected, running Java applications via software can keep costs down compared to additional Java hardware. JIT and AOT code performance might be enough to banish specialized hardware from a project.

Hardware Approach
+ High performance
+ Runs Java bytecodes directly
+ Transparent Java execution

− Hardware specific
− May have instruction or environment limitations
− Some JVM functionality may still be in software

Java hardware can deliver better performance than even JIT or AOT native-code execution by providing Java-specific support. This includes range checking and method invocation that may require multiple native-code instructions.

The major hurdle is choosing a hardware solution that works with the system being designed. A system-on-a-chip (SoC) solution built around a standard processor requires a compatible Java core design. Often there's only one or two alternatives, versus many for a software solution. Off-the-shelf solutions also exist for both Java-only and Java acceleration.

Nazomi Communications' JA108 is a unique solution for adding Java acceleration. It can be tacked on to existing systems where memory can be added because memory can be incorporated into the JA108 (Fig. 2). The standard chip sits between the processor and memory. Essentially, it's transparent until Java code needs to be executed.

Java code is placed in a memory range. The switch from native-code execution to Java bytecode execution is transparent to the native processor. It's a very elegant and inexpensive solution for only $5.59. The JA108 is based on Nazomi's JStar technology, which can be added to almost any processor core.

Ajile Systems' Aj-100 and Aj-80 processors provide a pure-Java execution environment. These Java processors are based on Ajile's JEMcore, which can be used with SoC designs.

Parallax's Javelin puts an interesting twist on a microcontroller that runs a limited version of Java. With no garbage collection or other fancy Java features, Javelin is still great for controller applications where low cost eliminates higher-end solutions. The Javelin has the same pinout as the Parallax Basic Stamp and supports limited multitasking through virtual peripherals like serial port support.

Java Cores
Standalone solutions rarely fit when existing applications or hardware must be used. But Java is so important that many add-on solutions are available. For example, ARM's Jazelle is a standard add-on to the ARM processor line, which translates Java bytecodes into native instructions. It's similar in operation to Nazomi's JStar.

InSilicon's JVXtreme takes the coprocessor route. It has all of the advantages of a dedicated Java processor, and it coexists with the host processor by sharing the memory bus. It requires minimal integration with the existing processor.

The remaining hardware solutions can operate as standalone Java processors designed to execute Java bytecodes directly. These include Ajile's JEMcore, Aurora VLSI's Espresso, Digital Communications Technology's Lightfoot, Vulcan Machines' Moon1 core, and Zucotto Wireless' XPRESSO core. Both Aurora VLSI's Espresso and Vulcan Machines' Moon1 core can also be implemented as a Java coprocessor supporting standard processors like ARM or MIPS.

Keep in mind too that using a hardware solution could be good for other reasons, including power reduction. Software solutions may have to run the host processor faster and hotter to deliver the desired performance. In the end, hardware may win out.