Jeff, I appreciate your response, I'd like to pursue the subject a little. The funny thing about the pin argument, it's been around at least since the advent of so-called VLSI. I hate to date myself like this, but do you remember the original 8086 and the multiplexed address/data lines? To conserve pins in a DIP? In a similar time frame, Nick Trendenick, a principle architect of the 68k, argued against RISC in pin terms, from the technology perspective of that time, he figured you couldn't run memory fast enough through the limited number of pins on a package to feed the processor at the then-feasible clock rates of o(10 mhz) or so, so you may as well do microcode. It seems there's always a pin crisis on the horizon, and there's always some technical workaround being proposed, be it elegant or hack, and then the packaging guys come up with more pins. Jeez, what do the north bridge chips have, 500, 600 pins now? And they sell for $30 or so?
The problem I see with Rambus, it's got a 16 bit data path, versus 64 bits for conventional memory DIMMs, so it's got to run 4 times as fast just to break even. The Rambus solution looks elegant in principle, but in practice, as near as I can tell, it ends up being bleeding edge, which is why the launch has been such a fiasco.
On the specific issue of Rambus versus SDRAM-style DIMMs on PCs, what pin count are you talking about? Pins on the memory chip, I presume? I'm not even sure what the current mainstream SDRAM size is, but for, say, 256 mbit (= 32 megabyte) memory chips and 128 megabyte DIMMS, you need a 16 bit wide path out of the chip to fill the 64bit memory controller path. I assume this is what's currently done. That's the same as you need with Rambus. In the coming year, I figure 128mbyte DIMMS will be mainstream. Next generation, gigabit DRAM? I don't know enough to speculate on the alternatives, but I'm willing to bet there will be alternatives to Rambus that will work fine, one way or the other.
Conventional SDRAM +DDR, right now, looks to have a fairly clear path to 4x what PC100 DIMMS gave, that is, a crank up to 200mhz + the edge clocking deal for another 4x. 8 bytes wide x 200 mhz x 2 = 3200 mbytes/sec, broadly. The 800 mhz level Rambus solution, which seems to be close enough to the technology edge to have serious production problems, gives you 1600 mbytes/sec. Of course, PC200 DDR is not in production, yet, but the path is clear, and in terms of economically effective yields, it's not clear if PC800 DRDRAM is in production yet either.
Again, I'm not denying the validity of the pin count argument. But it's not clear if the more straightforward DDR SDRAM path isn't good enough, in the fashion of the x86 architecture or the internal combustion engine. Maybe Rambus memory will get the production kinks worked out in the playstation/embedded device market, and move up to the PC market from there, or maybe Intel will have its way and force the transition now. And yes, you can run multiple Rambus channels, ala the 840, and match the hypothetical PC200 DDR data rate. Just. I suppose you can crank the frequency too, but 800 seems bleeding edge as it is.
Again, Rambus may be the way to go for Playstation or various internet appliances and similar stuff where high integration is important. But that brings us to the contradiction of Intel pushing Rambus for Willy but leaving the high-integration path Timna for "conventional" SDRAM.
Shoot, I'd go on, but this is already way too long for the style of this thread. I would appreciate your thoughts on this, though. For others interested in the details, here's a semi-old article on how Rambus memory works, I'm really not an EE type, but reading this I was by turns impressed by the sophistication of the technology and aghast at the complexity. realworldtech.com
Cheers, Dan. |
