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: gnuman who wrote (72462)	5/10/2001 12:50:38 AM
From: Jim McMannis	Respond to of 93625

Gene, RE:"You realize, of course, there are a bunch of Rambus design engineers laughing their arses off over this series of posts. <VBG>" Not to mention... "perhaps" a bunch or shareholders getting ready to sue Rambus...as in "We took your word and bought your stock only to find out you commited fraud"... Jim

To: gnuman who wrote (72462)	5/10/2001 2:23:51 AM
From: Bilow	Respond to of 93625

Hi Gene Parrott; I think I'm beginning to smell a rat here. I'm beginning to suspect that the 64Mbit RDRAM chips were speced to have a wider output compliance than the current chips, and consequently some performance has been dropped off the back of the bus. This would have been due to the Camino fiasco. My suspicion is that the Rambus 95% efficiency numbers date to a time that Rambus was using the 3rd step. To avoid a read to read delay when switching between a close RDRAM chip to a far one, you have to put up with the 3rd step, it is inherent to the physics of the situation. I think I can support this if I can just find a specification for the output compliance of the RSL current sources. One of the funny details is that I can no longer find any spec sheets for 64Mbit RDRAM chips on the web. They're no longer at the websites of the memory makers, only the 128 and 256Mbit parts remain. This is kind of odd because normally memory makers keep old data sheets around for people to read who have problems with legacy designs. Or maybe it's just time for me to go to bed. But as far as the your questions go... Re: "I need to understand the electrical length of the bus" The total length of a fully populated 2-RIMM RSL bus, with two 16-RDRAM RIMMs installed is in excess of 4ns. That is, the far memory takes around 4ns for its signals to reach the controller, and another 4ns for the reflection to reach the termination resistor. Since a single bit takes 1.25ns, this means that a whole lot of bits are simultaneously on the bus. My proof that there has to be a 3rd step on the bus assumes that Rambus is able to pass the baton from a read of one RDRAM chip to a read of another without a gap in the data received by the controller. This is what is referred to as a "tristate delay", the length of time that one output must turn off before the other output turns on. This was originally a design goal of Rambus for Direct RDRAM: Proof that the Rambus protocol has no delay between reads of different RDRAM chips (or at least did not back in the days of the 3-RIMM RSL channel (snicker): Rambus Technology Basics Billy Garrett, Rambus Inc. ... Current mode interface allows minimum turnaround and "tristate delay" ... Open drain drivers in current source mode Rambus signalling levels: 1.8V - 1.0V ... High impedance buffer ignores wave-front and allows wave to pass through to termination www.ece.utexas.edu/~kettler/Rambus1.pdf Rambus Technology Basics Billy Garrett, Rambus Inc. ... Why the protocol is efficient ... Eliminates read-to-read tristate delays ... www.ece.utexas.edu/~kettler/Rambus2.pdf My step diagram shows the inevitable consequence of eliminating the read to read tristate delay, that is, the 3rd step. But again, why is it that I snagged the above link off of an obscure texas university website instead of the Rambus site? Partly it's because I find Rambus distasteful, and don't like spending time at their site, (though they have very good servers), but maybe it's because old documents (with obsolete promises long broken) are no longer there. -- Carl