What is this SCEI patent?

[PC-Engine]

Having a higher clock speed isn't necessarily an advantage. If memory A offers the same bandwidth as memory B but requires a doubling of clock frequency, A is not better than B.

 

[notAFanB]

Having a higher clock speed isn't necessarily an advantage. If memory A offers the same bandwidth as memory B but requires a doubling of clock frequency, A is not better than B.

and what if A costs less and/or runs on less heat? surely the deciding factor (bar some of the nitty gritter technical differences) is cost?

 

[Squeak]

However I do know for a fact that Nintendo chose RDRAM for the N64 because of costs. It needed fewer PCB layers. Too bad they didn't consider latency. Don't know what the situation is with XDR though.

I've read that, on the contrary, RDRAM is supposed to have very low latency, in part due to the high clockrate.
It might be the unfortunate implementation by Intel some years ago, that has people confused?

 

[Simon F]

My understanding always was that RDRAM's latency was high but that it had very high data transfer rates. I could be wrong though.

 

[akira888]

The largest issue with RDRAM is that each RIMM is connected serially with each other unlike DDR-SDRAM in which the DIMMs are arranged in a grid formation. The 16 bit data signal therefore has to travel through each RIMM (or placeholder stick in case of an empty slot), and the "furthest" RIMM from the memory controller will determine the latency. On the plus side you have double the banks open per RIMM, but bank charge time is typically higher than SDRAM.

 

[Guden Oden]

while that's all well and good for PC space, for an fixed console I cannot see the advatages if the perforemence ( of both parts at the time) are near enough Identical.

Huh?

I just described why Sony might like XDR over standard DRAM schemes; granularity, fewer pins etc. You might just as well turn your reasoning upside down; while GDDR and XDR have similar performance levels, XDR has the advantage of better granularity, fewer pins etc.

what would be the likely cost reduction over the lifetime of PS3? (including the initial price of purchase?)

Sony wouldn't purchase anything, they're going to fab the memory themselves. There would be a small royalty to Rambus though, but nothing that compares to what they'd have to pay if they were to source the memory on the open market.

How does does this compare with the projected figures for GDDR3 over the same period?

I haven't the faintest clue, but we can assume the steam in standard non-differential signalling schemes will run out sooner or later since interference will be a bigger and bigger problem the higher we dial up the frequencies...

 

[Squeak]

The largest issue with RDRAM is that each RIMM is connected serially with each other unlike DDR-SDRAM in which the DIMMs are arranged in a grid formation. The 16 bit data signal therefore has to travel through each RIMM (or placeholder stick in case of an empty slot), and the "furthest" RIMM from the memory controller will determine the latency.

Again, isn't that only how it's implemented on the Intel boards?
On PS2 the bus(ses) that go to the RDRAM doesn't look serial to me.

 

[Guden Oden]

DRDRAM in PS2 is a point-to-point configuration, not serial... You have two memory devices, two memory channels, each 16-bit wide, and that's it.

 

[Fox5]

However I do know for a fact that Nintendo chose RDRAM for the N64 because of costs. It needed fewer PCB layers. Too bad they didn't consider latency. Don't know what the situation is with XDR though.

I've read that, on the contrary, RDRAM is supposed to have very low latency, in part due to the high clockrate.
It might be the unfortunate implentation by Intel some years ago, that has people confused?

I heard PS2 wasn't very good either, something like 50 nanoseconds latency, compared to 10 nanoseconds on xbox's main ram, and <1 nanosecond on gamecube's. I've also heard the latency of the entire gamecube system is about 10 nanoseconds, whereas the ps2 and xbox(and most modern computers) are in the hundreds, though I think athlon 64 computers can get under 100.

 

[akira888]

Well, PS2 only has 2 RIMMS, each with it's own channel (and a rather short trace) so my comment does not apply in that case. However the bank charge time is still rather high.

 

[Guden Oden]

Fox5,

You've certainly heard a lot, though it seems not much, if anything of it is true.

Access time for all types of DRAM is from what I've been able to gather basically the same regardless of the clock speed, in the 60-ish ns territories, this is somehow inherent to the DRAM tech itself and doesn't seem to have changed much over the years. Adding or subtracting to that is the type of connection to the memory (1st gen RDRAM = major addition) and various SRAM buffering techniques, like in 1T SRAM that hides the initial access penalty by keeping a copy of the first few pieces of data in fast SRAM memory.

Latency on xbox main mem is certainly not 10ns and gamecube not 1ns, that's way faster than reality. On-chip 1T SRAM for GC is around 5ns +/- a little (don't remember exact figures), and main memory is about 12ns. That's at least 8x better than any other DRAM-based system, XB included, but it's not 1ns, no way.

 

[PC-Engine]

My understanding always was that RDRAM's latency was high but that it had very high data transfer rates. I could be wrong though.

That was my understanding too. Good for streaming data but not good for random access.

 

[David_South#1]

A Unix/Linux/BSD variant will definitely be the OS.
A Hurd OS is the OS I’ve been using as a template.

This is in line with previous speculation, now the forum doesn't feel lost and confused anymore. Thanks for putting us back on track!
To those of us that - eeheh *coughs* unlike me - maybe aren't fully up to speed on this - what is a Hurd OS anyway?

The way I refer to it wasn’t helping you.
Hurd isn’t a type of OS, it is actually a fully working real world OS.

A better answer,
http://www.gnu.org/software/hurd/hurd.html http://www.gnu.org/software/hurd/gnumach.html

it's compatible
The Hurd provides a familiar programming and user environment. For all intents and purposes, the Hurd is a modern Unix-like kernel. The Hurd uses the GNU C Library, whose development closely tracks standards such as ANSI/ISO, BSD, POSIX, Single Unix, SVID, and X/Open.
it's built to survive
Unlike other popular kernel software, the Hurd has an object-oriented structure that allows it to evolve without compromising its design. This structure will help the Hurd undergo major redesign and modifications without having to be entirely rewritten.
it's scalable
The Hurd implementation is aggressively multithreaded so that it runs efficiently on both single processors and symmetric multiprocessors. The Hurd interfaces are designed to allow transparent network clusters (collectives), although this feature has not yet been implemented.
it's extensible
The Hurd is an attractive platform for learning how to become a kernel hacker or for implementing new ideas in kernel technology. Every part of the system is designed to be modified and extended.
it's stable
It is possible to develop and test new Hurd kernel components without rebooting the machine (not even accidentally). Running your own kernel components doesn't interfere with other users, and so no special system privileges are required. The mechanism for kernel extensions is secure by design: it is impossible to impose your changes upon other users unless they authorize them or you are the system administrator.
it exists
The Hurd is real software that works Right Now. It is not a research project or a proposal. You don't have to wait at all before you can start using and developing it.

GNU Mach is the microkernel of the GNU system. A microkernel provides only a limited functionality, just enough abstraction on top of the hardware to run the rest of the operating system in user space. The GNU Hurd servers and the GNU C library implement the POSIX compatible base of the GNU system on top of the microkernel architecture provided by Mach.

Mach, is particularly well suited for SMP and network cluster techniques. Thread support is provided at the kernel level, and the kernel itself takes advantage of that. Network transparency at the IPC level makes resources of the system available across machine boundaries (with NORMA IPC, currently not available in GNU Mach).

Sounds pretty good. But this is old news from about a year ago.

Recently, I just might be able to name the Specific OS being worked on for Cell.
As soon as Pana helps me air my thoughts I hope to share them with you.

Panajev, said something that remined me of a personal reason in regards to PPC440 not being used as the PU. I don’t know that it won’t be. But my reason also seemed pertinent to the OS options, and one specific OS that I recalled seems to fit the spec.

 

[David_South#1]

Luckily, the console isn't launching tomorrow. By the time it does launch, XDR will likely be considerably faster than it is now (well, ISN'T, really, but we have paper specs ). Considering it uses differential signaling and all that, it should be able to go faster using 256 data pins (half data, half data inversed), than what GDDR3 manages with 256 data pins.

If you compare the fluidity between 30 and 60, it's a totally different ballgame..
[/quote]

In the way of XDR it was my impression that 32datapins/16bits was as many as they would have implemented by this time. That was the industry limit I was referring to.

But to sum it up. Toshiba is sampling 3.2Ghz 16bit XDR.
But you need two 32bit XDR-DIMM at 3.2GHz to reach 25.6GB/sec.

Rambus still has to achieve 6.4GHz or quaduple (=64bit) the bit count to reach 50GB/sec.

Key to XDR DRAM's draw is its high bandwidth per pin. Using a 400MHz clock, XDR can transmit eight data bits per clock (octal data rate) attaining a 3.2GHz/pin data rate. An 8-bit interface can transfer 3.2GBs/sec, and a 32-bit interface hits 12.8GB/sec. Tack two 32-bit "XDIMMS" together and you reach 25.6GB/sec at 3.2GHz signaling. Rambus expects to quickly move to 6.4GHz/pin signaling, so if you expand to a 128-bit interface at 6.4GHz/pin, you can reach 102.4GB/sec. This is far beyond speeds on DDR roadmaps. Rambus attains such speeds using three key technologies: Differential Rambus Signaling Levels (DRSL), FlexPhase technology (to compensate for timing errors), and octal data rate signaling mentioned previously. You can check out Rambus XDR info on their site for technical details. http://www.rambus.com/products/xdr/

http://www.extremetech.com/print_article/0,1583,a=119135,00.asp

I want note that I revised the post you were replying to. (Cleaned up.)
Specifically changing Firewire from "probably" to "not so likely".
USB 2.0 is enough for most applications.

 

[Gubbi]

My understanding always was that RDRAM's latency was high but that it had very high data transfer rates. I could be wrong though.

That was my understanding too. Good for streaming data but not good for random access.

This is probably due to the braindead P4 chipsets Intel produced that basically used RDRAM as super fast SDRAM.

The Alpha EV7 integrated (multiple) RDRAM controllers on the die and has a load-to-use latency in the 75 ns range (ie. faster than SDRAM).

On top of that RDRAM chips can have more banks open at the same time, increasing the chance of hitting an open bank and thereby reducing latency further.

There's a good presentation of the EV7 implementation (with numbers) here:

http://www.eecs.umich.edu/vlsi_seminar/f01/slides/bannon.pdf

Cheers
Gubbi

 

[PC-Engine]

The Alpha EV7 integrated (multiple) RDRAM controllers on the die and has a load-to-use latency in the 75 ns range (ie. faster than SDRAM).

Faster than DDR1 at the time?

 

[Gubbi]

The Alpha EV7 integrated (multiple) RDRAM controllers on the die and has a load-to-use latency in the 75 ns range (ie. faster than SDRAM).

Faster than DDR1 at the time?

I think so. The Opteron with todays state of the art DDR has a load-to-use latency of 50-55 ns on a open page hit, with another 20ns penalty for hitting a different page. I don't know if that is with buffered ECC DIMMs or not (the EV7 number includes ECC).

Cheers
Gubbi

 

[Guden Oden]

In the way of XDR it was my impression that 32datapins/16bits was as many as they would have implemented by this time.

"They"?

XDR modules can of course be paired up in an arbitrary fashion just like DRDRAM, so what the width of the data module itself is doesn't really matter much...

But you need two 32bit XDR-DIMM at 3.2GHz to reach 25.6GB/sec.

This isn't really a problem though, because you need 256 data pins of DDR to reach the same figure. That's 4x as many pins as XDR needs with differential signals included. Then there's some extra fluff for both standards, and DDR(2) needs lots of ground pins and such, but I'll ignore that for now.

Rambus still has to achieve 6.4GHz or quaduple (=64bit) the bit count to reach 50GB/sec.

Even with 4 3.2GHz modules in width, it's still only half the pins of (G)DDR2/3 for 50GB/s, I don't really understand what you're getting at...

 

[Paul]

Grall speaks the truth.

 

[PC-Engine]

XDR uses differential pairs at 3.2Gbps per pair, which gives the same per-pin bandwidth as (non-differential) 1.6 Gbps GDDR3 memory. No gain there.

Uhh, please correct me if I'm wrong, but it was my understanding that with normal single-ended signaling, you'll need a ground pin for every data pin.

Thus, for every pair of pins on the package, you'll yeild 1.6Gbps with GDDR3, but with first generation XDR, you'll yeild 3.2Gbps. And XDR is slated to scale from it's current 400mhz to 800mhz (6.4GHz) within 2 years.

Uhh, please correct me if I'm wrong, ...

You are.

There's no special "signal ground" lines in GDDR3.
IO signals are relative the power ground, and I don't think there's any extra power ground signals compared to XDR.

You are.

There's no special "signal ground" lines in GDDR3.
IO signals are relative the power ground, and I don't think there's any extra power ground signals compared to XDR.

Interesting, then how exactly does GDDR3 get around the noise problems that are related with unbalanced transmission? Where's a good place for more specific information? I remember hearing that in single-ended signaling, your ratio of active pins to power and those to ground will converge on 1:1 - obviously, you can get around this with XDRs DRSL which should provide you with 2X the mean, per pin, transmission rate as the ratio nears 1:1, but I've never read up on any of the DDR2/GDDR3 specs.

You can isolate signals with by putting grounded traces in between without having extra grounding pins ... power-consumption and signal integrity are seperate issues.

Samsung's GDDR3 chips have 14 power and 18 ground pins which are designated for output, it seems to have seperate power grids for the memory and the I/O, for 32 I/O pins.