The Battle in 64 bit Land, 2003 and Beyond

Pages: 1 2 3 4 5 6 7 8 9 10

SGI MIPS and PA-RISC: Running out the Clock

Although shrinking in size in recent years, the customer base of MIPS and PA-RISC, the house brand RISC architectures of SGI and HP respectively, are still economically important to these companies. That is why they continue to develop and introduce new RISC products even though both companies are committed to migrating their users to IA64. Imposing major architectural change on customers is a dangerous activity for any computer vendor. Such changes are expensive and disruptive for customers and are natural opportunities for customers to change vendors, especially if the reason for the change is unconvincing. The safest tactic is to offer an overlap period extending for at least several years during which the vendor offers products based both the old and the new architecture.

The problem with a dual track approach is that designing a competitive new high end processor is quite expensive and time consuming. The solution both HP and SGI employ comes straight from the environmental movement – reduce, re-use, and recycle. That is, they recycle their existing CPU core design by porting it to a more advanced process to reduce the feature size, and re-use system infrastructure (buses, chipsets etc). Refreshing an old design with a process shrink provides higher clock rate and larger on-chip cache even while shrinking die size, power, and cost. While staying with a tried and true design saves the time and resources needed to create and verify a new microarchitecture it is still a costly and time consuming exercise to bring out a new MPU. Sections of circuitry often need to be redesigned for performance or sometimes just to function reliably and the physical design and pre and post silicon verification tasks are essentially the same.

In the case of SGI, it is has been recycling the MIPS R10000 (R10k) quad issue, out-of-order execution processor core for half a decade. Although the processor gets renamed with each shrink (R12k, R14k, and R16k) the microarchitecture is largely unchanged from the original design. Although SGI has hinted that the future R18k device on its road map will represent a significant improvement, reports indicate it will still heavily leverage the R10k. The primary differences are the FP hardware will be changed from one multiply and one add pipeline to two multiply-add pipelines (thus doubling the chip’s peak GFLOP rating) and the system bus is improved [10]. Given the huge performance gulf between its MIPS-based products and its new Itanium 2 based product line it is hard to imagine SGI seriously contemplating MIPS development beyond the R18k. But SGI’s questionable plans for MIPS must be distinguished from an independent and highly successful market for 32 and 64 bit MIPS architecture processors in embedded control type applications, a topic out of the scope of this article

In the case of PA-RISC, it is even more obvious that HP is simply running out the clock. The company hasn’t introduced a new CPU core since the PA-8000 which is about as old as the MIPS R10k. Instead, HP simply shrinks the PA-8000 core and fills up the available space with increasingly large L1 instruction and data cache as feature size shrinks. The next PA-RISC on HP’s road map is slightly more interesting, the PA-8800 “Mako”. It consists of two PA-8000 style cores on one device. This decision forced HP to cut the data cache capacity per processor in half compared to the PA-8700 despite the smaller feature size (0.13 mm vs 0.18 mm). To help make up for the smaller data cache and the growing gap between processor and memory performance, the Mako will be packaged in an MCM with 32 MB of DRAM-based L2 cache [11]. Despite its high capacity, the very high latency (40 CPU cycles) of the L2 in combination with a modest processor clock frequency target (1 GHz) for PA-8800 will severely limit improvement in uniprocessor performance over the PA-8700. The purpose of PA-8800 seems to be to allow HP to double the number of CPUs in its Superdome large scale server without a major physical redesign.

Pages: « Prev   1 2 3 4 5 6 7 8 9 10   Next »

Discuss (86 comments)