# How fast was Rambus compared to regular EDO RAM?

The Nintendo 64 used Rambus RDRAM. This was an unusual choice, e.g. the PlayStation used regular EDO RAM which I gather most consoles and computers did at the time.

As I understand it, Nintendo chose Rambus for speed. This is surprising; it was only 9 bits wide, compared to 32 bits for the EDO RAM on the PlayStation, so by default I would've expected it to be slower.

How fast was it compared to EDO RAM? To have a speed advantage, it would need to be clocked at least four times as fast. Was this actually the case? If so, how?

• You can put RAM chips in parallel, was the N64's RAM only 9 bits wide or did they make it 4 chips wide to get 36? Jan 5, 2021 at 19:21
• @user253751 It offered a 9 bit wide data port. Just with extreme high clock rates (for back then) and DDR transfer. Chips were not in parallel Jan 6, 2021 at 0:29

## What's the question?

First problem here is what is to be considered speed.

• Random access time?
• Cycle time?
• Maximum memory thruput?
• Average memory thruput?
• Either value per chip or
• for the whole memory subsystem?

For the following I'll go with maximum memory bandwidth for the whole memory subsystem. That is when a memory page is opened and successive access is done at full bus speed. In this page opening time can be (mostly) ignored, as it is (at each time) the same, independent of interface technology. Doing the numbers is thus rather simple:

## The Numbers

RDRAM in the N64 is bytewide (*1) and operates at 250 MHz, delivering two bytes per cycle:

250 MHz x 2 Byte = 500 MB/s

EDO-RAM in the Playstation is 32 bit wide and operates ~33 MHz, delivering a word per cycle:

33 MHz x 4 Byte = 133 MB/s

So basically RDRAM as used in the N64 delivers words ca. 15 times faster than EDO-RAM used by the PS. Considering the wider memory word (32 vs 8) of the PS still leaves about four times the memory bandwidth.

## Why RDRAM

There are several benefits from using RDRAM with its high clock rate:

• Memory doesn't need to be as wide, as four consecutive fetches (for a word) can be done faster than the CPU can swallow it
• Smaller memory width needs less chips
• Smaller memory width means less lines to be routed. 9 vs. 32 bit results 23 saved lanes to be routed to CPU and graphics - at cost of only a single additional address line.
• Less lanes to route means cheaper board production - part of the reason why the N64 could get away with a simple two layer board
• Fast transfer speed allows a Unified Memory Architecture (UMA), saving the need for additional logic/buffers to separate main and video RAM.
• UMA allows flexible allotment of RAM to either purpose.
• UMA nullifies (or at least greatly reduces) the need to transfer data from main memory to video memory as such can be done by bending pointers.

## Any Drawback?

A unified memory architecture means that CPU and graphics hardware compete for RAM access. Depending on how much data either component needs to access, congestion can happen. Albeit, the quite high bandwidth and the way memory is accessed make it manageable.

## Why EDO RAM in the PS?

At the time of the Playstation, EDO was already an outdated technology, passed by SDRAM were PC100 became standard in 1992. 32 bit wide SDRAM would have provided 400 MB/s. But as well be expensive.

Sony picked a design with separate main and video RAM so main RAM had only to go along with the CPU speed - and needed to be 32 bit wide for sufficient thruput. So chips may have been way less expensive, but at the same time board design was more complex and it did need additional logic.

In the end the N64 was the more aggressive and advanced design and it payed of in performance and price.

*1 - For simplicity we ignore the dance around the 9th bit some N64 fans love to do :))

• PC100 SDRAM may have been standardized in 1992,but it took quite a few years before it became standard (i.e. the most commom option). The high-sales-volume low-end PCs I was buying in the mid 90s still used EDO RAM. My first machine with SDRAM was my first Pentium 2 ca 1999, and I suspect many others had the same experience. Jan 6, 2021 at 0:11
• @occipita Didn't say standardized, but standard.The point here is not when some of us switched for SDRAM, but that both systems (PS/N64 introduced 1994/1996) were designed at a time EDO was already on the way out. Sony was looking back at the past, while Nintendo was looking ahead - resulting in a notably better performing machine. Already in 1992 it was quite clear that EDO is on the way out. RDRAM was the clear favourite, except that Rambus screwed it with their licence policies, so development took a bit longer (and a detour via SDRAM) until DDR reached the same level in the early 2000s. Jan 6, 2021 at 0:28
• I recall one of RDRAM's drawbacks for mainstream computers was power usage. With only a tiny amount of RAM (2 chips for 4MiB total, unlike a 1U server with many sticks), I guess it wasn't a big deal for N64. Also, IDK if Rambus's high-speed narrow bus (16-bit) interface could scale to modern bandwidths if it had caught on. Modern techniques for controlling skew in high-speed parallel traces have been pretty successful. I guess it could have simply widened to 64-bit. en.wikipedia.org/wiki/Rambus#Technology mentions latency was worse than with standard sdram, as well as power. Jan 6, 2021 at 4:43
• One big drawback of RDRAM was the licence cost to RAMBUS. Intel tried to impose it on the PC market with the Pentium 4 but AMD and most board manufacturers would not play along. The price difference was so big that Intel had to cave and drop RDRAM. Jan 8, 2021 at 12:28

Do not confuse "fast" in terms of bandwidth (bytes per second) with "fast" in terms of latency (nS from beginning of address request till when bytes are in cache). Rambus used a highly serialized protocol that required multiple clocks to even start a transaction, and more clocks to transmit the address values.

Thus the combination of the N64 memory control unit and the Rambus memory was "fast" in terms of the rate of bytes per second flying back, but "slow" in terms of the number of clocks from start of memory transaction to end of memory transaction. Thus it was fast (bytes per second) for large bursts of data, but "slow" if you wanted a single byte from memory right now (in terms of number of stalled clock cycles on in-order cache misses).

EDO memory was "slow" in terms of clock speed and peak bandwidth, but an address could get sent in a single (2 phase) clock, and more bits of data came back in one clock. Thus it could be faster (lower latency) for small item fetches.

The (cancelled) Magic Carpet follow-on project at SGI/MIPs switched (back) to using SDRAM because of various latency issues found in developing software for the Reality Engine.