Home  |  News  |  Reviews  | About Search :  HardWare.fr 



MiscellaneousStorageGraphics CardsMotherboardsProcessors
Advertise on BeHardware.com
Review index:
Interview with AMD's CTO Mark Papermaster: SoC? x86?
by Damien Triolet
Published on August 13, 2012



At the beginning of June, during Computex, we had the opportunity of interviewing Mark Papermaster, who took up the post of Chief Technology Officer at AMD at the end of 2011. After a long career at IBM followed by shorter passages at Cisco and Apple, Mark Papermaster is now focussing on remodelling AMD’s development strategies and methodologies from top to bottom so as to establish the company on a more competitive footing.

Mark Papermaster isn’t overseeing the detail of GPU and CPU architectures directly, though he does have the job of making sure that the developments correspond to the overall AMD strategy. His principal task is to take the current AMD development methodologies and move them towards an SoC (System on a Chip) approach, so as to give more modularity and flexibility. This move should enable AMD on the one hand to roll out its mainstream products at lower cost and with more responsiveness and on the other to attack more specific markets with the option of responding to very precise customisation demands that certain customers might have.


We therefore asked Mark Papermaster about this development and its implications, without forgetting to cover other subjects such as the possible use of instruction sets other than x86. Here’s the transcript of this discussion, including comments from Chris Hook, head of corporate communications at AMD:


What's AMD's no.1 asset? What's your most interesting piece of IP for future SoC?

Mark Papermaster: No surprises, you saw it today with the Trinity rollout. We will continue a very intense focus on every generation improving our graphics, both graphics and compute, our multimedia capabilities and, along with that, our CPU capabilities. Then with the SoC approach we're doing, we can to make it easier to tie in other elements. It could be third party, could be ones we have developed. Imagine a specialized IP block around which our capabilities will grow, but the rest of the core, the real foundation, is the APU. The APU is a point of differentiation, every generation we're gonna increase capability substantially so that we have a differentiated solution at AMD.

The point I'm making to you about the change in the SoC is that if we just did that it wouldn't be enough. If we just relied on the CPU and GPU we would lack the flexibility we need to give us the force to react to the market going forward. So the APU is the foundation on which we're building with capabilities that we bring with our SoC methodology.



What are or were the main challenges in moving to an SoC design methodology?

MP: The trick is that it's a different methodology because, to design a true SoC, you have to take your IP and modify that design so it can be easily connected with other IPs. We're not just talking the CPU and GPU: it's all of the multimedia, the memory function, it's architecting in a standardized way how these can be interconnected. We rearchitected the direction in which we're going. So you ask: "Well Mark where's the difficulty?" The challenge is actually just making sure you're thoughtful about how you do the implementation.

So for instance you're changing the way that you're bringing your products together, the protocols which you're going to use to connect everything with. If I were to do all of this immediately for next year it could potentially bring disruption to our development schedule, which we don't want. Our customers expect our products at each customer cycle so we wouldn't do it that way. We're going to do this in a thoughtful way in terms of architecting and staging how this could be implemented. So at first it should include us doing some things to increase our development productivity and some of our flexibility, but we'll see this change to the SoC over 2 to 3 years in terms of implementation. There is a different way of developing the IPs so as to standardize how you interconnect them. The guts of the IPs don't change. The value we have as to how we design our CPU core families and move that forward, our graphics engines… that's not changing, that roadmap continues. It's about the protocols, how that interconnects and how you've architected that gives you the flexibility to put them together in different combinations in a very agile way and a much more efficient way.


What's the main advantage? Faster time to market with derivative products?

MP: More than faster time to market, it's the flexibility of how the IPs are put together. You know today if I want different combinations of IP, each one is more of a custom effort. If I take an APU and I want a different combination of CPU, GPU... and I might have a third party IP block that I want to add in, multiple third party IP blocks... That today in our methodology has been a customized effort. We've had work that we've done for embedded applications which are of that nature, we've put hundreds of engineers on it!

Where we're going with a more flexible SoC approach is not just about efficiency, it's actually enabling us to do those kind of things. We might have partners that want to have a differentiated product and they might need a unique accelerator or a unique combination of IPs. Before, that type of contract would have required an investment of hundreds of engineers, now with a small team we can work and do deeper partnerships with those customers. So it actually expends our opportunities.


These derivative products need to be manufactured and tested and this takes time as well. Doesn't that limit your possibilities?

MP: Of course, for each modified design. A fab cycle is typically 3 months, that's the fabrication cycle. Imagine Sony had a TV, a smart TV, and they came and said "I like AMD products... I have a huge volume opportunity... I like what you have on this standard SoC but we have some unique requirements". It's a derivative design. Today that derivative design could take many many engineers. With this more modular approach, yes you have a unique fab cycle, manufacturing and testing, but the design phase is very short.


Have you already benefited from this approach with current products?

MP: Llano 2 is a derivative design. So we very quickly modified from Llano, changed the content because it was optimized for a different market. We changed the number of CPU, graphics cores and because we weren't fully modular at that time, the design cycle was some months. It's shorter than a whole new APU but we did leverage modularity and we shortened it. With the approach I described we'll shorten that even further. But Llano to Llano 2 is an excellent example of modularity. We did that with many less resources, so imagine if we took that a whole other step forward. That's what we're doing.

Chris Hook: It was a much smaller budget to execute for Llano

MP: A fraction, a fraction

CH: What people don't understand, it's not 5 or 10%, it's a fraction. You're not saving a little bit, you're saving a lot.

MP: It's a big change, it's a big deal. Our customers get it.


Do you have a concrete example of such a personalized product that you can tell us about?

MP: What happens when you really leverage that modularity for deep partnership with someone is that... you actually won't hear about it. It won't be the silicon component that will be marketed, it's the end product capability. It might be a performance speedup or a product feature because it's done in partnership with that end customer. So the question you have is "Are we announcing new products this time?" No.

We are clear on this direction, we've got lot of interest from customers, lots of activity going on but none that reaches toward direct marketing by customers and will be public. So it's not something we can share. But I can tell you we have a lot of interest in this approach.


What's the tradeoff with this new design methodology? The last bit of performance or the last hundreds of MHz?

MP: Potentially… but I don't think so because it's more efficient if we come to market faster. You're right there's a few percent of that optimization and customization that with a modular approach you may give up. But when you go to market faster, frankly, every month to market is equal to performance. So at the end of the day I don't believe we have sacrificed anything.

CH: It would also be fair to say that we can maybe introduce sometime a little more risk. What I mean is a more aggressive schedule; because when you have the option of falling back on a previous generation component, you can give an aggressive schedule for a newer piece.

Let's say your new CPU core is one year late, could you move back to the older core and still benefit from a newer GPU?

MP: You could do that, I mean I don’t intend to ever have one of my CPU cores coming a year late! But yes you could.

We've seen that kind of delay in the past…

MP: Today, we drive our key IP blocks to a very tight schedule so that's very unlikely. But you might have a smaller block, a specialized block that's pushing on some new capabilities, not like a CPU and a GPU core but smaller, it might be late and you just go with the previous one. Maybe it's some subset of a multimedia or audio block, something like that. You're right we'll have that flexibility.


There's a lot of talk about x86 and AMD's future. On one hand, x86 is a kind of rent for AMD, but on the other it could make it difficult to enter new markets. What's your take on this?

MP: My take is that x86 is obviously a phenomenally successful architecture and it will be, you know, as far as the eye can see. So we will continue with all of our investment in x86. But what I'll also say is we're a different AMD, we're an AMD that's gonna be able to react very quickly. So that SoC approach, that SoC methodology I described to you, is very flexible. It's flexible such that if a customer says "I like everything you're doing, I like x86, but I have a unique application here that due to some ecosystem or software requirement needs a different instruction set architecture", we could support that.

We are heavily investing in x86, it's a real gem among our IPs, like our GPU and graphics technology, but the flexible approach I described going forward will ensure that we won't leave any market behind, including a different ISA. If that was a strong customer demand then we would fulfill it.


Are you allowed to enter the handheld SoC market and compete with Qualcomm to whom you sold the Imageon division a couple of years ago?

MP: We're not restricted in any market by anyone. I mean we can compete where we see market opportunities across the spectrum.






Autre articles dans le même thême
AMD A10-5800K and A8-5600K: the second desktop APU! AMD FX-8350 review: is AMD back? IDF: Interview with Intel's Mark Bohr Intel Core i3-3110M Ivy Bridge versus i3-2370M Sandy Bridge
AMD A10-5800K and A8-5600K: the second desktop APU! AMD FX-8350 review: is AMD back? IDF: Interview with Intel's Mark Bohr Intel Core i3-3110M Ivy Bridge versus i3-2370M Sandy Bridge

Copyright © 1997- Hardware.fr SARL. All rights reserved.
Read our privacy guidelines.