The latest of those will debut Monday (Jan. 29): JVXtreme Accelerator, an intellectual-property core from inSilicon Corp. that can be combined with a mainstream embedded CPU core to create a system-on-chip. But Docomo, which delayed the rollout of Java services for months to perfect its infrastructure, has yet to mandate Java acceleration on all handsets.

Companies this year will roll a range of software- and hardware-based solutions to increase Java performance in wireless applications. Players include intellectual property (IP) providers Nazomi Communications Inc. and Chicory Systems Inc.; Java native processor vendor Zucotto Wireless Inc.; and ARM Ltd., with its Jazelle technology. Many of those companies, along with Philips Semiconductors, are optimizing their Java accelerators for set-tops, primarily for the Multimedia Home Platform defined by Europe's Digital Video Broadcast initiatives.

System-on-chip companies' interest in Java is also growing. While there's no Java accelerator in its lineup yet, "we believe Java to be an essential part of our embedded platforms," said Bob Krysiak, group vice president at STMicroelectronics' Consumer and Micro Group.

First-generation Docomo Java phones designed by Matsushita and Fujitsu tapped pure software implementations of Java. But "many handset vendors are finding very quickly that their current solutions are not going to hold up for long," said Mark Sears, product manger at Zucotto Wireless (San Diego).

As the Multimedia Home Platform's interoperability testing kicks off in Europe, broadcasters and set-top vendors are getting the first feedback on how well various applications actually run on their systems, said Nick Thorn, group manager at Philips Semiconductors' Systems Laboratories (Southampton, United Kingdom). The company claims its Nexperia home entertainment engine offers "the fastest Java virtual machine."

Cell phone companies recognize the need to provide an "acceptable user experience without breaking the core communication platform," said Robert Nalesnik, vice president of marketing at inSilicon (San Jose, Calif.). And "application developers are definitely asking for a performance boost," said Jay Kamdar, chief operating officer of Nazomi Communications (Santa Clara, Calif.), formerly known as JEDI Technologies. "Service providers are very aware that the higher performance of Java is critical to the success of their services."

Shift to hardware

Many in the industry say software approaches, which execute Java byte code by using a Java virtual machine to interpret general Java platform instructions for a target CPU — will remain the dominant solution for handsets throughout 2001. But as Docomo cranks up its Java-based services, "there will be a domino effect" in the industry, skewing demand toward hardware acceleration solutions, predicted Kamdar.

Current software acceleration options include JVM optimization, with the use of a just-in-time compiler with dynamic adaptive compilation. Hardware-based solutions include ARM, with a newly added instruction set for Java byte code, and Zucotto's Java native processors. Other hardware options are Nazomi's Java coprocessors and inSilicon's IP cores.

But none of these solutions is yet designed into a Docomo handset. Indeed, the hardware environment in current handsets constrains the development of Java programs for wireless applications, sources said.

Yair Raz, Java architect at inSilicon, said Docomo is asking Java applet developers "to limit the size of their programs and use of multitasking." Docomo guidelines issued in November for i-Mode Java content also recommend that developers minimize multithreading.

That could limit compelling applications for i-Mode phones. "If they are allowed to do only one thread of execution at a time, for example, developers writing a fighting game for i-Mode phones cannot create multiple objects with different threads," said Joe Leung, a board member of Access Co., based in Japan.

Service providers can't afford customer dissatisfaction with the Java experience, noted Nazomi's Kamdar. "Once given up, it's hard to regain their confidence."

Thus the slate of accelerators headed toward the market.

JVXtreme, which inSilicon was slated to announce Monday, is supplied as a synthesizable core for system integration and can accelerate CPU performance for most Java applications up to 55 times at peak levels and 15 times in sustained modes over a software JVM, claimed Nalesnik.

JVXtreme eliminates the overhead of the software-based Java interpreter loop by implementing the instruction loop logic and thread-switching logic in hardware. Raz said the core executes "80 percent of the most commonly used Java byte codes in hardware." It needs no JIT compiler and thus results in "no startup latency and no increase in memory. Because there are no software components to JVXtreme, there is no additional code requirement either."

Drop-in solution

The company touts the approach's ease of integration with the embedded microprocessors now used in cell phones, handhelds and set-tops. The inSilicon core can interface with the processor either as a memory-mapped device on the CPU's high-speed bus or as a coprocessor on the CPU's coprocessor bus. "This is truly a straight drop-in solution on a system level, with no need to do any surgery inside a CPU," said Nalesnik.

Nazomi's Kamdar confirmed that "system OEMs are looking for a pin-for-pin compatible design for a Java-accelerated CPU. They want solutions requiring no major porting, reporting or modifications in the JVM, CPU and real-time operating systems they are already using in their systems." Calling Nazomi's JStar technology "an instruction path coprocessor," Kamdar said the core sits between a CPU core and an instruction memory.

Though inSilicon claims the JStar approach requires intrusive system integration, Kamdar said, "We do offer OEMs three flexible options." The core can sit between the cache and CPU, can be placed on a system bus or can reside on an instruction RAM interface. Nazomi is scheduled to finish a JStar port to the ARM7 and ARM9 families this quarter. Solutions are already available for MIPS.

ARM itself is introducing a set of extensions under its Jazelle technology that will let an ARM processor directly execute Java byte code alongside existing operating systems, middleware and application code. The technology boasts an 8x performance gain over software JVM. It requires no JIT and no code bloat. Its memory footprint is "12 kbytes plus the Java run-time environment," said David Cormie, product marketing manager at ARM.

Different versions of Jazelle-enabled ARM solutions are in the offing over the next few months. One ARM licensee hopes to tape out the first Jazelle-enabled ARM9, a standalone processor core designed for PDAs and cell phones, in about six weeks. In June, Cormie said, a different licensee expects to ship what would amount to a superset of the first Jazelle product, complete with memory system, for use in cell phones, PDAs, Internet appliances and set-tops.

Cormie said that ARM is also defining a Jazelle-enabled ARM10 CPU that's scheduled for completion before year-end. "Our goal is to take the technology into set-tops," he said.

Chicory Systems (Austin, Texas) also offers IP that adds a minimal number of gates to existing processor cores. Chief executive officer John Derrick said Chicory's approach is based on recognizing the instructions used in byte code processing and creating a set of compressed instructions that speed up overall performance.

Chicory plans to support ARM, MIPS and, in the future, the SH architecture from Hitachi and STMicroelectronics.

"Unlike Jazelle, our approach creates data streams with extremely high power efficiency. Jazelle is just dynamic code translation, but it does nothing for the processor power consumption. And the power consumption profile is as important as the peak performance of the processor," Derrick said.

Some competitors remain skeptical of Java native processors. The rub is that Java was never meant to handle system-level functions, Kamdar said.

Xpresso flavors

Zucotto will position its upcoming Xpresso Java native processor as a "companion processor" for running Java applications alongside a host processor that handles all core cell phone functions. Sears said his company plans third-quarter samples of three versions: Xpresso120, a native Java processor for cell phone applications; Xpresso110, a microcontroller version that runs Java applications and Bluetooth functions in wireless PDAs; and an Xpresso core available for licensing.

Two-chip architectures are becoming more common for many cell phone designs as DSPs are added to handle multimedia applications. But Zucotto doesn't believe that adding yet another processor, for Java, will tax handset vendors.

"We believe handset vendors want to do Java processing properly and efficiently in a native processor," Sears said. A companion chip also means more power, but "the second processor could help reduce the power consumption of an overall system by introducing multiple sleep-mode functions."

Xpresso lets Java applications run 20 times faster than with a software K Virtual Machine, Zucotto claims.

For set-top applications, where the constraints for memory and power consumption are not as severe, some companies are opting for software-based Java acceleration. Philips Semiconductors has licensed Insignia Solutions' Jeode technology to run Java on Nexperia- based set-tops. The technology comes with the Jeode Embedded Virtual Machine, an accelerated run-time engine said to optimize performance and responsiveness in a smaller memory footprint.

At a time when "this DTV industry is so fragmented and standards are constantly evolving, software acceleration is a more flexible and cheaper way to go," said William Ringer, senior marketing manager at Philips. Jeode's dynamic adaptive compilation lets Philips "run Java five to 10 times faster, on most applications, over interpreted solutions, while using roughly the same amount of memory," Ringer said.

STMicroelectronics is similarly leaning toward software-based Java acceleration. "Dedicated Java processors do not look like a sensible option," said Krysiak. "For us, most systems can reach very good performance through compilation techniques, and there are a few very good commercial solutions available."