Silicon Insider

by Jim Turley
Silicon Insider #39, June 2006

“When I hear the word 'culture' I reach for my revolver,” deadpanned Hermann Göring, a man who was clearly all business. In the technology business, I sometimes want to shoot the messenger when every one of them is breathlessly abuzz over dual-core processors.

Processor "cores" and their apparent proliferation seem to have captured the imagination of those with little imagination – or recollection of history. Intel's marketing people very shrewdly trademarked the name Core as the successor to the popular Pentium brand name. Now any conversation about processor cores unintentionally involves trademarked name-dropping. Clever marketing, that.

Over in the engineering world, processors cores have been with us since there were processors. Every microprocessor and microcontroller in the world has a core in the same way that every car has an engine. The core is simply the brain of any processor. It's where the software gets executed and the data gets shuffled. It's the little man in the radio who sings.

Chips with two cores, or four, or ten, or even more are commonplace. In fact, the the average is 2.3 cores per processor chip. In short, this has all been done before.

There's obviously no trick to making multi-core processors. The real trick is the software. Dual-core processors are usually synchronized, running in lockstep using the same cache and same bus interfaces. They share an instruction set and memory or I/O resources, but execute two different streams of code. Like the Hydra, they have separate minds but one body. Who but Hercules can tame such a beast?

In mythology, Hercules got help from his nephew, Iolaus. And so it is today. To attack this multi-headed monster we'll need help from the software vendors. That means new software tools that can balance programming loads among two or more processors. Debuggers will have to evolve, too. This is all doable and it's already underway. Expect to see a stream of announcements on this front over the coming year.

But new compilers and debuggers won't be enough. We're facing a change to new programming languages. Current languages like C don't express parallelism well. Compilers can identify threads of execution or independent constructs and extract some small amounts of parallelism here and there, but the language itself prevents large-scale parallelism. If we're to exploit these new multi-processor chips, we're going to have to swallow hard, roll up our sleeves, and tackle a truly Herculean task.

Comment on this article

by Jim Turley
Silicon Insider #31, October 2005

There's some debate right now over whether to allow cell phone calls on airplanes. Turns out the FAA was being overly cautious before. ("Just fooling -- cell phones don't really interfere with navigational equipment after all.") No problem; better safe than sorry. So now we have the option of allowing cell phone usage on flights.

The question now becomes, do we really want to? While it might be technologically sound, is it socially acceptable? Informal polls show that most people oppose to the idea. They like the relative isolation of a long plane flight.

We're creeping toward a similar situation in our cars. Automotive electronics have brought all sorts of improvements but we're reaching the point where the electronics have surpassed what's necessary and moving into what's merely interesting.

In-car entertainment, back-seat video screens, satellite radio, and other "frivolous" features are very popular, and quite profitable. GPS-based navigation systems are also flying out of showrooms, so to speak, and will likely become standard equipment before long. Bluetooth connections to cell phones aren't unusual, and add an interesting new twist to "hands-free" communication; you don't even have to remove the phone from your purse.

Somewhere along the line we'll overstep the bounds of what mainstream auto buyers want, and take a small step back. It's impossible to predict where that point lies or when it will arrive, but it's inevitable. Every industry tests its boundaries this way, whether it's consumer electronics, banking, retailing, or music. I suspect the tipping point will come fairly soon, and the issue will be reliability.

We're accustomed to mechanical breakdowns in our cars but not electronic failures. There's something inherently creepy about software failures in an automobile. Perhaps it's cultural or simply at odds with our accumulated experience, but we're not comfortable with the idea that our onboard computers might crash, as it were. A news story circulated recently about a certain make of car contracting viruses through the Bluetooth interface. Like having alligators in the sewers, it doesn't matter whether the story is true or not. It shows how people are uneasy with the very idea.

Most people equate "software" with "computer," and that is not a happy analogy. We'd all hope that our cars would be more reliable than our PCs. Automotive software needs to be utterly reliable and predictable, regardless of where it's used. Most people won’t make a distinction between the failure of their in-dash CD player and the failure of their antilock brakes. If the CD software hiccups, the entire car is suspect. The consumer electronics firms understand this; they know that DVD players and VCRs need to be utterly reliable, even if they're hardly safety-critical devices. Computer makers, on the other hand, happily tolerate a certain amount of iffiness. Let's be sure the former philosophy prevails.

Comment on this article

by Jim Turley
Silicon Insider #27, June 2005

Recently Embedded Systems Design magazine, which I also edit, conducted a large-scale survey of developers across North America and Europe. We asked a number of questions related to hardware, software, schedules, budgets, and other topics. One of the more surprising conclusions to come out of the survey was the way in which developers choose their microprocessors.

When asked to rank price, performance, power consumption, peripherals, pinout (the Five P's) and several other factors in evaluating processors, the top choice was clear: none of the above. Overwhelmingly, the top choice was one we put far down the list: software tools.

By a wide margin, developers said that the software tools (compilers, assemblers, debuggers, etc.) were far more important than pipelines and caches, availability, performance, or even price. In fact, they frequently choose their tools first and then select a chip that's supported by the tools, rather than vice versa.

Furthermore, their loyalty to the software tools outweighed their loyalty to processor vendors or instruction-set architectures. In other words, developers would rather switch processor families than switch compilers.

The lesson for chip vendors is clear: from this day forward, consider yourselves software companies. Spend your development resources on more and better tools, and treat chip sales as royalties on that software. It's your tools, not your chips, that customers are evaluating so it makes sense to put the effort there.

Comment on this article

by Jim Turley
Silicon Insider #23, February 2005

I got to meet two of my heroes. Through the kindness of Freescale I found myself in Austin attending that company's in-house engineering Conference. The keynote speaker was Gene Krantz, NASA's mission controller in Houston during all the odd-numbered Apollo missions, including the Apollo 11 moon landing, the near-disastrous Apollo 13, and the final Apollo 17 mission. If you've watched the movie version of Apollo 13 Gene was the Ed Harris character with the stern demeanor, the crew cut, and the lucky white vest his wife made for him.

Krantz was a no-nonsense speaker, as you might imagine. He somehow managed to look a thousand people straight in the eye and tell us, "failure is not an option." He and his team at Mission Control rescued three astronauts stranded farther from home than any people have ever been, before or since. Remarkably, a key part of the strategy was to send them farther away, around the dark side of the moon (and out of radio contact), in order to conserve fuel and buy time.

Gene described the mission's early details. Everything was going smoothly; better, in fact, than many previous launches. As the astronauts were just about to go to sleep and coast toward the moon, the entire ground crew was startled with the chilling, "Houston, we have a problem."

Like a replay of history, we in the audience heard these same words come over the sound system, but they didn't come from Gene's mouth. In a clever bit of stagecraft, astronaut Fred Haise had been hiding just offstage waiting for his cue. Now Haise and Krantz were reunited (not for the first time, I'm sure) to recount what the Apollo 13 flight was like from both perspectives.

The movie famously shows the ground team cobbling together air filters from bits of flotsam found on the spacecraft. Systems were shut down to conserve battery power. The astronauts shifted first from one spacecraft (the lunar lander) to the other to make use of all the available oxygen and energy. The capsule and the three astronauts got miserably cold in the void of space, but here Haise said the movie departed from reality. "I don’t care how cold it gets," said the former Air Force captain, "I wasn't going to hug a Navy flier."

These men's tale is one of fortitude, endurance, and skill under pressure. They were dealing with an embedded system – several, in fact – that had failed for no apparent reason. No one involved had built this system, but they understood it well. In the ultimate case of remote debugging, they determined what worked, what didn't work, and what could be made to work in the time allowed. There were no recriminations because no one yet knew what caused the failure, so there was no one to blame. More important, they wouldn't have cared. Solving the problems – and there were many – under pressure and with limited resources made that team great. Under Krantz's leadership, Mission Control guided the most complex machine ever created up to that time all the way from the moon to earth and down to its landing site in the ocean. That's what great engineering can be.

Comment on this article