Browse Prior Art Database

Cache line fetch data integrity test algorithm

IP.com Disclosure Number: IPCOM000031319D
Original Publication Date: 2004-Sep-21
Included in the Prior Art Database: 2004-Sep-21
Document File: 4 page(s) / 58K

Publishing Venue

IBM

Abstract

Current memory tests typically rely on write-read-compare operation to verify the data integrity of both the memory and the cache subsystems. When testing strictly memory, there are various addressing algorithms which bypass the cache, but the basic mechanism of analyzing forced memory fetches at particular address remains the same. In one system under development, it was noticed that these conventional memory tests would fail to report data miscompares even in systems where it was known that such failures had occurred. It was determined that, due to the inherent cacheline architecture of the memory controller, the location that a given memory error occured was beyond the address actually being analyzed. A new test was required for two main reasons: First in modern memory architectures which fill whole cachelines per fetch, simply analyzing a single data item ignored other data items from the fetch that could have failed. Simply reading all the addresses can mask the problem due to the excessive overhead of memory operations. Also, the affected data locations can often be behind (address-wise) the current address, so they would be missed in a normal sequential read. A second need for an improved test is the ability to verify the accuracy of a reported error in hardware and reporting the details of the failure correctly (when ECC is turned off). For these reasons, a new test was developed which integrated the fetching mechanisms of the memory controller into the analysis logic.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 4

Cache line fetch data integrity test algorithm

    Most modern server architectures consist of a processor element connected to memory with one or more varying levels of memory cache. The cache methodology isn't critical to the operation of the algorithm other than to understand the influence that the cache has upon the memory test and standard tests won't report any errors. As an example Figure 1 shows a model of an actual system where a cache is 4-way set associative with the main memory and the cacheline size is 128 bytes in length.

Figure 1: Main Memory Mapping to the Processor Cache (example)

    An example of a modern server architecture would be a system where main memory is double data rate (DDR) bus interleaved with two busses of 8-bytes of data each and independently covered with an 8 bit ECC for a total data path of 144 bits of data. Figure 2 shows the addess mapping to the main memory as seen by the processor and the test cases.

1

[This page contains 1 picture or other non-text object]

Page 2 of 4

*Bolded box is a cacheline Figure 2: Main memory byte address layout (values are offset addresses)

    When the processors have a cache miss the data is requested from the memory controller, the data that is requested is considered the "critical" word. The critical word is only a portion of the cacheline that is fetched from the main memory. So for the test case the fetch would use the 8 bytes that it requested then move on to new locations. The problem was that the critical word (8 bytes) was fetched correctly and passed the data integrity check of the testcase (realize that part of the testcase is to initialize memory so that the memory contents are predetermined); however, the testcase didn't take into account that the non-critical portion could have been fetched incorrectly from main memory and loaded into the processor cache. The testcase would move on to other locations in memory and would eventually invalidate the cache contents that contained the erroneous non-critical data.

    When a cache line request is performed the accesses are performed in two bursts of four operations, where the DDR specification indicates a burst of four as sequential or interleaved operation. The memory controller accesses the DRAM in the interleaved format. Figure 3 illustrates the potential combinations of pattern fetching based upon interleaved access and the critical word that is requested.

2

[This page contains 8 pictures or other non-text objects]

Page 3 of 4

Figure 3: DRAM Output Pattern per "Critical" Address Fetch for Interleaved Setting

    On a system experiencing memory errors the limitations of testing this architecture quickly becomes clear. On the failing system, it was reported by the memory controller that the last beat of a burst was in error. However, for a given cache line the controller could not report whi...