Silicon Insider

At its annual Freescale Technology Forum (FTF) corporate event, microcontroller giant Freescale announced that it's launching a broad line of 200+ ARM-based chips starting later this year. The move is a momentous one for Freescale, which has always based its midrange chips on its own in-house ColdFire technology. Now, the company's chips will be based on ARM, with ColdFire playing a supporting role.

The announcement brings Freescale in line with practically every other microcontroller and embedded-processor, which have all licensed ARM processors, it seems. The decision must have been a difficult one, but necessary in order to broaden Freescale's market appeal. ARM has undeniable momentum in the marketplace, to the point that it's almost become a de facto standard. Engineers have to explain why they're not using ARM processors. ColdFire, in contrast, appeals mainly to established (read: old) engineers who have used ColdFire (or its predecessor, the 68K) for years.

ColdFire has a very large and happy installed base. It's not going away any time soon. But the announcement of the ARM-based product line sounds suspiciously like the death knell for the much-loved ColdFire family. It seems likely that it will gradually be eclipsed by newer, faster, and better-known ARM-based equivalents.

Freescale calls its new ARM-based product line Kinetis, and all Kinetis chips are based on the Cortex-M4 processor core -- at least, for now. The company has left the door open to using other ARM processors, most likely other M-series cores. The Cortex-M3 wouldn't make any sense, as the -M4 is already a superset of the -M3. But low-end chips based on Cortex-M0 might made sense.

As if to soften the blow, Freescale also pulled the wraps off an upgrade to the ColdFire family, called ColdFire+. The plus suffix indicates a shift to more modern 90nm silicon production and the inclusion of a new nonvolatile memory technology called TFS (thin-film storage). ColdFire+ is not a processor or performance upgrade, however. In fact, the first ColdFire+ chips use one of the slower versions of the ColdFire processor core, known simply as version 1. From here on, it will be important for Freescale to differentiate its ColdFire+ chips from its new Kinetis chips; no point having two similar processors with the same performance and peripheral mix.

Freescale positions Kinetis not as a replacement for ColdFire (or its PowerPC-based chips), but as a complement. A new sibling, if you will. That's true in a lot of ways. Kinetis will appeal to developers who want ARM-based chips and software tools and who would not have considered Freescale previously. In that sense, it's accretive business. But it's also hard not to feel bad for ColdFire+, which now is positioned as the third alternative in the company's crowded three-way processor lineup.

Silicon Insider's new address is:

649 Lighthouse Avenue
Pafific Grove, CA 93950

Telephone numbers stay the same.

Chalk one up for sensationalist journalism.

A new Associated Press article article describes, in somewhat breathless terms, how security consultant Chris Tarnovsky "cracked" the security chip found in most PCs. According to the article, this will lead to widespread identity theft, lost passwords, stolen military secrets, and more.

Although the details of Tarnovsky's exploits are accurate, the fallout is not. In reality, this is no big deal. Here's the background.

Read more: "Black Hat" PC Security Hack Is No Big Deal

Contrary to popular belief, Intel makes just two percent of the world's microprocessor chips.

Surprised? You wouldn't be if you worked with us.

You read it every day in the press: Intel has 90-something percent share of the microprocessor market.

Nothing could be further from the truth. Although it's true that Intel supplies 90-odd percent of the microprocessor chips used in PCs, the larger reality is that PCs are only a small percentage of global consumption of microprocessor chips. Even if Intel controlled 100% of the PC market (and there were no AMD or other competitors), it would still command only 2-3 percent fo the total microprocessor market.

Intel is a very big fish in a small pond, you might say.

So what about the other 98% of microprcoesor chips? Where do they go, who buys them, and who supplies them? The overwhelming majority of microprocessor and micrcontroller chips manufactured every year go into something other than a PC. This is known as the "embedded" market, mean these chips are embedded into products other that aren't PCs. That's a lot of chips to ignore. Intel has relatively little presence in the embedded market; it is one among many players. Instead, dozens of other semiconductor companies occupy that market space.

Remember, we're talking about unit volume, not revenue. Intel's chips are extraordinarily profitable, so the company's small 2% unit volume equates to a large slice of the revenue pie. Embedded microprocessor chips are comparatively inexpensive, so they generate less revenue individually but more in total. How much more? Give us a call and let's discuss it.

The silicon chip business has some unusual economic characteristics that you won't find in most other industries.

In most manufacturing businesses, if you sell more products you also have to buy more raw materials. If you're making boats and your orders increase, you have to purchase additional wood, brass, and fiberglass to build the boats you're selling. If you make TVs, you need to buy more cathode-ray tubes (or LCD or plasma displays) to put into the TVs. When sales go up, your materials costs go up. Pretty simple.

But the chip-making business doesn't work that way. Microprocessors, DRAMs, and other chips all contain silicon, copper, aluminum, and maybe a little gold or other trace elements but those ingredients aren't the most expensive part of the chip. Unlike other tangible goods, in the semiconductor business the raw materials are essentially free. Making more chips doesn't mean spending (much) more on raw materials.

No, the most expensive part of a silicon chip is the depreciation on the equipment used to make it, including the building. A semiconductor factory, or fab, is horrendously expensive to build and maintain, to the tune of $2 billion to $3 billion dollars in construction costs, plus tens of millions per year in maintenance. And the whole facility will be obsolete within three to five years. Ouch.

That means each and every chip coming out of the fab is burdened with the enormous overhead cost of that depreciation. That depreciation is actually the biggest cost for many chips, eclipsing the expensive raw materials that went into it. It's as if chip makers taped a $5 bill to each new microprocessor.

Making more chips doesn't raise the manufacturer's costs very much. In fact, greater volume effectively lowers costs because that crushing depreciation can now be spread over more chips. Same overhead; more units. That's a good thing for both producers (them) and consumers (us). In a sense, the first chip off the assembly line costs $2 billion; all the chips after that are free. Like real estate, the material is cheap but the space is expensive. You're paying for the acreage, not the dirt.

That's why chip makers are so fanatically focused on high-volume products. They want/need to amortize their overhead costs over as many units as possible. That's also one of the reasons chips are constantly getting smaller. It's not so that they'll use less silicon or copper, it's so that more of them will fit on a single wafer, thereby increasing the yield per wafer. Semiconductors are like pharmaceuticals: very high development costs and very low unit costs. The difference is, there are more Canadian chip companies.
 

The Internet: maybe you've heard of it. It's the great equalizer and the great enabler. Part of its beauty is that it's global, it's egalitarian, and it's free. Internet standards like HTML, POP, and SSL were designed to be hardware-, software-, language-, OS-, and byte-ordering neutral. It doesn't matter what computer you're using or what operating system you prefer. Internet standards don't care if you're a PC or Mac user, big-endian or little-endian, using a fast new machine or an old slow one.

That glorious impartiality comes at a price, though. It's hard to imagine a less-efficient way to transport data than with 7-bit ASCII-encoded HTML. But efficiency wasn't the goal in defining the Internet's internal standards; universality was. We're willing to give up a little (okay, a lot) in transport efficiency in exchange for a single global network that everyone can share. Or can they?

The answer, as with so many things, is yes and no. Although the Internet's network plumbing is hardware-agnostic, most Web content is not.

Web content has become less portable and more client-specific over time. This didn't happen by accident. It's the result of both commercial forces and simple human nature. The upshot is that today's Web is becoming an Intel- and Microsoft-centric medium, just like PC software is. And there's no reason why this situation will change any time soon. Whether that's a good thing or a bad thing depends mostly on your job.

Getting there from here
First things first: is the Web really platform-neutral or has it become PC-centric? Anyone who's spent an hour surfing the Web on two different computers has seen how pages often look different on different machine. Folks with a PC at work and a Mac at home are familiar with this effect. Even changing browsers on the same computer (from Internet Explorer to Opera, for example) can highlight dozens of differences in what was supposed to be a standard presentation format. Anything more exotic than an all-text page with blue underlined links is liable to look and behave differently on different clients. Viewing a favorite site on your BlackBerry or iPhone is also likely to lead to frustration--or amazement that it works at all.

How did Web content get this way? It's a combination of simple human nature mixed in with a fair bit of commercial self-interest. After the initial "gee whiz" wore off around 1994, most of us got bored with plain-text Web pages. Some Webmasters studded their pages with blinking text or flashing borders. That was about as creative as early browsers would allow. Remember, HTML wasn't created with today's slick e-commerce economy in mind. It was intended for academics.

Today, any decent commercial Web site uses Flash, Java, QuickTime, Postscript, Real Audio, and any number of other semi-standard extensions to the basic HTML underpinnings. These extensions have all become part of the Web's lingua franca: the language of global Internet commerce. Increasingly, you can't even read a site's basic content--never mind browse the catalog or log in--without installing the requisite helper applications to read PDF or Flash files.

Here's where the problem starts. Like any program, these helper applications had to be written for (or ported to) each distinct combination of processor and operating system. The Adobe PDF reader for Internet Explorer 7 running on Windows XP running on an Intel Core 2 Duo processor isn't the same as the PDF reader for Safari running on Mac OS running on a PowerPC chip, and so on. Just like any other team of programmers, the folks who develop these helper apps must look at the cost/benefit. Is it worth the effort to port this program to Platform X if said platform accounts for only 5% of the market? Do we really need to write, debug, and support a RealAudio decoder for the Commodore 64, Silicon Graphics Indigo, or Cray Y-MP if hardly anybody will ever use it?

A good example is Flash and the iPhone. Millions of happy iPhone users know that their favorite toy can't render Flash animation. There just isn't a Flash helper application for iPhone and, until recently, no hope of getting one. Apple has since released an iPhone software-development kit, so Adobe will presumably be quick to fill this gap in its product coverage. But in the meantime, no iFlash.

So browsers and their helper apps behave just like any other software. They must be ported and supported, and that means the most popular processors and operating systems get supported first. The less-popular platforms catch up later, if at all. Your Amiga might be able to load Google's basic home page, but good luck getting YouTube to work.

That's the practical side. There's a commercial side at work, too. Microsoft, like any good software company, wants to protect and extend its customer base. It has done this in part by encouraging a number of "non-standard" extensions to Web content. Active server pages (ASP), ActiveX, Exchange Server, and .NET are a few examples of Microsoft's contribution to Web content cacophony. Oracle, Real Networks, and other companies have all done likewise, promoting extensions in which they had a commercial interest. Some of these efforts have been more successful than others, but all of them erode the independence and client-agnosticism that was inherent in the early Internet. The more bells and whistles we add, the more locked-in we become.

Meet the new boss
We now have a situation where Web content is developed for the PC first, with Macintosh, Linux, and other clients coming later. In contrast, few Web sites are deliberately Mac-specific, even Apple's. If your site doesn't work on a PC running Windows and Microsoft's latest browser, it's effectively broken. The Intel/Microsoft hegemony rules the Internet just as it does the desktop, and certainly not by coincidence.

But what about mobile platforms, you say? Intel's footprint is very small in handheld devices, where ARM is considered the hands-down winner. Is the mobile Web going to be ARM-specific? Quite probably.

It's fair to say that ARM-based chips are the most popular processors for smart phone designs, just as Intel's chips dominate the desktop/laptop/server business. But ARM's popularity doesn't make all smart phones identical. A CPU instruction set does not a standard make. The handheld software market is too fragmented to consider it one platform. Programmers working on mobile applications must navigate through a forest of choices. But regardless of operating system and other software concerns, we can guess what kind of compiler they'll use.

But wait, there's more
Deeply embedded systems are the exceptions that prove the rule. The proverbial Internet-enabled Coke machine and plenty of other embedded systems now sport full- or part-time Internet connections for monitoring, feedback, or content delivery. Then there are the routers, packet inspectors, encryption appliances, firewalls, and all the other embedded-systems plumbing that makes the network work. None of these needs a traditional browser or any helper applications. Coke machines don't need to render Flash animation (yet) and file servers don't need an Acrobat reader.

So although these more deeply embedded systems greatly outnumber the PC-type clients, they have little effect on the actual Web content. Routers route data regardless of content, for the most part. Unless they're sniffing packets for viruses or doing QoS massaging, embedded network boxes generally don't care what the traffic is bearing. They don't affect what is on the Web, only how it's delivered.

Déjà vu all over again
This whole situation puts programmers in a strong negotiating position. Their helper applications are what make the Web interesting. Without the full assortment of helper apps, new client hardware is nearly useless. Witness the dismal failure of WebTV and other "network appliances." Sure, they could render basic HTML, but without all the extra content bells and whistles, they weren't much fun. And isn't that what the Web is all about?

Web content relies on specific helper applications just like desktop PCs rely on productivity applications. Without the full array of browser plug-ins, users are disappointed and Web publishers aren't happy. The same commercial and technical issues that shaped the PC market have conspired to make the Web processor-specific.