Browse Prior Art Database

Concurrent Dynamic Validation of Hardware Scrubbing Disclosure Number: IPCOM000013895D
Original Publication Date: 2000-Aug-01
Included in the Prior Art Database: 2003-Jun-19
Document File: 2 page(s) / 42K

Publishing Venue



Disclosed is a method for dynamically validating the scrubbing logic for

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Concurrent Dynamic Validation of Hardware Scrubbing

Disclosed is a method for dynamically validating the scrubbing logic for

memory controller in a random fashion and concurrently with other random

functions supported by the memory controller.

Hardware supported scrubbing algorithms are typically designed to run continuously. Memory controllers that support hardware scrubbing typically have a sequencer that gets kicked off by software control. It then tirelessly walks through memory reading data, doing ECC checks, recording syndromes, and optionally correcting the data and storing the corrected data back to the memory arrays. The scrubbing logic typically shares some control and dataflow with the "normal" load and store operations that a memory controller must support. Obviously there are some decision points in the implementation that require arbitration for use of these shared facilities. It is very desirable to allow scrubbing functions to be turned on randomly and thus causing interference with the "normal" sequence of loads and stores to the memory arrays. Traditional verification efforts concetrated on this "tough to hit logic by writing manual patterns.

The dynamic checking methodologies of today monitor testcase commands and Unit Under Test interfaces to determine where an operation starts and then with some intelligent prediction logic, decides where it should then be routed. It is also common to use a static initial memory image that is loaded at simulation initialization time to give an inital state of system or main memory. This image is loaded into a memory model which the Unit Under Test will interact with. At the same time, this initial load is loaded into a software copy that the code will maintain for comparison purposes at sync points in the testcase and/or final end of test comparisons. This memory is then updated as needed by following interface traffic and/or testcase activity. It is difficult to test the scrubbing function with other functions in a random way, because the accesses for scrubbing initiate inside the Unit Under Test. One difficulty arises with the fact that the pre-load of memory for the scrub is difficult to determine statically at initialization time, because one does not know how many scrubs will be completed in a simulation run. A second difficu...