Leading by design: Q&A with Dr. Raghuram Tupuri, AMD Chris Hall, DigiTimes.com, Taipei [Monday 12 December 2005]

Transcription

1 Leading by design: Q&A with Dr. Raghuram Tupuri, AMD Chris Hall, DigiTimes.com, Taipei [Monday 12 December 2005] AMD s drive to 64-bit processors surprised everyone with its speed, even as detractors commented that there would be little or no performance gain on the desktop without a 64-bit OS and 64-bit applications. Whatever the doubts within the industry, Intel lost little time in offering its own version of AMD64, in the form of the EM64T extensions. Traditionally perceived as the under-dog in the cutthroat world of microprocessors, AMD managed to take the design initiative at exactly that moment Intel was fixated on power consumption and the move to dual cores. In the terms of Intel s own corporate jargon, it was AMD that had managed to create an inflection point, a key moment of change in the dominant technology. DigiTimes.com recently had an opportunity to discuss AMD s approach to microprocessor design with Dr. Raghuram Tupuri, general manager, Microprocessor Solutions Sector Design Engineering, AMD. Q: The consensus within the industry is that AMD64 has clearly been a tremendous achievement for AMD and to a large extent has re-defined the competitive landscape in microprocessors. What was the design approach if you like, the design philosophy that guided development of AMD64? It s often been remarked, for example, that Dirk Meyer, who came to AMD from design work on the Alpha processor, had a considerable influence on AMD64. A: I worked very closely with Dirk Meyer on the K7/Athlon processor. We both worked on micro-architectural aspects of the K7. He s a very inspiring and hands-on type of leader, and that s the management style we have developed in all our microprocessor groups at AMD very hands-on, with good technical understanding. Dirk always says that he thinks of himself as an engineer at heart, and his background and experience definitely helped him develop his leadership style, walking around, talking with the engineers. He doesn t miss an opportunity to meet the engineering team and learn about their progress and challenges first hand. That style suits AMD s design strategy, which is to keep the design teams as small and as experienced as possible, to maximize communication. The key is to enable the team members with all the information they need, leaving them challenged and empowered to do more than their job. The core design philosophy is to deliver higher performance to the end user. As microarchitectural improvements are achieved, they are evaluated with respect to the end-user experience and future software needs. My own view is that we have not yet reached the limits of what can be achieved by micro-architectural changes and enhancements. As we progress in the technology, and more transistors continue to become available, we will continue to see the

2 adoption of advanced micro-architectural techniques. We will continue to see a lot more prefetch, in hardware, and a lot more speculative execution, but at the same time we will be factoring in power consumption. Delivering performance was always the focus for us. At AMD we have a history of emphasizing performance rather than processor frequency, but now, especially for our corporate users, the question becomes one of power efficiency, performance per dollar per watt. The design challenge now becomes, How much performance can I squeeze out of the wattage? At AMD, a microprocessor designer has to work within a power budget, and each application tends to have a different power profile. For example, if you are converting a DVD video, then you are using one section of the processor core quite heavily, but if you are simply typing an , it becomes more a question of I/O resources. That s the type of question being asked in processor design. What application or set of applications are we targeting, and what is the power profile? Users buy new processors because they want to have more performance, and higher performance is definitely on the horizon, but it has to be delivered within certain power constraints. Previously we operated within a transistor budget. We had a certain number of transistors available, and within that budget we had to improve performance. The die size was always limited, both by economic factors and by the limitations of the technology of the time. We now have more transistors, but certain strings are attached. We now have to improve performance within a power budget. Q: Commentators have noted that what s fascinating about the AMD64 architecture is how it maintains full compatibility with the much-maligned x86 architecture while also delivering a RISC operational and programming environment. How accurate is this assessment? A: There always was tendency at AMD to assume that we could put x86 on top of RISC. I remember when we were working on the 29K RISC processor, we always thought that, with some additional hardware, we could put x86 on top of the RISC core and execute CISC instructions. Once we knew we could implement that kind of design, it was incorporated in several products, including the K7, K6, and K5 and, of course, the Opteron. AMD had had RISC technology for a long time. Its 29K microprocessors were popular in embedded applications. Later, when these 29K engineers moved to x84 processor design, the result was CISC designers who have RISC at heart! Q: How much more mileage is left in x86? Are there any realistic alternatives, given the less than compelling performance of Intel's IA-64 architecture and Itanium processors? A: I would be surprised if, a few years down, anyone even remembers the Itanium processor. Intel now offers two 64-bit solutions, IA-64 and AMD64. I think that tells you all you need to know about the success of x84 and AMD64.

3 I think there is still quite a bit of mileage left in x86, but the actual mileage will be determined by the software base. If I m a software vendor, what I want to focus on is developing new software and selling it to more end users. If the software needs to be ported to different processor platforms, then it is time or money deducted from the development of new algorithms or the improvement of existing programs. Given the ubiquity of x86, you only need to develop a set of binaries once, and they can then be applied in any number of instances. The processors now known as x86 first began life as desktop processors. Now they are being used in both servers and laptops. AMD64 is now enabling x86 in the server market in a big way. In the near future, we expect AMD64 processors to be used in network switches. Already, they are being used in embedded applications, and later they will be used across the complete computing spectrum. I believe x86 is here to stay, whether you love it or hate it. Whatever criticisms have been leveled at x86, it remains the longest surviving instruction set. No other instruction set has had this long a lifetime. Other instruction sets have come and gone, but x86 lives on. A technologist may not like x86; it may not be the sleek instruction set everyone would like to see, but in the end, it s the end users who determine which technology will be used. The marketplace determines the acceptance of a particular instruction set. In terms of software development, for example, the portability is already there. You take the binary and plug it in, and it runs the same day; you don t need to do any qualification. If you use any other instruction set and any other porting, then you have to go through all the qualification cycles, and that s a very expensive option. In the corporate world, it s simply not possible. Q: Given the complexity of processors such as the K7 and the K8, and the need to get these devices to market under ever more severe time constraints, what are the test techniques that are either being implemented by AMD? We hear a lot these days about design for test (DFT). Is DFT a key strategy for AMD? A: It so happens, my first job at AMD was to look at the implementation of DFT strategies on AMD microprocessors and coordinate DFT activities across the company. AMD designers were already using several DFT techniques SCAN, for example and we were looking at the longterm strategy for our DFT techniques. The question was how various test technologies might be unified, and how they might scale to future technologies. IDDQ testing, Built-in Self-Test (BIST) and automatic test pattern generation (ATPG) tools were becoming popular. At that time, I was working very closely with a few startup ATPG vendors on a variety of issues and solutions, and the direction AMD wanted to go in. Later, these startups were acquired by big CAD companies. Every AMD chip now incorporates DFT and BIST technology, and we use this combination very heavily. Q: What design tools are you now using at AMD? Has AMD developed its own EDA tools or does the company rely on standard commercial offerings or a combination of the two?

4 A: AMD always uses a mix of in-house and external tools. If you look at microprocessor development, we are pushing the envelope in all directions. In general, the semiconductor industry runs somewhere between three to five years behind microprocessor technology. So whatever tools are commercially available we use, but when it comes to pushing the latest technology, we start to use our own internal tool development. We have a team that looks into new design issues that require in-house tool development. But once external tools come into the picture, in exactly the same way we worked with ATPG tool vendors in the past, we work with them to define and incorporate the features we want, and then once the tool is available, we start phasing out our own internal tools and go with the external tool. An example would be signal-noise analysis. We ve been doing our own signal-noise analysis since the K7 days. It s only in the past two or three years that external tools have become available. Q: In what direction should test go? What new developments would you like to see in test? A: There are two issues here. For the production environment itself, I would like to see more and more self-test being used, and that includes more reliable self-test procedures. Research is ongoing, at 45 nanometers and below, and that is where the research community should be focusing its efforts in the development of self-test. On the tool side, I think there should also be more emphasis on a diagnostic capability because as we move further and further into deep submicron, process failures are becoming much more complex. Test compression will be a key factor. Test time is becoming expensive, and test compression reduces cost. That reduced cost can then be passed on to the end user. Raghuram Tupuri, Ph.D, general manager, Microprocessor Solutions Sector Design Engineering, AMD Q: One criticism commonly made of dual- and multicore processor designs is the lack of efficient inter-connecting logic. What are your comments?

5 A: Let s look at it from the micro-architectural side. Let s say you re trying to enhance core performance. As you do that, you need to supply instructions and get data in and out. If we don t focus on supplying instructions, then we are just creating a bottleneck. So when we were thinking about the design of the Opteron, we asked, OK, we are making our core much more powerful, but how are we getting the instructions into it? Are we going to use the same old front-side bus? We were also considering what direction design might take in the future because whenever you are making major design changes of this kind, you need to keep the platform as stable as possible for end users. You can t keep changing and re-designing things. So the question also became, how can we do this not just for the next generation of processors but think beyond that? In this process, it became evident that we had to have an interface to external memory that could support not only the single-core Opteron but also dual-and multicore versions of the Opteron. We realized that dual- and multicore processor design was the direction in which things would go. AMD had predicted that the future would be multi-core and presented the direction to the technical community. We could see that the conventional interface to the CPU, via Northbridge logic, via the I/O and peripherals, is always a bottleneck. The interface involves a drop in frequency from gigahertz to megahertz, before the processor can interface with main memory. HyperTransport, as a direct interface between the processor core and main memory, was devised to remedy that. It adopted a Direct Connect Architecture that provides a direct interface between the processor core and memory. HyperTransport is a generic bus, and not simply a memory interface. We can also use HyperTransport to connect processors. All of our high-end processors come with multiple HyperTransport links, and multiple processors can be connected this way. HyperTransport is very forward-looking and designed with dual-core processors in mind. That s why, when you look at dual-core today, it is a built-from-the-ground-up architecture and delivers seamless performance. HyperTransport is also an open architecture. We have a HyperTransport consortium, and of course AMD is a founding member. AMD believes in open standards. Open standards, we believe, drive competition, and competition benefits the end customer. So when AMD came up with AMD64, we immediately made that an open, public specification, and we said to companies, Feel free to use it! We believe in competition! Q: Does HyperTransport continue to develop? Can we expect a further generation of HyperTransport? A: I would think so because all the companies within the consortium are asking, What can we do to improve it? It s as a consortium that companies are continuing to develop

6 HyperTransport, and people are bringing their ideas to it. It s like Linux; everyone is helping to develop and improve it. Q: How well do you think HyperTransport will continue to compete with other interconnects, such as PCI Express and Rapid I/O? A: I believe in the market. I think the market will decide. We ve already seen that with x86; everybody thought x86 was dead, but it is continuing on and becoming stronger and stronger. It will be the same thing with interconnect standards. You will see a lot of proposals for interconnects, but eventually you ll also see consolidation. Proliferation is always followed by consolidation. Initially, architectural design teams will always focus on performance. Then they ask, How can we enhance performance by making use of these additional interconnect standards that are becoming available with next-generation technology? At the same time, architectural techniques have to improve single-core performance; you cannot focus only on multicores. Performance derives from both because in a glueless architecture, such as that of the Opteron, the effect of improvements in a single core will be multiplied in multicore designs. Power consumption also needs to be factored in. Test requirements need to be factored in. Power, test, verification everything needs to be factored in. We can design it, but can we test it? Can we verify it and still remain within our power budget? These are all crucial questions for the designer. Q: With the Opteron processor, the way seems clear for advanced SMP configurations. What success has AMD had in achieving entry to the advanced server market with this type of configuration, bearing in mind that corporate MIS departments are naturally conservative? A: I think the quarterly results speak for themselves. As you noted, it does take a long time to become established in the server market. When we ask what is the decision-making process when, say, enterprise-level companies consider whether to invest in eight-way Opteron systems, I think there is only one metric, price performance per watt per dollar. If you look at that metric, the AMD solution is clearly the winning solution. Of course, architectural change is a long-term thing. Can we replace single cores with dual cores and still get enhanced performance within the same power budget? That kind of easy migration and upgrade path, is it there? AMD has a good roadmap, and I think that MIS managers clearly understand that. That s why we have leading customers in the Fortune 500 companies, and that list is growing. Q: We often hear the comment that there is no point in investing in 64-bit processor configurations before more applications become available at 64-bit; that without 64-bit apps there will be no performance gain. What is your response to that dilemma?

7 A: As a designer, whenever I hear Opteron discussed only in the context of 64-bit, that hurts me because Opteron is much more than 64-bit. It has so many performance advantages that even if I don t run a single 64-bit application, I m still getting full dollar value for Opteron. The Opteron seamlessly delivers performance for 32-bit applications. It has built-in micro-architectural enhancements that optimize performance, whether at 32- or 64-bit. I would also ask what is the direction of technology migration? If it s to 64-bit, am I going to immediately replace my hardware or use separate hardware for 64-bit programs? The answer is no. With Opteron, one can take advantage of its performance for 32-bit today and then adopt 64-bit applications whenever they come along at a later date. If you are into gaming and multimedia in particular, you will see a lot of 64-bit applications becoming available. But even if you use a PC just for Web browsing, you ll still see benefits because with Opteron you now have your memory a lot closer to the CPU. You also have additional security features. DigiTimes Publication. All rights reserved.