Questions about DDR RAM

  • Thread starter Thread starter Igor
  • Start date Start date
In alt.comp.hardware.pc-homebuilt daytripper

ALL of them do.
It's on the DIMM, not the motherboard.
Completely transparent. The mobo doesn't even know it's there.

Erm, pardon me but being the village idiot, I don't quite understand
this part.

If the motherboard doesn't even know ECC is there, why are there
options to turn off ECC on some boards? Also, why do boards state they
support non-ECC or ECC memory if it's transparent to the board?

Lastly, where is this ECC logic implemented on the ECC dimm because
looking at the pictures, apart from the additional memory chip, they
don't seem to have any additional IC doing this ECC thing.
 
Erm, pardon me but being the village idiot, I don't quite understand
this part.

If the motherboard doesn't even know ECC is there, why are there
options to turn off ECC on some boards? Also, why do boards state they
support non-ECC or ECC memory if it's transparent to the board?

Lastly, where is this ECC logic implemented on the ECC dimm because
looking at the pictures, apart from the additional memory chip, they
don't seem to have any additional IC doing this ECC thing.

Simply put, he is utterly wrong...

/daytripper (hth ;-)
 
In alt.comp.hardware.pc-homebuilt [email protected]
(The little lost angel) said:
Erm, pardon me but being the village idiot, I don't quite understand
this part.

If the motherboard doesn't even know ECC is there, why are there
options to turn off ECC on some boards? Also, why do boards state they
support non-ECC or ECC memory if it's transparent to the board?
I was mistaken, it seems. I thought the logic on the ECC-capable boards
were done logically and transparently; auto-correcting on-the-fly, like
I would have done; the corrected-read *always* appearing on the output.

However, it seems that would slow the delivery of memory-results down by
at least a gate-delay or two; and speed-is-all in today's computers.
Besides, as-pointed-out by others in this discussion, today's memories
are actually pretty damned good; and memory-failures are rare enough (at
the most a few times a day; and at the least almost never) that it
doesn't pay to invoke that extra delay. So, while the logic *is* on the
DIMM, the end-result is just to raise an interrupt if an error occurs;
and then back-up and correct the error afterwards. (Hopefully it didn't
cause something disastrous to happen when it occurred.) I'm not too
sure how you CAN correct a memory-error after it already happened, even
if you know what the error was (and that's what ECC does). But
supposedly they can.

OR, maybe I'm mistaken; and the ECC memory *does* correct it on-the-fly;
and just raises an exception to let the system know that a correction
was made. I'd have to look into the specifications I guess.

In any case, the interrupt *does* allow the system to log errors so you
know when things are going down the tubes; and unlike parity-errors,
which don't do you a bit of good, with ECC the errors *are* corrected.
That's what the middle 'C' in ECC stands for.
Lastly, where is this ECC logic implemented on the ECC dimm because
looking at the pictures, apart from the additional memory chip, they
don't seem to have any additional IC doing this ECC thing.

You didn't look closely enough.
They have several extra chips.
Both extra memory bits, *AND* extra logic.
 
In alt.comp.hardware.pc-homebuilt [email protected]

I was mistaken, it seems. I thought the logic on the ECC-capable boards
were done logically and transparently; auto-correcting on-the-fly, like
I would have done; the corrected-read *always* appearing on the output.

However, it seems that would slow the delivery of memory-results down by
at least a gate-delay or two; and speed-is-all in today's computers.
Besides, as-pointed-out by others in this discussion, today's memories
are actually pretty damned good; and memory-failures are rare enough (at
the most a few times a day; and at the least almost never) that it
doesn't pay to invoke that extra delay. So, while the logic *is* on the
DIMM, the end-result is just to raise an interrupt if an error occurs;
and then back-up and correct the error afterwards. (Hopefully it didn't
cause something disastrous to happen when it occurred.) I'm not too
sure how you CAN correct a memory-error after it already happened, even
if you know what the error was (and that's what ECC does). But
supposedly they can.

OR, maybe I'm mistaken; and the ECC memory *does* correct it on-the-fly;
and just raises an exception to let the system know that a correction
was made. I'd have to look into the specifications I guess.

In any case, the interrupt *does* allow the system to log errors so you
know when things are going down the tubes; and unlike parity-errors,
which don't do you a bit of good, with ECC the errors *are* corrected.
That's what the middle 'C' in ECC stands for.


You didn't look closely enough.
They have several extra chips.
Both extra memory bits, *AND* extra logic.

There is absolutely no logic on the DIMMs that contribute to ECC - other than
the extra drams for storage of the ECC check bits.

All ECC logic is in the host chipset, including the check bit generators, the
syndrome generators, the data correctors, error triggers, etc.

The DIMM has no awareness of the integrity of the data stored thereon. DIMM
data is always raw, uncorrected data...

/daytripper
 
In alt.comp.hardware.pc-homebuilt daytripper
There is absolutely no logic on the DIMMs that contribute to ECC - other than
the extra drams for storage of the ECC check bits.

All ECC logic is in the host chipset, including the check bit generators, the
syndrome generators, the data correctors, error triggers, etc.

The DIMM has no awareness of the integrity of the data stored thereon. DIMM
data is always raw, uncorrected data...
OK ... That actually makes sense.
Still, there *are* several extra chips on the ECC-capable DIMM.
Extra data requires extra places to store it.
 
In alt.comp.hardware.pc-homebuilt daytripper

OK ... That actually makes sense.
Still, there *are* several extra chips on the ECC-capable DIMM.
Extra data requires extra places to store it.

What part of "There is absolutely no logic on the DIMMs that contribute to ECC
- other than the extra drams for storage of the ECC check bits." did you miss?

/daytripper (it's Deja Vu all over again ;-)
 
In alt.comp.hardware.pc-homebuilt daytripper
What part of "There is absolutely no logic on the DIMMs that contribute to ECC
- other than the extra drams for storage of the ECC check bits." did you miss?
The "other than the extra dram" part.
 
OK ... That actually makes sense.
Still, there *are* several extra chips on the ECC-capable DIMM.
Extra data requires extra places to store it.

Let's try this so everybody has the same picture
ValueRam 1GB Kit HyperX Reg ECC DDR 400MHz 3-3-3
http://www.amazon.co.uk/gp/product/...797970-8922313?ie=UTF8&n=560798&s=electronics

I count 9 similarly sized/shaped chips so those should be the DRAM
chips. There is just ONE extra chip in the corner which I believe is
the Serial Presence Detect (SPD) chip that's basically an EEPROM that
provides configuration information.

From Kingston KVR533D2E4/1GI 1GB 128M x 72-Bit DDR2-533 CL4 ECC
240-Pin DIMM
http://www.valueram.com/datasheets/KVR533D2E4_1GI.pdf

Also shows a similar picture except it's doublesided with 9 DRAM chips
on both side and only one SPD chip for the entire DIMM.


So I'm kinda confused, where "*are* the several extra chips on the
ECC-capable DIMM" that you are refering to?
 
I count 9 similarly sized/shaped chips so those should be the DRAM
chips. There is just ONE extra chip in the corner which I believe is
the Serial Presence Detect (SPD) chip that's basically an EEPROM that
provides configuration information.

I could be wrong but thought the SPD was in a PROM or EPROM,
with only specialized memory recently being released (from
OCZ?) that has an EEPROM.


From Kingston KVR533D2E4/1GI 1GB 128M x 72-Bit DDR2-533 CL4 ECC
240-Pin DIMM
http://www.valueram.com/datasheets/KVR533D2E4_1GI.pdf

Also shows a similar picture except it's doublesided with 9 DRAM chips
on both side and only one SPD chip for the entire DIMM.


So I'm kinda confused, where "*are* the several extra chips on the
ECC-capable DIMM" that you are refering to?

He might've been thinking of buffered memory.

http://www.simmtester.com/page/news/images/fbdimm_4.jpg
 
a?n?g?e? said:
Erm, pardon me but being the village idiot, I don't quite understand
this part.

If the motherboard doesn't even know ECC is there, why are there
options to turn off ECC on some boards? Also, why do boards state they
support non-ECC or ECC memory if it's transparent to the board?

Lastly, where is this ECC logic implemented on the ECC dimm because
looking at the pictures, apart from the additional memory chip, they
don't seem to have any additional IC doing this ECC thing.

Erm, you're not the village idiot. As you note, the memory module
only has the extra bits on it to do the error code. Frank's
experiment will "work", but since those extra bits aren't connected
to anything, it's a small value of "work". Software types really
shouldn't be messing with hardware. Someone's going to get hurt. ;-)
 
In comp.sys.ibm.pc.hardware.chips krw said:
Erm, you're not the village idiot. As you note, the memory module
only has the extra bits on it to do the error code. Frank's
experiment will "work", but since those extra bits aren't connected
to anything, it's a small value of "work". Software types really
shouldn't be messing with hardware. Someone's going to get hurt. ;-)

"Beware of programmers who carry screwdrivers" [Leonard Brandwein]

-- Robert
 
"Beware of programmers who carry screwdrivers" [Leonard Brandwein]

At the PPOE, the software types got nervous when the hardware types
came around with screwdrivers too. Once, after assuring them that we
really did know what we were doing, we installed a crypto feature on
their test vehicle. Bringing up the hardware (the second copy in
existence) we found a signal didn't get "from here to there". So we
powered off the system before removing the logic modules (about 4"
water-cooled cubes) trying to track down the errant signal. When we
disconnected the water jacket it all of a sudden got very quiet and
programmers started coming out of the woodwork to see what happened.
The dumb bastards had switched the consoles from one side of the MP
configuration to the other so we were trying to debug the hardware on
one side with the console on the other. No wonder the signal didn't
get from here to there. Those things (1200W logic modules) sure
didn't appreciate running without water either.
 
In alt.comp.hardware.pc-homebuilt chrisv said:
Which is one extra chip, not "several".

How do you get several more bits with only one chip?
This isn't parity, but ECC.

As I recall a SECDED hamming-code for 32-bits would require a minimum of
7 extra bits for single-bit ECC correction and double-bit parity-error
detection.

If a standard DIMM gets 4 bits each in 8 chips, that would require a
minimum of two more chips, not one.
 
Frank said:
How do you get several more bits with only one chip?
This isn't parity, but ECC.

As I recall a SECDED hamming-code for 32-bits would require a minimum of
7 extra bits for single-bit ECC correction and double-bit parity-error
detection.

If a standard DIMM gets 4 bits each in 8 chips, that would require a
minimum of two more chips, not one.

First of at it's not 32 bits. And 8 bits per 64 works well :)

rgds
\SK
 
How do you get several more bits with only one chip?

Chips, these days, are more than one bit wide. X-1 chips went out
with button shoes.
This isn't parity, but ECC.

The memory doesn't know the difference.
As I recall a SECDED hamming-code for 32-bits would require a minimum of
7 extra bits for single-bit ECC correction and double-bit parity-error
detection.

Memory is 64bits wide these days. Run your numbers again.
If a standard DIMM gets 4 bits each in 8 chips, that would require a
minimum of two more chips, not one.

Try 8bits each in eight chips, add a ninth for parity/ECC.
 
In comp.sys.ibm.pc.hardware.chips krw said:
Memory is 64bits wide these days. Run your numbers again.

Quibble: *DIMMs* are 64-bits wide these days.

Memory, even just talking about main memory on the PC architecture, runs
from 64 bits to 256 (possibly 512, if you count AMD's lightweight NUMA as
parallel. Otherwise, 256 is for the quad-channel Xeon boards.)

ISTR some fairly ridiculous bus widths for high-end graphics cards, as well.
 
How do you get several more bits with only one chip?
This isn't parity, but ECC.

As I recall a SECDED hamming-code for 32-bits would require a minimum of
7 extra bits for single-bit ECC correction and double-bit parity-error
detection.

Only a standard DIMM is a 64 bit module, not 32. An additional
bit is required due to the enlarged module word size and so ECC
DIMM is 72 bit to accommodate the extra data. Taking a standard
8-chip DIMM you see that each chips takes 8 bit words and so only
a single additional module is required.
 
Quibble: *DIMMs* are 64-bits wide these days.

We were talking about memory.
Memory, even just talking about main memory on the PC architecture, runs
from 64 bits to 256 (possibly 512, if you count AMD's lightweight NUMA as
parallel. Otherwise, 256 is for the quad-channel Xeon boards.)

We were talking about memory, not processor implementation. Do you
have an example of an x86 processor with a wider than 64bit data path
to the DIMM (ignoring dual channel for the moment, which is simply
two DIMMs)?
ISTR some fairly ridiculous bus widths for high-end graphics cards, as well.

We were... Do you really have parity/ECC on graphics cards?
 
Back
Top