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: Tenchusatsu who wrote (33046)	10/27/1999 12:46:00 PM
From: unclewest	Respond to of 93625

borrowed from the intel thread.. Thread - Another Cumine 733 / i820 review vs. Athlon 700 review gamespot.com Excerpt: <Coppermine outpaced the Athlon in the 16-bit GameGauge scores across the board. Some of the differences may be attributable to the more efficient throughput of the Coppermine/Camino combination. The faster L2 cache may have also played a small role, but games tend to be less cache-dependent than other applications. Finally, some of the differences were no doubt due to the roughly 5 percent clock rate difference. Still, all of it indicates the Athlon core may not be that much better than the Pentium III, as previously thought. The 32-bit game scores were somewhat inconclusive, with the Pentium III showing small, but not statistically significant, differences. What seems to have happened is that Intel has come from behind and achieved parity with AMD. This is no doubt a relief to Intel, but it's still very significant that Athlon can stand up to Intel's latest and greatest and hold its own. Once AMD shrinks Athlon to 0.18 micron, AMD may once again have the opportunity to pull ahead. As before, AMD's biggest Achilles' heel continues to be the motherboard and core-logic chipset problems. I would have liked to run the AMD tests on a shipping off-the-shelf motherboard, but neither the FIC or Asus motherboards could complete all the benchmark tests. The Camino-based system, despite its beta nature, has been rock solid, even with the supposed RAMBUS problems (of course, we were only using two RDRAM sockets, not all three). So stability is still Intel's strong suit - and it's not a trivial one by any means. If I were a large OEM looking to minimize support calls, I'd look long and hard before choosing an Athlon solution.

To: Tenchusatsu who wrote (33046)	11/2/1999 6:18:00 AM
From: Bilow	Read Replies (2) \| Respond to of 93625

Hi Tenchusatsu; Revisting the pin requirements of SDRAM versus RDRAM... Intel does not have data sheets on its web site for the new 840 parts, but they have package pin counts for the parts. This allows us some small comparison of RDRAM and SDRAM interface counts. I would like to include powers and grounds, but I just don't have the data sheets to compare to. Anyway, you wrote: "Try grafting dual DDR channels onto the north bridge. It's possible, if you don't mind the 200 extra pins or so." This assumes that an SDRAM channel must use about 100 pins more than an RDRAM channel. I would like to examine this assumption in more detail. There are two Intel parts that connect to the Rambus channel but are not memory. Instead, the 82803 splits a Rambus channel into two Rambus channels, thereby doubling the amount of memory that can be addressed by the original channel. The 82804, on the other hand, takes a single Rambus channel, and turns it into a single SDRAM channel. Just looking at the pin counts, you would suppose that since a single RDRAM channel uses less than half the pins of a single SDRAM channel, then the 82803 would require fewer pins than the 82804. That is, both chips have an incoming Rambus channel. The 82803 has two outgoing Rambus channels, while the 82804 has only a single outgoing SDRAM channel. But the fact is that the 82803 is in a 324 pin package, which is *larger* than the 241 pin package that the 82804 is in. This suggests that the actual pin count ratio between the two interfaces (counting all the power, ground, termination voltages, etc., is below 2 to 1. I wish I had the specs. I know the following calculation is faulty, but I am going to include it anyway. Hopefully, when Intel releases the specs on the 840 series chips, we can understand what is going on: <<<Begin Erroneous calculation:>>> 82803 has 3 * Rambus channels, and 324 pins. So each Rambus channel uses about 108 pins. The 82804 has one Rambus channel and one SDRAM channel, with a total of 241 pins. If the Rambus channel takes 108, the total needed by the SDRAM would be 133. Therefore, the ratio of pin count between SDRAM and RDRAM channels is around 5 to 4. Therefore, the actual pincount savings for RDRAM over SDRAM is only 20% of the memory pins, or around 25 pins per channel. <<<End erroneous calculation...>>> Now some possible explanations for why SDRAM is showing fewer pins than expected, compared to RDRAM: (0) The SDRAM RIMM module actually has more pins than the number needed to drive it. That is because some of the signals are tied to VCC or GND, and others are tied together. But this doesn't apply to the RDRAM bus, which actually needs all of its pins. (1) Pin rounding. The 82804 just barely fits in a 241, while the 82803 has to get bumped to the next standard package. This is quite possible. (2) I/O bound silicon. The Rambus chip requires particularly large or wide I/O pads, and consequently, the 82803 is more I/O bound than its pin count would suggest. The part is thus forced into a larger package (that happens to have more pins) because of the resulting die size. This would be suggested by a large number of NC among the 82803 pins. Unfortunately, I haven't seen the data sheets yet. (3) The 82803 has a much larger number of power and ground pins. This could be due to its extraordinarily high output currents. The 2 outgoing channels each have something like 3 amps peak current total, while the incoming channel has something like 1.8 amps. This gives a total peak output current of 7.8 amps, and therefore ground bounce is fattening the pin count requirement. In addition, the low signal levels might increase the sensitivity to ground bounce, relative to standard CMOS signaling levels. Any more ideas? -- Carl