Presentation on theme: "Serial Presence Detect – Using It Effectively to Improve System Performance Bill Gervasi Technology Analyst"— Presentation transcript:
Serial Presence Detect – Using It Effectively to Improve System Performance Bill Gervasi Technology Analyst
Agenda What is a Serial Presence Detect (SPD)? How is it used in systems? How can it be used to tune performance? Using the new SPD revision system
What is the SPD? I 2 C-based serial EEPROM located on all JEDEC modules Describes the module characteristics Describes the DRAM characteristics
Using the SPD Read all module SPDs at boot time Each SPD has a unique I 2 C address wired Configure the memory controller based on contents of all SPDs SPD ID= X0 ID= X1 ID= X2 ID= X3 I 2 C serial bus DIMM Slot 0 DIMM Slot 1 DIMM Slot 2 DIMM Slot 3 Memory Controller (or South Bridge)
SPD Contents Memory and interface type Module configuration DRAM coarse parameters DRAM fine parameters Module features
Simple Boot Procedure Reject incompatible modules –E.g., DRAM type –E.g., Operating frequency too slow Calculate the memory range & program per-slot addressing Determine row, column, and block addressing Set interface speed or timing –Possibly based on module loading Load and fly
Module Parameters Standard module features –ECC bytes –Register on address lines –PLL on clock lines Unique module features –Fast PLL relock –Module height
Fine DRAM Timing Parameters Some fields can determine performance: t DQSQ, t QHS are key for variable frequency systems t CK min and t CK max determine operating range Available operating frequency = 1 (necessary setup & hold + crap) t QHS (simplified view) DQS t DQSQ data Sampling window
Coarse DRAM Timing Parameters Values not known in advance –Refresh timing for future densities –CAS latencies supported Values that vary from vendor to vendor (JEDEC optional or superset) Values that vary speed bin to speed bin –Row cycle & row-column access time –Special features, e.g., fast autoprecharge t RFC = ???
Other Tuning Parameters CAS latencies Memory cycle times based on CAS latencies Row precharge time Random column access time Address and command setup & hold Data and mask setup & hold Write recovery time Loading on address or data bus (determines slew rate) Chipsets can use all of these to get the most efficient use of available memory bandwidth
SPD Revision But SPDs change over time… how do I know what to read? New feature: two part SPD Revision system –Encoding revision –Contents revision SPD Byte 62 = EncodingContents In review now
SPD Revision Revision levels –Encoding level should only change in emergencies… tells how to interpret existing fields –Content level determines which bytes and bits are defined –Content level never reverts or resets back to 0 SPD interpretation –BIOS must reject modules with encoding level higher than it understands –BIOS should accept higher content levels but only use the fields it knows how to decode!
An SPD Revision Example Initial release Added new bytes or attribute bits Added more bytes or attribute bits Encoding changed in some byte/bit Added more bytes or attribute bits Encoding changed in some byte/bit plus added a byte or attribute bit Rev
How Often Do SPDs Change? JEDEC procedure to review once per year –All approved changes held until Board meets –Board approves any revision release package –No changes? No action taken
Summary SPDs are a valuable part of DIMM design Simplest use is to configure system to run More complex systems can take advantage of special features New revision system lets BIOSes handle changes gracefully Updates not more often than once a year