SI
SI
discoversearch

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
RMBS 88.13+1.1%Nov 21 3:59 PM EST

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Alan Bell who wrote (19487)4/29/1999 3:41:00 AM
From: Tenchusatsu  Read Replies (2) of 93625
 
Alan,

You bring up some very good points, and I'd like to reiterate them here.

<Given these tenuous assumptions, they seem to claim that the choice memory architecture is not very important for the current generation of systems but will become important for future generations as the difference in speed between the processor and memory increases.>

This is the key to RDRAM and the flaw in some of the criticisms of RDRAM. Many say that RDRAM isn't necessary, that latency is the real problem and not bandwidth, that PC100 SDRAM is all that's necessary. There could also be a few performance tests which show that in some situations, systems with RDRAM really do exhibit no real advantage over systems with PC100 SDRAM.

However, I can tell you for sure that RDRAM has a very real benefit for systems which tax the memory subsystem from multiple sources. On an Intel system, you'll have three masters competing for memory bandwidth:

1) Processor
2) AGP graphics card
3) PCI devices like hard disk controllers

As the memory traffic from all three sources increase with future generations (faster processors, faster graphics cards, more advanced PCI devices like network cards), traditional SDRAM will become less and less adequate to handle this load. RDRAM with its ability to keep many open pages and access them concurrently will be more efficient in handling this load.

And that also points to the flaw in the criticisms of RDRAM. The fact is, none of the critics have been able to point to a viable alternative. PC133 SDRAM is only a stop-gap solution, and it really doesn't address latency concerns at all. DDR SDRAM isn't going to be as efficient as RDRAM because even though it increases the peak bandwidth of SDRAM, it also inherits all of the inefficiencies of SDRAM. And of course, even though the critics love to point out the transitional difficulties with going to RDRAM (e.g. three-month Camino chipset delay), they forget that moving to any new DRAM technology will exhibit transitional difficulties.

<They mention the Alpha 21364 has a Rambus channel directly attached to the processor, thereby eliminating the chipset(memory controller) latency from the equation. (I wonder if Merced/MacKinley might use this technique.)>

Yes, this is true. The Alpha 21364 reduces memory latency by integrating an RDRAM controller inside the processor. (Well, actually, it's four RDRAM controllers working in parallel.) No, Merced doesn't do this. I won't comment on McKinley, but I will tell you that Intel is definitely moving towards integrating memory controllers into the processor.

You could integrate an SDRAM controller into a processor, but that requires a lot more pins than an RDRAM controller. This makes integrating an SDRAM controller very costly, and it won't even have the performance of RDRAM. You could also integrate a DDR SDRAM controller and get bandwidth which matches or exceeds RDRAM, but you still have a huge pin count. Let's just say that for the same number of pins, you can integrate four RDRAM controllers onto a processor and gain a tremendous amount of bandwidth.

I have reason to believe that most processor designers are going toward the integrated memory controller route because of the lowered latencies. And RDRAM's low pin count makes it ideal for integrated controllers.

Tenchusatsu
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext