Transmeta Corporation

On October 14, 2003, Transmeta announced the Efficeon processor which was claimed to have twice the performance of the original Crusoe CPU at the same frequency. However, performance was still weak relative to the competition and the complexity of the chip had increased significantly. The greater size and power consumption may have diluted a key market advantage Transmeta's chips had previously enjoyed over the competition.

In January 2005, the company announced its first strategic restructuring away from being a semiconductor product company and began to focus on licensing intellectual property. In March 2005, Transmeta announced that it was laying off 68 people while retaining 208 employees. Sony was reported to be a key licensee of Transmeta technology, and approximately half of the remaining employees were to work on LongRun2 power optimization technology for Sony.

On May 31, 2005, Transmeta announced the signing of asset purchase and license agreements with Hong Kong’s Culture.com Technology Limited. The deal fell apart due to delays in obtaining technology export licenses from the US Department of Commerce and the parties announced the termination of the agreements on February 9, 2006.

On August 10, 2005, Transmeta announced its first-ever profitable quarter. This was followed by GameSpot’s March 20, 2006 report that Transmeta was working on an "unnamed" Microsoft project. As it turned out, this was a secure platform under the AMD brand for Microsoft FlexGo.

On October 11, 2006, Transmeta announced that they had filed a lawsuit against Intel Corporation for infringement of ten Transmeta U.S. patents covering computer architecture and power efficiency technologies. The complaint charged that Intel had infringed and was infringing Transmeta's patents by making and selling a variety of microprocessor products, including at least Intel's Pentium III, Pentium 4, Pentium M, Core, and Core 2 product line.

On February 7, 2007, Transmeta shut down its engineering services division, terminating 75 employees in the process. This was concurrent with an announcement that the company would no longer develop and sell hardware and would focus on the development and licensing of intellectual property. Subsequently, AMD invested $7.5 million in Transmeta, planning to use the company's patent portfolio in energy-efficient technologies.

On October 24, 2007, Transmeta announced an agreement to settle its lawsuit against Intel Corporation. Intel agreed to pay $150 million upfront and $20 million per year for five years to Transmeta and drop its counterclaims against Transmeta. Transmeta also agreed to license several of its patents and assign a small portfolio of patents to Intel as part of the deal.

Transmeta also agreed to never manufacture x86-compatible processors again. One significant sore point in the Intel litigation was the payout of approximately $34M to three of Transmeta's executives. In late 2008, Intel and Transmeta reached a further agreement to transfer the $20 million per year in one lump sum.

On August 8, 2008, Transmeta announced that it had licensed its LongRun and low-power chip technologies to Nvidia for a one-time license fee of $25 million. On November 17, Transmeta announced the signing of a definitive agreement to be acquired by Novafora, a digital video processor company based in Santa Clara, California, for $255.6 million in cash, subject to adjustments dependent on working capital. The deal was finalized on January 28, 2009, when Novafora announced the completion of its acquisition of Transmeta.

Intellectual Venture Funding LLC completed the acquisition of the patent portfolio formerly developed and owned by Transmeta Corporation on February 4, 2009.

Due to financial troubles and inability to execute, Novafora collapsed in late July, 2009.

Financial history

The following charts show the company's revenues, operating expenses, gross profits, and net losses from 1996 through 2007. Numbers are in 1000s as per the 10-K reports. The company was once named as the Most important company in Silicon Valley in an Upside magazine editorial, but failed to obtain profitability while it was a chip vendor.

Funding

Transmeta received a total of $969M in funding during its lifetime.

The Transmeta Efficeon processor addressed many of Crusoe's shortcomings and showed roughly a 2x real-world improvement over Crusoe. Its die was considerably smaller than Pentium 4 and Pentium M, when compared in the same process technology. Efficeon's die fabricated in 90 nm is 68 mm2, which is 60% of the Pentium 4 in 90 nm, at 112 mm2, with both processors possessing a 1 MB L2 cache.

The notion of selling a product into a specific thermal envelope was typically not understood by most reviewers, who tended to compare Efficeon to the gamut of x86 microprocessors, regardless of power consumption or application. One such example of this criticism suggested that the performance still significantly lagged behind Intel's Pentium M (Banias) and AMD's Mobile Athlon XP.

Technology

Transmeta processors were in-order very long instruction word (VLIW) cores running a special dynamic binary translation software layer which together implemented compatibility with the x86 architecture. Transmeta trademarked the term "Code Morphing" to describe their technology and referred to the software layer as Code Morphing Software (CMS).

Transmeta used reverse body bias to reduce power consumption by a factor of about 2.5. (A similar technology was used in XScale processors.)

Code Morphing Software

Code Morphing Software (CMS) is the technology used by Transmeta microprocessors to execute x86 instructions.

In a broad view, CMS reads x86 instructions and generates instructions for a proprietary VLIW processor, in the style of Shade (the fast instruction set simulator and custom trace generator originally developed by Bob Cmelik (Sun Microsystems) and David Keppel (University of Washington)).

CMS translation is much more expensive than Shade's, but it produces much higher quality code. CMS also contains an interpreter and simulates both user-mode and system-mode operation.

Code Morphing Software consisted of an interpreter, a runtime system, and a dynamic binary translator. x86 instructions were first interpreted one instruction at a time and profiled, and then, based on the frequency of execution and other heuristics, CMS would progressively generate more optimized translations.

Similar technologies existed in the 1990s: Wabi for Solaris and Linux, FX!32 for Alpha, IA-32 EL for Itanium, open-source DAISY (Dynamically Architected Instruction Set from Yorktown) and its successor BOA (Binary-translation and Optimization Architecture) from IBM Research, and the Mac 68k emulator for the PowerPC. The Transmeta approach set a much higher bar for x86 compatibility due to its ability to execute all x86 instructions from initial boot up to the latest multimedia instructions.

The operation of Transmeta's code morphing software is similar to the final optimization pass of a conventional compiler. Considering a fragment of 32-bit x86 code:

add eax,dword ptr [esp] // load data from stack, add to eax

add ebx,dword ptr [esp] // ditto, for ebx

mov esi,[ebp] // load esi from memory

sub ecx,5 // subtract 5 from ecx register

This is first converted simplistically into native instructions:

ld %r30,[%esp] // load from stack, into temporary

add.c %eax,%eax,%r30 // add to %eax, set condition codes.

ld %r31,[%esp]

add.c %ebx,%ebx,%r31

ld %esi,[%ebp]

sub.c %ecx,%ecx,5

The optimizer then eliminates common sub-expressions and unnecessary condition code operations and, potentially, applies other optimizations such as loop unrolling:

ld %r30,[%esp] // load from stack only once

add %eax,%eax,%r30

add %ebx,%ebx,%r30 // reuse data loaded earlier

ld %esi,[%ebp]

sub.c %ecx,%ecx,5 // only this last condition code needed

Finally, the optimizer groups individual instructions ("atoms") into long instruction words ("molecules") for the underlying hardware:

ld %r30,[%esp]; sub.c %ecx,%ecx,5

ld %esi,[%ebp]; add %eax,%eax,%r30; add %ebx,%ebx,%r30

These two VLIW molecules could potentially execute in fewer cycles than the original instructions could on an x86 processor.

Transmeta claimed several technical benefits to this approach:

As the market leaders Intel and/or AMD would extend the core x86 instruction set, Transmeta could quickly upgrade their product with a software upgrade rather than requiring a respin of their hardware.

Performance and power can be tuned in software to meet market needs.

It would be relatively simple to fix hardware design or manufacturing flaws in the hardware using software workarounds.

More time could be spent concentrating on enhancing the capabilities of the core or reducing its power consumption without worrying about 33 years of backward compatibility with the x86 architecture.

The processor could emulate multiple other architectures, possibly even at the same time. (At its initial Crusoe launch, Transmeta demonstrated pico-Java and x86 running intermixed on the native hardware.)

Prior to Crusoe's release, rumors indicated Transmeta was relying on these benefits to develop a hybrid PowerPC and x86 processor. But Transmeta initially concentrated solely on the extremely low-power x86 market.

The ability to quickly update products without a hardware respin was demonstrated in 2002 with an in-the-field upgrade (a download) to enhance CPU performance of the Crusoe based HP Compaq TC1000 tablet PC. It was used again in 2004 when the Transmeta Efficeon product line added NX bit and SSE3 support without requiring hardware changes. In-the-field upgrades were rare in practice due to system hardware vendors not wanting to incur additional customer support costs or spend additional money on QA for the potential upgrades or bug fixes to shipped products they had already closed the revenue books on.

VLIW core

In conjunction with its code-morphing software, the Efficeon most closely mirrors the feature set of Intel Pentium 4 processors, although, like AMD Opteron processors, it supports a fully integrated memory controller, a HyperTransport IO bus, and the NX bit, or no-execute x86 extension to PAE mode. NX bit support is available starting with CMS version 6.0.4.

Efficeon's computational performance relative to mobile CPUs like the Intel Pentium M is thought to be lower, although little appears to be published about the relative performance of these competing processors.

Efficeon came in two package types: a 783- and a 592-contact ball grid array. Its power consumption was moderate (with some consuming as little as 3 watts at 1 GHz and 7 watts at 1.5 GHz), so it could be passively cooled.

Two generations of this chip were produced. The first generation (TM8600) was manufactured using a TSMC 130 nm process and produced with speeds up to 1.1 GHz. The second generation (TM8800 and TM8820) was manufactured using a Fujitsu 90 nm process and produced with speeds ranging from 1 GHz to 1.7 GHz.

Internally, the Efficeon had two arithmetic logic units, two load/store/add units, two execute units, two floating-point/MMX/SSE/SSE2 units, one branch prediction unit, one alias unit, and one control unit. The VLIW core could execute a 256-bit VLIW instruction per cycle. A VLIW is called a molecule and has room to store eight 32-bit instructions (called atoms) per cycle.

The Efficeon had a 128-KB L1 instruction cache, a 64-KB L1 data cache, and a 1-MB L2 cache, all on-die.

Additionally, Efficeon code morphing software (CMS) reserved a small portion of main memory (typically 32 MB) for its cache of dynamically translated x86 instructions.

Native compilation

In principle, it should be possible to optimize x86 code to favor Code Morphing Software, or even for compilers to target the native VLIW architecture directly. However, writing in 2003, Linus Torvalds (a former employee of Transmeta) apparently dismissed these approaches as unrealistic:

The native Crusoe code – even if it was documented and available – is not very conducive to general-purpose OS stuff. It has no notion of memory protection, and there's no MMU for code accesses, so things like kernel modules simply wouldn't work.

The translations are usually better than statically compiled native code (because the whole CPU is designed for speculation, and the static compilers don't know how to do that), and thus going to native mode is not necessarily a performance improvement.

So no, it wouldn't really benefit from it, not to mention that it's not even an option since Transmeta has never released enough details to do it anyway. Largely for simple security concerns – if you start giving interfaces for mucking around with the "microcode", you could do some really nasty things.

[...I meant...] "you cannot do that". And we won't even tell the details of how you cannot do that.

In fact, even inside Transmeta you cannot do that, without having a specially blessed version of the flash that allows upgrades. If you ever see a machine with a prominent notice saying "CMS upgraded to development version", then that's a hint that it's a machine that TMTA developers could change.

Subsequent reverse engineering, published in 2004, clarifies some details of the native VLIW architecture and associated instruction set, and suggests that there are fundamental limitations that preclude porting an operating system such as Linux to it.

The same work also compares Transmeta's patented technology with prior art published and in some cases patented by IBM, and suggests that some claims might not stand detailed scrutiny.