To: Scumbria who wrote (91724 ) 2/5/2000 6:09:00 PM From: Ali Chen Read Replies (1) | Respond to of 1575814
Scumbria, <..having the CPU core do different tasks at different clock speeds, it is hard to say what the clock speed of the part is. Willamette will create some controversy in that regard.> The situation is indeed interesting, and not very good for AMD. Historically, the 386 CPUs had input clock at DOUBLE frequency, 50 or 66MHz, to provide accurate phases for internals and bus protocol. However, the processors were rated at 33MHz (AMD made it to 40MHz). On the other hand, Motorola tried a trick with dual-pumped clocking on 68000 family as I vaguely remember, but it was not accepted in the marketplace as "true" speed measure. The dual-pupming controversy changed since 486 were introduced, with internal PLL to do this clock "doubling" job. The core still was rated as 33MHz, until "true" core "doublers" were introduced, 486DX2 (core=66MHz), and later "triplers" 486DX4 (core=100MHz). And quads... Now the Willy claims to achieve 1.2-1.4 GHz at the inroduction, on 0.18um process. This is on the same process where Intel can barely yield the 650MHz (center of distribution) on the standard 12-14-stage pipeline of the classic P6 core. I am having hard time to believe that the pipeline can be made much deeper without strongly degrading the overall CPU performance on current workloads. At the same time I have hard time to believe that the logic complexity can be significantly reduced for all these prefetches, predecodes, decodes, more decodes, and dispatching results to multiple execution units. I think AMD has done their job with Athlons already, so there is little or no room for further simplifications in the inter-stage combinatorial logic. Therefore the only open possibility is to design the decode-dispatch pipeline with some sort of frequency cheating like dual-pumped input clock, and claim that this is the true core working frequency, for obvious marketing reasons. The approach to perform decodes-dispatches at high rate, and execute commands at somewhat slower rate, 1/2 or 1/4, may make some sense if it shifts complexity away from the decode pipeline, and I think AMD may take this idea into the Sleighammer project. However this approach may have some difficulties, presumably in overall performance. It must be a blunt lie that the current Willy is A-0 silicon. I remember some Usenet reports that Intel was running something in their labs at 1.2GHz a year ago. Now I suspect that those were pre-Willys, and I am sure Intel can afford several pre-tapeouts, especially if the project was due in 1997 :) So, AMD should be very aware of the "megaherz sell" concept, and do something to counter the fake Willy's MHz. Take care, - Ali