EE Times: Does AMD have a new microarchitecture under way?

Phil Hester: It is always interesting to me what people call a new microarchitecture. What we typically do is keep the fundamental part of the core design for two or three generations. If you are just taking the base core and changing the memory controller, that is what I call a modification.

We are evolving to what I'd say are a minimum of two brand-new core design points, new microarchitectures from the ground up. One is aimed at mobile computers and the very low-power space. Another is optimized for the high-end server space. The question we have now is: Can you pull down the server space, or pull up the mobile, enough to cover the desktop?

Our belief is that we have to do an outstanding job on power management across the board. Techniques that applied mainly in the mobile side of things will now apply in the server and desktop space. Obviously, there are different cost or silicon budgets in notebooks than there are in the server space. So we will make these designs modular so that we can adjust the cache and the number of cores, based on what we know about the workloads.

EET: I would guess mobile is the bigger opportunity, yes?

Hester: Absolutely. The mobile microarchitecture could be pushed up to the desktop and down to what I believe in the next three to four years is going to be something that lives between your notebook and your PDA. That would be something that also works well in a set-top box or a digital TV. If you make it modular, you could come up with different design points to meet different costs: either a system limited to 1 watt of power consumption or the traditional notebook space. You would have the same basic microarchitecture, but with different caches or different bus widths to memory.

EET: When will those microarchitectures be ready?

Hester: It's an '07-'08 discussion for both of them — in that general range. We now have core groups of 10 to 20 people doing the high-level microarchitectures, supported by others who work on performance modeling or who work with the software community on compiler technology.

EET: How do you see the move to dual-core processors? It seems they arose in part because of power concerns and in part because the software vendors figured out how to do multiple threads.

Hester: It is different for servers and clients. On the server side, the parallel model has been around for 20 years. Just about every server has been based on a symmetric multiprocessor, and a dual core essentially is a two-way SMP on a chip. In the client space, people can typically find two active processes for most of the stuff that people do: virus protection or ripping an MP3 file while doing e-mail. You can find a couple of apps that can partition across two processors pretty well.

EET: How about beyond two cores?

Hester: We'll have quad-core architectures in the 2007 time frame. The challenge on the client side is the software, to see how fast that client software parallelizes. Outside of visualization, gaming and scientific apps, not a whole lot of programmers spend a lot of time worrying about parallel code. What goes beyond two cores? If you have enough silicon to do four processors with a pretty good cache structure, or three cores with an even better cache structure, which one of those is the right answer? The answer depends on what the client software will look like two or three years from now. What are the usage patterns going to look like on the desktop? That drives many of the design decisions.

One thing we do know is that software moves a lot slower than hardware.

There are something like 100 billion lines of X86 client code written — a huge number. So the thought that much of that is going to be rewritten and effectively tuned to run on five or six cores, I kind of step back and say that might not be such a good thing to assume.