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.

Technology Stocks : Rambus (RMBS) - Eagle or Penguin -- Ignore unavailable to you. Want to Upgrade?

To: grok who wrote (31886)	10/9/1999 6:48:00 PM
From: TST	Respond to of 93625

Right KZ, then I did understand you. Again, I say thanks & great fun to you on your retirement & lots of luck. Take care.

To: grok who wrote (31886)	10/9/1999 10:02:00 PM
From: Tenchusatsu	Read Replies (2) \| Respond to of 93625

KZ, <The flip side of the advantage of granularity and pin saving is that Rambus reads 16 bytes of data inside an Rdram and then ships them out at very high speed over a narrow, two byte interface to the chip set which then expands them back to 8 bytes and ships them over to the Microprocessor.> Of all the arguments you have against Rambus, this is one that really ought to be dropped. Following your line of reasoning, the CPU bus really ought to be 256 bits wide instead of 64-bit, because the L2 cache is accessed 32 bytes (256 bits) at a time. Why squeeze 256 bits onto a 64-bit bus? Or, what if there was a CPU out there whose bus interface is only 16 bits wide, just like Rambus? Would your attitude on Rambus change? I suspect not. Or how about CPU buses which are 128 bits wide? Would that mean that SDRAM no longer makes any sense, because it is only 64-bit? Yeah, right. The point is that the CPU bus interface is independent of the memory interface. Who cares whether the CPU bus is 64-bit, or any other size for that matter, as long as the memory subsystem has enough bandwidth to feed it? Tenchusatsu