Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Politics : Formerly About Advanced Micro Devices -- Ignore unavailable to you. Want to Upgrade?

To: THE WATSONYOUTH who wrote (67112)	7/30/1999 11:28:00 PM
From: Elmer	Read Replies (1) \| Respond to of 1575535

Watsonyouth - you presented many perspectives and you may be right however you really don't make a case as to WHY you believe what you do. How about making a case for your position? EP

To: THE WATSONYOUTH who wrote (67112)	7/31/1999 12:02:00 AM
From: Dan3	Read Replies (1) \| Respond to of 1575535

Can coppermine and its supporting chipset run with anything but Rambus? If it's a simple switch back to SDRAM or DDRDRAM, then your point is very well taken. If not... Rambus is still listing binsplits for the 800 parts with part numbers for latency between 40 and 50 ns. SDRAM for delivery in the same time frame is running between 13 and 30 ns. SDRAM loses some of that advantage in bandwidth due to setup time, (I think its 10 ns, can someone correct this for me?) but it still leaves a delta of up to 27 ns. There was a lot of analysis I remember from 8 or 10 years ago when many systems were offered with or without cache. No cache - as was reprised in the early celerons - caused about a 35% performance hit. 8K cache caught about 85% of mem requests, 16K about 90%, 32K 95 - but then the hit rate for most code asymptotically approached 98% (this is all from memory - please correct the inevitable errors). Rambus with its 128 bit wide 100ns rams being fed through a 16 bit wide bus at 8x the speed of the back end devices isn't compelling as a performance solution. It's still reading from 100ns RAM and now there is the overhead associated with ordering the bits and pumping the data down the bus. But for a motherboard/CPU manufacturer like intel it radically reduces pin and board trace counts and so reduces costs. But you can only save so much money on a motherboard that retails for $75 to $200 including chipset and power components. And if your memory costs an extra $50, and your $700 processor now performs exactly like a $500 processor, you have a problem (If most of this is correct). If AMD can't pump out enough k7's to be a significant market presence, this doesn't matter. If lots of k7's come out at speeds equal to or greater than coppermine it's back to the motherboard and chipset drawing boards for intel.

To: THE WATSONYOUTH who wrote (67112)	7/31/1999 5:21:00 PM
From: Paul Engel	Respond to of 1575535

WatsonYouth - Re: "So a six month process capability difference between AMD and INTEL could negate it. I truly believe this thread under estimates the processing implications in this race. " You raise some very good points. One point you touched on (from a process standpoint) - but did not expand on - is the 256K on-chip L2 cache of the Coppermine. The added benefit of this cache - running at full CPU speed - 600/667/733 MHz - will give the Coppermine a needed performance enhancement above the AThlon - which uses off-chip L2 cache. Once AMD tries to ADD that L2 cache to the ATHLON chip, their die size will increase significantly - even at the 0.18 micron process - and their yields will take the inevitable AMD nosedive. Paul