Will Rambus Go Bust?

retep writes: "32BitsOnline has a interesting article about how the new memory standard RAMBUS may go bust. Essentially a bunch of missteps with Intel's Camino chipset, high costs, the rise in popularity of alternative CPU's such as the Athlon and a lack of performance may prove its undoing. I remember a story in Wired just a year or two ago praising RAMBUS for its innovative tactics; look what's happened now."

Comments

The problem with Rambus compared to SDRAM...

[Telcontar]

is a higher latency. This means the CPU has to wait longer until the memory is read, but can read memory faster from then on.
The consequence of this is that compilers would have to be optimized for that kind of memory access - i. e. accessing a few pages is expensive (and slow) under Rambus, slower than under SDRAM. Accessing many pages is more effective.
The question is, why did Intel chose this kind of tradeoff? Was there no alternative that did not increase the latency by the factor of 10 (according to the link to Tom's hardware)?

Re:The problem with Rambus compared to SDRAM...

[overshoot]

the idea is that boosting frequency down the line (for RDRAMs) will be easier than adding more lines to SDRAM, or trying to boost SDRAM frequency (due to its more parallel nature).

DDR-SDRAM is actually less parallel than Rambus. DDR has a strobe (clock) line for each eight data lines, where Rambus uses a common clock for sixteen. DDR-II also moves to a dedicated differential strobe. The result is that the skew within byte lanes (the main limit on the transfer rate for source-synchronous signaling schemes) is lower and therefore the data rate can be higher.

In contrast, Rambus tries to keep the clock rate low by doing four transfers per clock cycle. Since the data has a frequency half of the transfer rate, more width, and is single-ended, there's really no engineering advantage to the 4x multiplier. There is a honking great cost, though, since it requires the devices to oversample the data in between clock edges. This leads to more jitter (sampling-point variability) and makes the Rambus interface (RAC) very complex and expensive. The primarily-analog circuitry in the RAC is one of the main reasons that RDRAMS have such hideously low yield -- it's just ugly getting all of those comparators and timing paths to match up in a cost-means-everything DRAM process which is basically oriented to making lots and lots of cheap capacitors.

Early DDR devices are already running at over 400 MT/s (million transfers per second) in small systems such as graphics controllers and Transmeta's low-power systems. JEDEC is now putting the finishing touches on DDR and most of the hairy design work is moving to DDR-II. As usual, the second pass mostly applies the lessons learned on the first pass. DDR-II will have less legacy support and will remove some features in the "nice but not worth the speed cost" category.
The objective is to run early parts with >400 MT/s data rates in large systems -- or in other words, your 72-bit DIMM is going to have more than twice the bandwidth of those still-not-available 800 MT/s Rambus parts -- and the DDR-II parts won't require water cooling, either.

Re:One world: DUH

[jht]

You're dead right on the Rambus pricing issue - it costs way too much. Part of that is the royalty factor, but it's more (right now) caused by low yields on Rambus parts and a very small amount of makers. There's no flood of RDRAM on the market to drive prices down the way there is with SDRAM. If yields were equivalent to SDRAM and more people were making the parts, the prices would be a lot more competitive, but still somewhat pricier because of the royalty issue.

As far as USB/Firewire goes, though - it isn't royalties that have slowed Firewire acceptance. Intel had included USB in every chipset since the LX several years ago - in fact, USB support was in silicon before any OS had support for it. That's why it was on motherboards - It's part of the chipset whether or not you want it, so you might as well build the ports. Firewire royalties are tiny (below $1/port), and it's split between Apple and the other patent holders (I believe TI and Canon are in the group, too). Firewire would have been adopted quicker had Intel followed through with their earlier plans to include it in newer chipsets.

The other thing that sped acceptance of USB versus Firewire is that USB 1.0 was ready a (relative) long time ago, and Firewire is only a couple of years old. The DV cameras that really take advantage of Firewire have just begun to be priced approriately for the casual camcorder buyer. Sony and Apple build the ports onto virtually all their systems, and are selling them as fast as they can build them.

Also a Good Thing for USB - since the CPU controls the bus and it's a simple protocol, it's well-suited for cheap, simple peripherals like modems, digital still cameras, low-end scanners, audio devices, etc. Firewire aims a lot higher.

- -Josh Turiel

Rambus was doomed from the start

[jht]

When Rambus was being designed, EDO RAM was the current standard, and Rambus is competitive in a head-to-head with EDO - with latencies in the same class or faster but much better transfer speeds. SDRAM was intended as a stopgap measure to provide a memory technology that could keep up with the faster Pentium/Pentium II systems during the wait for Rambus to make it to market. But a few things happened to screw it all up:

SDRAM took off as a standard, and other chipset makers adopted it - and extended it to PC100 and PC133 from the original PC66.

CPU speeds accelerated faster than anyone planned (a year ago, 600 MHz was state of the art!)

Rambus was late to market, as were the systems designed to use it. This gave SDRAM more of an opportunity to become entrenched.

Rambus has proven to be difficult to manufacture to this point, with horrible yields.

And finally, SDRAM turned out to be a lot more scalable than anyone anticipated at the beginning.

If Intel had expected DDR PC133 SDRAM, Rambus might never have made it out of the starting blocks in the first place. But given the lead time on their chipset and CPU design cycles, they had to make a call based on what the trend appeared to be - and they bet on the wrong one. The 810 chipset is a lot more important to Intel right now than they had expected it to be, and the 815 wasn't even planned - they also were hoping to retire BX by now. Some of their supply problems of late have been driven by this misforecast. When the dust settles, I expect to see Rambus slowly squeezed out of the mainstream and Intel to quietly write off their investment. It seemed like a good idea at the time...

- -Josh Turiel

Interleving memory banks

[Bryan Andersen]

What ever happened to interleaving memory banks for more speed? It does raise the pin counts, but package technologies have been developed that mitigate that. I have an old 486DX2-66 motherboard that does interleving between two banks of ram. Each cache load loaded two memory words into the external cache instead of one. It won't lead to better write performance, but read rates will nearly double (You get something like a 1.8x effective increase).

Rambus=phft!

[Khan]

Well, I can tell you that yesterday at COMDEX, I saw an Itanium chip running in a demo box. When I asked what kind of ram it was using, I was told that it was PC133. When I asked why it wasn't using RAMBUS, the guy stuttered and said that he wasn't allowed to comment on rambus. 'Nuff said.

The wired effect ?

[steve.m]

Didn't wired also say that interactive movies, push content and Iridium were 'the next big thing'. Look where they are now.

One world: DUH

[LocalYokel]

Regardless of what these EE majors and other so-called experts have to say, the real reason Rambust is going nowhere is cost. Sure, Grambus is not offering a significant/if any performance benefit, but even if it did, the price would have to match performance.

Nobody really likes new technologies that add significant cost through royalties -- see FireWire (ahem) IEEE 1394. USB was free, which is why everyone had those controllers on their motherboards years before they had anything to plug into them.

Rambus would have a great chance if it was not commanding a 500% premium, and perhaps cost only 10-15% more than current SDRAM. If they can get the prices down, which they will not, Intel would have been able to release a four channel solution that would significantly reduce its latency (this is coming) and increase its performance. As the technology became financially reasonable for everyone to use, mass production would bring the price down even further.

Besides, who wants to go back to paying 1995 prices for RAM?

--

A more tempered look at DRDRAM

[dpilot]

Two forenotes:

1 - I've been involved in the design of DRDRAM for several years, now. I've been in memory design for 18 years, also. I'm slightly more informed on this than the average geek-on-the-street.

2 - I really don't like the principle behind DRDRAM. Proprietary things are supposed to eventually become commodities, not the other way around. Memory has long been THE commodity in a computer, and here they are trying to make it go the other way. But it's technically interesting, my contributions won't make or break the whole scheme, and the kids gotta eat.

Cons:

Fundamentally, for at least the near future, it simply takes more silicon to implement the Rambus interface. No matter how much learning you do, that area doesn't go away. Perhaps after the spec stabilizes fully, it may be possible to come up with better fully custom circuit implementations, but that's at least a little ways in the future. Plus in the performance race, it's possible that the spec may never stabilize sufficiently before a given generation is obsolete.

It's very complex. My boss would have slapped me silly had I ever even thought of coming up with this. In years past I've been slapped silly for coming up with stuff a fraction of this complexity.

Latency - Obvious, though there is a second side to this, under Pros.

Wash:

The frequencies are high, and the margins tight. I suspect EVERYONE is going to have to cope with the same realm, sooner or later. DRDRAM is simply a bit ahead of its time on this on, and is taking the pain, first. I remember when it was tough getting the whole chip to run at 100MHz for SDRAM, or even 150nS for page mode DRAM.

Pros:

Granularity - don't discount this one. Presently DIMMs are made with 8 chips, each organized with X8 outputs. That says that 64Mb technology makes 64MB DIMMs. It also says that 256Mb technology makes 256MB DIMMs, even though mainstream PCs today are only now making the transition from 64MB to 128MB. That's part of the reason we've dropped the 4X-per-generation habit, and are bringing out 128Mb SDRAM, because the market just isn't ready for 256Mb. 512Mb and 1Gb are on the drawing boards and early hardware now, so this problem is going to get worse. A single 1Gb chip holds 128MB. (Obviously)

Pin count - As more integration happens, the reduced pincount of DRDRAM may become a bigger factor. It's a simple matter of 168 vs 55, though the 55 need to be at a higher frequency. It's simply easier to integrate a DRDRAM interface and have enough pins to do all of those other things, like an AGP bus.

Banking (Latency) - While simple latency is poorer, under situations with multiple threads of access (multithreading and/or DMA streams) the higher bank count of Rambus becomes an advantage. If a bank is left open, or even if it has just been closed following a prior operation, you need to wait a 'restore time' before you can access that bank, again. With DRDRAM there are usually more accessable banks, so odds are better that the next access will be to a bank that is currently closed. Even if the simple latency is longer, if you don't have to pay the 'restore time' penalty, the effective latency becomes shorter. This doesn't show up unless you have multiple memory access streams, though.

No summary

RamBus DRDRAM vs. DDR SDRAM

[Halo1]

I think you may find the following article quite interesting: "DDR SDRAM vs. RAMBUS DRDRAM". It's not written by the mosr staff (it was actually a reaction to a feature containing incorrect/skewed information), so all you mosr-haters can calm down already.

The author explains why he thinks DDR SDRAM is better dan DRDRAM and shows once again that MHz isn't everything.

--

a more clever title...

[dirtmerchant]

... then wouldn't a more clever title have been rambust? sorry, its early and i need sleep. i realize that was unforgivably stupid.
-----BEGIN GEEK CODE BLOCK-----
v.3.12
GCS d-(--) s+: a-- C+++$>++++$$ UL++$>++++$$ P+>++++$ L++>++++$ E--- W++$>++