LinuxDevices.com Archive Index (1999-2012) | 2013-current at LinuxGizmos.com | About  

Glenn Henry on the Isaiah architecture

Jan 23, 2008 — by LinuxDevices Staff — from the LinuxDevices Archive

Foreword — This informal mini-interview with Glenn Henry, president of Via's CenTaur processor division, took place a few days before the unveiling of Via's “Isaiah” architecture. Henry discusses Isaiah's technical merits, market positioning, and competitive prospects against current and future offerings from… chip giant Intel.

As background, be sure to read our coverage of Via's Isaiah announcement, here.


Competitive landscape


(Click to enlarge)

Asked to compare the first Isaiah-based chips in performance to offerings from Intel, Henry suggested performance might be comparable to single-core parts based on the Core2 architecture. He explained, “We didn't design [Isaiah] to compete with Core2. Mobile and small form-factor green devices is still our major focus. But, when you double performance, you're going to be more competitive in what you might call the 'full-size' notebook area.”

As for increased competition from Intel in mobile and small form-factor devices — Via's traditional strength — Henry noted, “Silverthorne has a different architecture, different chipset [Ed. note: Silverthorne uses a “Poulsbo” companion chip, rather than standard northbridge/southbridges], different packages, different everything. They want to make sure it doesn't eat away at their main product lines. If they make it too fast or too capable, people might buy it instead of Core2 mobile parts. They've constrained performance, and constrained compatibility.”

Compatibility, meanwhile, has always been a priority for Via, Henry said, explaining, “We've got to be blindingly compatible. We don't have the leverage, and we don't want to spend the money to create any new features for us, other than the PadLock [crytographic acceleration] that we've done.”

Incompatibilities aside, can't Intel — one of the best-capitalized companies in the world — out-compete anyone on price? Henry doesn't think so.

“Intel can afford to drop prices for a while, but they can't afford to do it in mass quantity, without losing shareholders. We'll just see. Intel's mobile pricing is very high, [because historically] AMD is not strong on low power. So, it'll be interesting to see what their pricing is with their new [Menlow] products, relative to low-end Core2 mobile parts.”

Henry declined to say how Isaiah chips will be branded or priced. He commented, “We'd be crazy to talk about pricing when we haven't seen Intel's.”

Henry added, “We've been with Via for eight and a half years, and we've survived every price attack, we've survived patent attacks, and we're still in business. We sort of think we understand how to survive. We're alive in our 13th year because we have the lowest-cost structure, lowest-cost parts, lowest-cost package, our testing is inexpensive — my cost [designing our processors] is almost negligible compared to anyone else's.”

“I'm proud of the team here. We did this new architecture and first chip with a company of less than 100 people, including lots of testers and support people. Intel's process is also very good, but since when has product cost been a key factor in their market?”

And what of the fallen foes in Intel's wake, such as Transmeta and Cyrix? Henry said, “Transmeta was doomed to start with. Their die was too big, their power approach was over-hyped, and they had grotesque incompatibility. Then, they were incredibly bloated. I used to joke that they had more VPs than we had people. They certainly had more managers than we had people.”

“Cyrix had a good product, but they got bought by a 'big smokestack' company and they got bloated. When Via bought Cyrix, they had 400, and we had 60, and we were turning out more product.”

Design goals behind Isaiah


(Click to enlarge)

Henry was happy to talk about his design goals for Isaiah. “The goal when we started was not to leave the low-power world, but to bring more performance at the same power. We double or tripled performance with the same power consumption, and that's really hard to do. We've also added a VM architecture and 64-bit support, not because we need them today, but because history says they'll be needed tomorrow.”

“It's no secret that the C7 is not terribly good at floating-point computation. So, we put a lot of thought into that. If you look at the timings at the instruction level, [our floating point unit] is faster than anybody else's. We actually have some major inventions there. We can do four single-precision adds and four single-precision multiplies in a single cycle.

“Our 64-bit architecture is Intel's. Intel's first 64-bit implementation was an add-on, and not very good. But now, Intel's is the same as AMD, and they implement it well. The differences between AMD and Intel [64-bit support] are trivial.

“Our VM architecture is VTX. Read the Intel VTX spec, and that's our spec. We prove it by running off the shelf software — VMWare, and others.

“64-bit support was relatively easy. The VM stuff is a lot more complicated. You've got the world's ugliest instruction set, and now you're going to virtualize it, so you have ugly squared.”

By “ugly,” Henry is referring to the many “weird optimizations” in x86 resulting from the days when transistors were “expensive” — that is, a very limited resource. For example, X86 instructions must be “decoded” into micro-ops before being executed.

Ugliness aside, Henry has long been a firm believer in x86. He recalls, “I was an IBM fellow, and I moved into the PC group there in '84 or '85. So, I started at IBM on x86 at the same time they were doing PowerPC. Everyone thought I was crazy, saying 'Look at our beautiful architecture!' But now look at the ratio of x86 to PowerPC. I could see [the role personal computers were to play]. Look at the ratio of x86 to PowerPC today. Software begets more software, and who really cares what instruction set is underneath it, as long as it works?”

Henry adds, “Alpha went out, PA-RISC went out, and there's a steady stream of RISC architectures withering on the vine every year.”

What's ahead for Isaiah?


(Click to enlarge)

And so, what's next for the Isaiah architecture, longer-term? Will the part's interesting cache architecture work okay in multi-core designs, for example?

Henry replied, “Isaiah has been architected to be multi-core. Our L2 is exclusive, rather than inclusive, but there's nothing weird about that for a dual-core. Data can still be shared, and can be available to either processor. Either L1 can push data into L2. We chose not to do a dual-core in the first parts, though. Why double the heat, double the transistors, and double the cost, when most of the customers don't need the performance of multicore? But dual-core has been thought about a lot, and it's a matter of when.”

In the nearer term, the focus will be on refining Isaiah, now that first silicon is in hand. Henry observed, from long experience, “Every architecture that comes out, you can improve performance 20 percent [in the first revision]. Then 10 percent, then five percent. No matter how much you model, analyze, study traces, and so on, once you have silicon you're “infinitely wiser” — I think that's the technical term I use in my architecture paper.

“We are already at work making the straightforward changes. There are millions of sizes to balance. 'How big is this buffer? How big is this FIFO?' A lot of the tuning is straightforward. 'We have two integer units, but maybe we should have three?' Those changes are easy to do once the basic structure is in place.”

“This is a starting point, rather than an end point,” he concluded.

Readers with good comprehension of processor micro-architecture terms are encouraged to read Henry's in-depth technical whitepaper on the Isaiah architecture, available for download here.


 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.



Comments are closed.