Variable FSB?

[mtn26bkr]

Hey everybody. I've always wondered why chipsets can't be designed or programmed to automatically recognize the speed of the memory, and then support the speed. For instance if you had a chipset that supported up to DDR333, could the designers make the chipset identify DDR400 and automatically recognize it. Or is this problem related to the standardization of the memory?

 

[Sahakiel]

And here I thought SPD was somebody's wet dream...

Before we work on artificial intelligence why don't we do something about natural stupidity? ~Steve Polyak

 

[mtn26bkr]

SPD=stupidity?

 

[CTho9305]

No, it's some information on the ram that tells the chipset how fast it can run. Motherboards adjust ram timings automatically by reading the SPD. "Back in the day", you had to manually set speeds in the bios (60, 70ns, etc).

 

[Matthias99]

However (to add a bit more), you can still get into problems with, say, DDR400 in a DDR333 motherboard. If the BIOS on there doesn't know what to do with super-high-speed RAM (often a problem with older and/or cheaper boards), it might not work properly with the automatic detection. But basically every motherboard built in the last 3 years or so can autodetect most DDR RAM just fine.

 

[aka1nas]

Originally posted by: mtn26bkr
Hey everybody. I've always wondered why chipsets can't be designed or programmed to automatically recognize the speed of the memory, and then support the speed. For instance if you had a chipset that supported up to DDR333, could the designers make the chipset identify DDR400 and automatically recognize it. Or is this problem related to the standardization of the memory?

If the chipset could identify DDR400 in particular, then why wouldn't it just support it? If you mean you want it to run it at the supported lower speed, then that is already present as mentioned above.

 

[Pulsar]

If a motherboard only supports up to DDR333, it may very well be that DDR400 wasn't out yet when the motherboard was created. Sure, down the road, a bios update may allow the board to detect newer faster memory, but since you plug the memory in to the motherboard when you take the motherboard "out of the box" and manually set the correct speed if it doesn't autodetect, this is all academic.

 

[Peter]

Folks, the SPD data define all timings in nanoseconds, not clocks or frequencies - so a carefully written BIOS does make the best use of any kind of DIMM you throw at it, given that it's at least as fast as the board's minimum requirement. Too fast a DIMM just won't be used at the best of its abilities, but still at the best of the board's abilities.

And yes, there are boards that auto-detect the best bus speed to run its DIMMs at. I just have built a system with an ECS L7S7A2 (yes, a cheapie, $29) that did exactly that. With an FSB266 processor and DDR333 RAM, putting DRAM speed to "auto" made it choose 166 MHz RAM bus speed. Spot on.

 

[TerryMathews]

Modern SPD implementations have wonderful capabilities. I've seen several DIMMs that had SPDs which set different timings on AUTO depending on what frequency they were run at. Very cool.

Back to the OP's question: If you've never taken an intro CEG course, this may go over your head. Basically, to have latency of any reasonably small measure, you have to have some sort of related clock rates; they don't have to necessairly be the same speed, but they have to be linked somehow or the clock signals will meet up very rarely.

Think like when you're driving on a rainy day. You can see the cars around you with their windshield wipers on. But because they run at very slightly different frequencies than yours does, they don't match up with yours very often.

Without using some sort of buffering, you can only transmit data when the clock signals of the two devices trying to communicate are in the correct position, whether low or high. If you're running asynch frequencies, that may happen very rarely. If the rates are synch, even if scaled, because they derrive from the same clock, the clock signals will match up far more often.

Now as to why chipsets don't have an infitine number of scalar ratios: Same reason cars don't have an infinite number of gears. The scaling hardware in your chipset is an actual piece of hardware, if microscopic.

 

[Peter]

Terry, once again, there is no magic to that. SPD datasets state all timings in nanoseconds - and the board's BIOS must then compute how many clock cycles at the given frequency this then makes. Of course the result differs with the frequency.

 

[TerryMathews]

Originally posted by: Peter
Terry, once again, there is no magic to that. SPD datasets state all timings in nanoseconds - and the board's BIOS must then compute how many clock cycles at the given frequency this then makes. Of course the result differs with the frequency.

You read my statement incorrectly. I've owned DIMMs that when inspecting the SPD data using a tool capable of downloading it like ctSPD, had different timings listed for different memory frequencies.

 

[Peter]

Hardly. The SPD is just a stupid little EEPROM, values hardcoded by the manufacturer. What you claim to have seen would require a frequency counter, some brain, and multiple datasets. Noone's doing that.

Besides, it'd be completely silly to do that. ALL TIMINGS IN SPD ARE STATED IN NANOSECONDS. A nanosecond is a nanosecond, no matter which frequency you're using to look at one. SPD has been defined and specified this way for the exact reason of having frequency-independent descriptions of the RAM's capabilities.