[an error occurred while processing this directive]

DDR Memory Analysis. Part 1: Kingmax DDR-466


We proceed with the series of articles devoted to the low level analysis of the most important characteristics of memory modules using the RightMark Memory Analyzer test package. The object of our next analysis is a couple of colored Kingmax DDR-466 modules of the high-performance hardcore series with stylish original design.

Manufacturer Information

Module manufacturer: Kingmax Inc.
Chip manufacturer: Kingmax Inc.
Web site of the module manufacturer: http://www.kingmax.com/product/color.htm
Web site of the chip manufacturer: N/A

Module Appearance

Photo of the memory module




Photo of the memory chip




Part Numbering System of Modules and Chips




Module Part Number Expansion

Data sheet on Kingmax DDR-466 does not contain information about the expansion of some part numbers of the modules. The documentation provides only brief technical characteristics pertaining to some part numbers. The characteristics of the module under review are provided below.

Field Value Expansion
0 MPYB62D-38KS4G Module density: 256 Mb
Configuration: 32M x64
Module bandwidth: 3.7 GB/sec
Memory clock: 4.3 ns
Data rate: 466 MT/s
Timings (tCL-tRCD-tRP): 3.0-4-4

SPD module chip data

Description of the SPD general standard:
JEDEC Standard No. 21-C, 4.1.2 - SERIAL PRESENCE DETECT STANDARD, General Standard

Description of the SPD specific standard for DDR:
JEDEC Standard No. 21-C, 4.1.2.4 – Appendix D, Rev. 1.0: SPD’s for DDR SDRAM

Function Byte Value Expansion
Fundamental Memory Type 2 07h DDR SDRAM
Number of Row Addresses on this assembly 3 0Dh 13 (RA0-RA12)
Number of Column Addresses on this assembly 4 0Ah 10 (CA0-CA9)
Number of DIMM Banks 5 01h 1 physical bank
Data Width of this assembly 6, 7 40h, 00h 64 bit
Voltage Interface Level of this assembly 8 04h SSTL 2.5V
SDRAM Cycle time (tCK) at maximum supported CAS# latency (CL X) 9 43h 4.3 ns (232.5 MHz)
DIMM configuration type 11 00h Non-ECC
Refresh Rate/Type 12 82h 7.8125 ms – 0.5x reduced self-refresh
Primary SDRAM Width (organization type) of the memory module chips 13 08h x8
Error Checking SDRAM Width (organization type) of the memory chips in the ECC module 14 00h Not defined
Burst Lengths Supported (BL) 16 0Eh BL = 2, 4, 8
Number of Banks on SDRAM Device 17 04h 4
CAS Latency (CL) 18 18h CL = 2.5, 3.0
Minimum clock cycle (tCK) at reduced CAS latency (CL X-0.5) 23 50h 5.00 ns (200.0 MHz)
Minimum clock cycle (tCK) at reduced CAS latency (CL X-1.0) 25 00h Not defined
Minimum Row Precharge Time (tRP) 27 48h 18.0 ns
4.19, CL = 3.0
3.60, CL = 2.5
Minimum Row Active to Row Active delay (tRRD) 28 28h 10.0 ns
2.33, CL = 3.0
2.00, CL = 2.5
Minimum RAS to CAS delay (tRCD) 29 48h 18.0 ns
4.19, CL = 3.0
3.60, CL = 2.5
Minimum Active to Precharge Time (tRAS) 30 28h 40.0 ns
9.30, CL = 3.0
8.00, CL = 2.5
Module Bank Density 31 40h 256 MB
Minimum Active to Active/Refresh Time (tRC) 41 3Ch 60.0 ns
13.95, CL = 3.0
12.00, CL = 2.5
Minimum Refresh to Active/Refresh Command Period (tRFC) 42 46h 70.0 ns
16.28, CL = 3.0
14.00, CL = 2.5
Maximum device cycle time (tCKmax) 43 30h 12.0 ns
SPD Revision 62 00h Revision 0.0
Checksum for Bytes 0-62 63 AFh 175 (true)
Manufacturer’s JEDEC ID Code (only the first significant bytes are shown) 64-71 7Fh, 7Fh,
7Fh, 25h
Kingmax Semiconductor
Module Part Number 73-90 - MPYB62D-38KS4G-MAAR
Module Manufacturing Date 93-94 04h, 00h 2004
Module Serial Number 95-98 00h, 00h,
00h, 00h
Not defined

SPD chip contents look not quite standard. Supported CAS# Latency values – 3.0 and 3.0. The first value (CL X = 3.0) corresponds to the non-standard cycle time – 4.3 ns (nevertheless, it matches the value claimed in Kingmax specification), that is the module operates at about 233 MHz (DDR-466). Timing scheme for this case can be expressed as 3.0-4.2-4.2-9.3, in reality (taking into account that tRCD, tRP and tRAS cannot take non-integral values) – 3.0-4-4-9 (which again matches the values provided above in the part number expansion). The second value of CAS# latency (CL X-0.5 = 2.5) corresponds to the standard (for DDR-400) cycle time of 5.0 ns. Timing scheme in the second case is written as 2.5-3.6-3.6-8 (in reality – 2.5-4-4-8).

Testbed Configurations and Software

Motherboards based on the chipsets of Intel 915 series

Testbed #1

Testbed #2

Testbed #3

Testbed #4

Testbed #5

Testbed #6

Testbed #7

Testbed #8

Testbed #9

Testbed #10

Testbed #11

Testbed #12

Test Results

According to our method, the memory modules were tested in two modes. The first series of tests (performance tests) were carried out in normal mode, with standard timings set in motherboard BIOS according to the SPD chip data. The second series (stability tests) – in the "extreme" mode with maximum possible timings for a given module on a given motherboard.

Tests in dual channel mode

Performance tests




The first series of tests in dual channel mode was carried out with "standard" settings – memory operating in DDR-400 mode, timings being set "by SPD". You can easily see that different BIOS versions on different motherboards interpret data in this chip differently. Most of them "agree" to 2.5-4-4-8, being the true values for these modules operating at 200 MHz – we have already shown that above. Enabled PAT (Testbed #1) slightly pulls up timings (up to 2.5-3-3-7), while the on-board memory controller of AMD64 (Testbed #8) ignores tRAS and sets its own value (2.5-4-4-6). But, running a few steps forward, we can note that it's not very successful – most likely, Kingmax DDR-466 modules (like the majority of other modules) simply ignore this parameter in chipset settings and use their own values. Quite an unexpected result is demonstrated by the Gigabyte K8NS Ultra-939 motherboard based on nForce3 250 chipset (Testbed #9)... to be more exact, the lack of result! The memory modules just refused to operate with this motherboard for some unclear reason, taking into account that the memory controller is part of an AMD Athlon 64 processor, not part of a chipset. We are only to guess that BIOS of this motherboard modifies some settings of the integrated memory controller (for example, memory interleaving) different from those used by BIOS in ASUS A8V Deluxe (Testbed #8).

Let's proceed to test results. Among the testbeds of the same type (Testbeds #1 – 7, except for the AMD system) the leadership both by memory bandwidth and by latency is taken by Albatron PX865PE Pro (Testbed #1) with enabled PAT. The second place is occupied by ASUS P5P800 (Testbed #3), which also uses the memory performance acceleration technology. Putting aside these results, we can see that almost all platforms based on Pentium 4 demonstrate more or less equal results: maximum memory read bandwidth is within 6150-6200 MB/sec, pseudo-random memory access latency is within 55-65 ns. But there are exceptions: ASUS P4P800-VM (Testbed #2) is obviously lagging behind by latency (60-70 ns).

Athlon 64 based system (ASUS A8V Deluxe, Testbed #8) expectedly keeps aloof. Its distinctive features are a considerably higher maximum real memory write bandwidth, and consequently lower pseudo-random access latency (only 34-38 ns).

Stability tests

The second series of tests was carried out with minimum possible timing values not resulting in memory glitches.




From this table you can clearly see that you can set any tRAS timing value in config registers of the chipset (up to 4 inclusive) without ruining memory operation stability. Values of the other timings are the same for all tested systems – 2.0-3-3. Note that the modules under review can operate at lower timings – 2.0-3-2, but it practically immediately resulted in read/write errors (it should be noted that the number of these errors was considerably less in Testbed #8 with Athlon 64 processor). What concerns low level characteristics of the memory system – it's easy to see that switching to the "extreme" mode didn't change the disposition. With PAT enabled, Testbeds #1 and #3 are still leading by their memory bandwidth and latency (among the "equal", that is excluding the AMD system). The other motherboards demonstrate average results, except for ASUS P4P800-VM (Testbed #2), which is loosing by its pseudo-random memory access latency.

Tests in single channel mode

Performance tests




Test conditions of the first series of tests in single channel mode match those in the dual channel mode – all settings are by default. Albatron PX865PE Lite Pro (Testbed #10) acts like the "dual channel" model (Testbed #1) – when PAT is enabled, "tougher" timings are set (2.5-3-3-7). nForce 3 250 chipset again brings a surprise, this time it's EPOX 8KDA3J (Testbed #12) that won't work. There is no sense in comparing the values in this case – they will only demonstrate obvious differences in memory system characteristics with and without PAT as well as no less obvious differences between the integrated memory controller in AMD64 and the controller in the i865PE chipset.

Stability tests




Stability tests in the single channel mode reveal some differences from the test results in dual channel mode. Namely, we managed to set 2.0-3-2 memory timings in Athlon 64 system retaining system stability! (remember that this configuration in dual channel mode resulted only in reduced number of glitches).

Bottom line

First of all, we should dwell on the compatibility issue of Kingmax DDR-466 memory modules with motherboards based on various chipsets. So, these modules are not recommended to use with motherboards based on NVIDIA nForce3 chipsets (both in single and in dual channel mode), because you risk to jeopardize your memory system stability (it may even result in complete inoperability). What concerns the other motherboards and chipsets tested (VIA K8T800/Pro, i865PE/G, i915P/G), we can say that they demonstrate approximately the same stability results (minimum timings, in particular). We should name Albatron PX865PE Pro (Testbed #1) and ASUS P5P800 (Testbed #3) as obvious leaders in memory system performance due to PAT support, while the worst result was demonstrated by ASUS P4P800-VM (Testbed #2), which is characterized by high memory latencies.



Dmitry Besedin (dmitri_b@ixbt.com)

November 18, 2004


[an error occurred while processing this directive]