Embedded Microprocessor Watch

Issue #167 -- 10/27/2003

Editor: Tom R. Halfhill  

In this issue:

Intel Enters Media-Processor Biz
Peter Glaskowsky - Editor-in-Chief  {10/27/2003}

What can you say when the world’s biggest semiconductor company enters your niche? Right now, media-processor vendors like Equator and Philips/TriMedia are probably telling their customers how happy they are that Intel has “validated” this market by introducing the MXP5400 and MXP5800, thereby proving these smaller chip companies were right all along. Companies previously validated in this way include Chromatic, Chips & Technologies, and ServerWorks.

The MXP architecture was codeveloped with Xerox, Intel’s first announced customer for these new chips. Xerox will use MXP chips to perform image enhancement, compression, and similar tasks in digital copiers, printers, scanners, and multifunction devices incorporating combinations of these features. Intel will also offer the new chips to other companies making document-imaging equipment, video-effects processors for the broadcasting industry, and any other type of product that needs high-performance 16-bit integer image processing.

The MXP5800 combines memory, PCI, and expansion interfaces with eight image signal processors (ISP) in a rectangular array. Each ISP is itself a multiprocessor, with five 266MHz programmable elements (PE) plus hardware function units. The MXP5400 is essentially the top half of the MXP5800 configuration, with four ISPs instead of eight and half as many DRAM and expansion interfaces. Each ISP is optimized for a specific function, as are the PEs within each ISP. This non-regular architecture complicates software development but allows a more efficient hardware implementation for image-processing tasks.

The MXP family may be just what Xerox needs, but we believe its limitations and idiosyncracies will make it difficult to sell to other potential buyers. Other media-processor vendors may be uncomfortable sharing the market with a company as big as Intel, but, for now, they probably won’t have to share many of their customers.

Microprocessor Report readers can access the full story here: www.mdronline.com/mpr/h/2003/1027/174302.html. To find out more about Microprocessor Report, please visit: www.mdronline.com.

MPF2003: Funeral or Celebration?
Peter Glaskowsky - Editor-in-Chief  {10/27/2003}

According to the keynote speakers at Microprocessor Forum 2003, microprocessor architecture, and the microprocessor itself, is dead—or, at least, no longer evolving. This would be very troubling news if it were true, but there’s no need to worry.

When Sun CTO Greg Papadopoulos said “microprocessors are dead,” he meant that discrete processors of the conventional type—one CPU per chip—are no longer the best solution for some high-end systems.

In saying that processor architectures have stopped evolving, AMD CTO Fred Weber was actually pointing out that instruction-set architecture (ISA) has become almost irrelevant to the costs and capabilities of modern microprocessors. In his view, there is no need for a new ISA, such as Intel’s IA-64; the PC and server markets should consolidate on the AMD64 ISA instead. AMD would naturally benefit from such an outcome, but Weber offered strong quantitative arguments for its happening.

As Weber pointed out, the influence of ISA on design effort, transistor count, clock speed, and power consumption in today’s PC processors is almost negligible. Weber left room for future work in application-specific instruction-set extensions, such as MMX, SSE, and 3DNow, but showed that the AMD64 ISA is a good foundation for future processor development. Microarchitecture, Weber said, is where the real action will be—and we agree.

It is not apparent to me that Intel has proved the need for IA-64—or that all of today’s server customers could ever be switched to Itanium processors. During lunch at MPF, I heard an anecdote from an engineer at a major OEM currently building Xeon servers for its proprietary online transaction-processing software. This engineer said his company had tested Itanium and rejected it, because the x86-specific optimizations in its software imposed terrible performance penalties on a simple IA-64 translation. Itanium gave the company one-fifth the performance at four times the cost. No doubt, this result could be substantially improved with some effort but, he asked, why bother?

It would be difficult for Intel to license AMD64—for political rather than technical or financial reasons. Intel could easily make the necessary changes to the Pentium 4 pipeline, and it’s reasonable to assume that Intel’s manufacturing and marketing strengths would preserve its market share. The trouble is that Intel originated the x86 architecture and was responsible for all major ISA improvements over the years. Intel even developed its own 64-bit extensions—the Yamhill technology we believe was designed into the forthcoming Prescott processor—although they may never see the light of day. AMD64, even under another name, would be a very bitter pill for Intel to swallow.

However the PC and server markets go, Weber was disregarding current trends in embedded processors, where ISA changes are essential to achieving the full potential of new concepts in parallel processing. It’s difficult to imagine AMD64’s being used by extreme-processor startups exploring heterogeneous multiprocessing and VLIW pipelines.

Similarly, I’m sure the computer industry will always have room for conventional chip-scale microprocessor cores, no matter what Sun does with Throughput Computing in server systems. Simple microprocessors, where the application-specific logic is best developed separately from the CPU core, will always be the preferred answer for some systems.

In embedded systems, PCs, workstations, and supercomputers, software that doesn’t lend itself to parallel processing will always be with us, creating permanent markets for the biggest, fastest cores possible. What we call a “microprocessor” will surely change in the coming years, but the microprocessor itself will outlive us all.

To find out more about Microprocessor Report, please visit: www.mdronline.com.

Motorola Enhances StarCore DSP
Tom R. Halfhill - Senior Editor  {10/20/2003}

Some of Motorola’s latest 3G mobile phones will use an enhanced StarCore DSP that the company revealed at Microprocessor Forum 2003. The new SC140e core has several advanced features not found in other StarCore DSPs, including a new memory subsystem and a user-level privilege mode. Motorola says the enhancements will eventually appear in a future architecture from StarCore LLC, a spinoff formed last year by Motorola, Infineon, and Agere (formerly Lucent).

Two related announcements accompanied Motorola’s introduction of the SC140e. A day earlier, StarCore LLC announced the first two licensable StarCore DSP cores, the SC1200 and the SC1400. Previously, only Agere and Motorola could design chips around StarCore DSP cores; now, anyone can license the synthesizable cores to design an SoC. The SC1200 and SC1400 are based on the same SC1000 architecture as Motorola’s SC140 and SC140e. Indeed, Motorola’s SC140 and StarCore’s SC1400 are essentially two different names for the same core, which was introduced in 1999.

On the second day of Microprocessor Forum, Motorola announced the Jupiter architecture, a “convergence platform” for wireless communicators that incorporate PDA functions. The foundation of the Jupiter architecture is an SC140e-based single-core modem chip and an ARM1136JF-S application processor.

Although Motorola’s new SC140e is a synthesizable DSP core like StarCore LLC’s SC1200 and SC1400, Motorola has no plans at this time to broadly license it as intellectual property (IP). Instead, Motorola will use the SC140e in its own chips—like the Jupiter-platform modem chip—and will design SC140e-based SoCs on demand for customers.

In about a year, the SC140e’s enhanced features will find their way into the next-generation StarCore DSP architecture, the SC2000, which StarCore LLC will make available as licensable IP. Until then, system designers who want the SC140e’s features will either have to hire Motorola to design an SoC to their specifications or buy the Jupiter modem chip. Motorola may introduce additional standard parts based on the SC140e as well.

Microprocessor Report readers can access the full story here: www.mdronline.com/mpr/h/2003/1020/174201.html. To find out more about Microprocessor Report, please visit: www.mdronline.com.

ARM Gets More Deeply Embedded
 {10/20/2003}

In recent years, ARM’s biggest challenge has been to expand its reach and grow its licensee base beyond the mobile phone. Its latest answer to this challenge is the ARM1156T2(F)-S, the details of which were announced for the first time at Microprocessor Forum 2003.

As a member of the ARM11 family, the ARM1156T2(F)-S carries with it many features of its ARM1136J(F)-S predecessor, but there are also many differences. The most obvious differences between the ARM1136J-S and ARM1156T2-S are evidenced by their names. The “J,” indicating Java support with Jazelle, is absent from the ARM1156. The other obvious difference is the inclusion of the new Thumb-2 instruction-set architecture, indicated by “T2.” The ARM1156 is the first incarnation of ARM’s Thumb-2, announced at the 2003 Embedded Processor Forum. Other differences include a 256-entry branch-history table, allowing it to predict all branches (new and old) in the Fetch3 stage rather than having to wait until the Decode stage to predict first occurrences.

The ARM1136 and ARM1156 pipeline stages are basically identical, except for the latter’s inclusion of a third fetch stage. This stage bumps the ARM1156’s pipeline to nine stages, the same length as the new MIPS 24K when it implements the MIPS16e instructions. The third fetch stage contains only functions to support branch prediction, branch folding, and alignment for the Thumb-2 instructions. The other pipeline stages are essentially untouched: those stages are still performing the exact workload as in the ARM1136; hence, clock speed is unaffected. Like the ARM1136, the ARM1156 contains a three-entry return stack.

Shrinking process geometries benefits speed, cost, power, and voltage. However, process geometries at 0.13 micron and below wreak havoc on things like power density and design complexity. Furthermore, on-chip memories become much more susceptible to errors caused by radiation. To address its fault-intolerant customers, the ARM1156 processor is the first ARM core to incorporate mechanisms to support fault-tolerant memories.

Microprocessor Report readers can access the full story here: www.mdronline.com/mpr/h/2003/1020/174202.html. To find out more about Microprocessor Report, please visit: www.mdronline.com.

MIPS Reveals 24K Core Family
Markus Levy - Senior Editor  {10/20/2003}

At the 2003 Microprocessor Forum, MIPS Technologies announced the near-term roadmap for processors based on its 24K microarchitecture. The roadmap indicates four versions of the 24K family: 24Kc, 24Kf, 24Kc Pro, and 24Kf Pro, where “c” indicates base integer core, “f” the addition of floating point, and “Pro” the support of MIPS’s CorExtend.

With the physical layout completed, MIPS announced the 24Kc core’s size at 3.0mm2 in a 0.13-micron process. The 24Kc is larger than the MIPS 4KE in the same manufacturing process. But the size data for the two processor cores in the same frequency range show less difference when caches are added (with the 24K optimized for area). This is because the 4Ke lacks the luxury of the 24Kc, with its two-cycle memory access. Hence, the 4Ke’s caches must be driven harder to obtain the same speed, resulting in larger caches.

MIPS claims the MIPS24Kx cores will run up to 400–550MHz with commercially available libraries and flows. The 400MHz figure is a realistic worst-case speed in a TSMC 0.13-micron general-purpose process (G); the 550MHz is possible in TSMC’s high-speed process (LV).

Microprocessor Report readers can access the full story here: www.mdronline.com/mpr/h/2003/1020/174203.html. To find out more about Microprocessor Report, please visit: www.mdronline.com.

PicoChip Makes a Big MAC
Tom R. Halfhill - Senior Editor  {10/14/2003}

If you want a Big Mac, go to McDonald’s. If you want a big MAC, see PicoChip Design. The U.K.-based company is introducing the PC102, a massively parallel communications chip that contains 344 processors, including 260 with multiply-accumulate (MAC) units.

PicoChip COO and chief architect Peter Claydon announced the PC102 on October 14 at Microprocessor Forum 2003. It’s surprising that a relatively small startup could design such a complex chip so closely on the heels of its first product, the PC101, which Claydon unveiled only four months earlier at Embedded Processor Forum. (See MPR 7/28/03-02, “PicoChip Preaches Parallelism.”) However, both the PC102 and PC101 are based on the same picoArray architecture, so they have more similarities than differences. Both are communications chips for cellular-telephony and wireless-network infrastructures, although they would excel at other signal-processing tasks.

Despite several enhancements, the PC102 does not supersede the PC101 in the same way that an Intel Pentium 4 replaces a Pentium III. Although the PC102 has twice as many on-chip processors with MAC units as the PC101, the earlier chip has more processors in total. They are siblings, not quite twins, designed for customers having different computational requirements.

PicoChip says the PC102 will ship in 1Q04 and run at 160MHz at its nominal core voltage of 1.2V. Like the PC101, it will be fabricated in TSMC’s eight-layer-metal 0.13-micron digital CMOS process. Volume pricing will be announced soon.

It will be easier to evaluate PicoChip’s unorthodox design philosophy when the company announces volume pricing, firm delivery dates, and design wins. The massively parallel PC101 and PC102 are fairly large, complex devices, limited to a relatively slow clock frequency, even when fabricated in a leading 0.13-micron process. However, their power consumption seems reasonable for muscular communications chips that can potentially replace multiple RISC processors, DSPs, ASICs, and FPGAs. Furthermore, the PicoChip devices are standard parts, obviating the need for an ASIC development project. If PicoChip can deliver on its promises and catch the attention of major base-station vendors, it may have a pair of winners.

Microprocessor Report readers can access the full story here: www.mdronline.com/mpr/h/2003/1014/174103.html. To find out more about Microprocessor Report, please visit: www.mdronline.com.

TSMC Delivers Chip to Cradle
Markus Levy - Senior Editor  {10/06/2003}

Cradle was established in 1995 as a project at Cirrus Logic and became independent in 1998. In 1999, the Cradle architecture was presented at Microprocessor Forum, with plans to introduce the first chip in 2000. Well, here it is 2003, and the first chip has just arrived, supporting image-processing and video-communications applications. Cradle chips crank out 28 gigaMACs and are supported by homegrown development tools that provide C-level programmability for the on-chip resources.

The ’3400 chips, built in a 0.15-micron process, run at 220MHz. This relatively low operating frequency benefits power consumption, as seen by the chip’s consumption of 3W with a 1.2V supply. We can see the ECE3400 or MPE3400 being used as a coprocessor alongside a general-purpose processor with a standard instruction set architecture (ISA). Furthermore, the chips may find their homes in low-volume applications that don’t justify the cost of a custom ASIC.

Microprocessor Report readers can access the full story here: www.mdronline.com/mpr/h/2003/1006/174003.html. To find out more about Microprocessor Report, please visit: www.mdronline.com.