Browse Prior Art Database

Dynamic Error Injection and Prediction for Memory Controller Validation

IP.com Disclosure Number: IPCOM000014421D
Original Publication Date: 2000-Oct-01
Included in the Prior Art Database: 2003-Jun-19
Document File: 2 page(s) / 58K

Publishing Venue

IBM

Abstract

Disclosed here is a method for dynamically injecting errors in memory and allowing full prediction in a random simulation environment for a memory controller. The problems that this invention addresses are logic coverage and schedule during the simulation phase of ASIC development. Traditional methods of verifying Bad Machine Path (BMP) rely very heavily on manual effort in creation of test scenarios as well as checking for correct results. This testing typically takes place last after all the good paths have been stressed, and quite often major microarchitectural changes are required to get the error cases handled correctly by the hardware. This can be very costly in terms of redesign and reverification of the Good Machine Path (GMP) logic to also be able to handle the Bad Machine Path cases. Disclosed here is a method of incorporating Error Injection and automatic results checking into "normal" GMP testing for any partition of logic that involves an interface to a memory unit and that supports error detection/correction mechanisms. The advantage here is that Bad Machine Path or BMP testing can take place earlier, and can be done on any and all configurations as part of a "Normal" testcase bucket, thus allowing earlier validation of all paths (i.e., GOOD and BAD). Using this method of dynamic error injection, we were able to very easily verify the functions that the Redundant Bit Steering (RBS) logic executed. RBS means that the hardware can make use of "extra" bits to the data arrays by "steering" the data on these "extra" wires to any bit that could be bad in an array or on an interface. In order to implement this, the simulation environment code needs to have its own copy of what memory should look like. This copy must stay up-to-date as simulation progresses. The method goes as follows for General Data BMP validation:

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

Page 1 of 2

Dynamic Error Injection and Prediction for Memory Controller Validation

  Disclosed here is a method for dynamically injecting errors in memory and allowing full prediction in a random simulation environment for a memory controller.

The problems that this invention addresses are logic coverage and schedule during the simulation phase of ASIC development. Traditional methods of verifying Bad Machine Path (BMP) rely very heavily on manual effort in creation of test scenarios as well as checking for correct results. This testing typically takes place last after all the good paths have been stressed, and quite often major microarchitectural changes are required to get the error cases handled correctly by the hardware. This can be very costly in terms of redesign and reverification of the Good Machine Path (GMP) logic to also be able to handle the Bad Machine Path cases. Disclosed here is a method of incorporating Error Injection and automatic results checking into "normal" GMP testing for any partition of logic that involves an interface to a memory unit and that supports error detection/correction mechanisms. The advantage here is that Bad Machine Path or BMP testing can take place earlier, and can be done on any and all configurations as part of a "Normal" testcase bucket, thus allowing earlier validation of all paths (i.e., GOOD and BAD). Using this method of dynamic error injection, we were able to very easily verify the functions that the Redundant Bit Steering (RBS) logic executed. RBS means that the hardware can make use of "extra" bits to the data arrays by "steering" the data on these "extra" wires to any bit that could be bad in an array or on an interface.

In order to implement this, the simulation environment code needs to have its own copy of what memory should look like. This copy must stay up-to-date as simulation progresses.

The method goes as follows for General Data BMP validation:

1) Generate and load the Unit Under Tests with random memory configuration.
2) Generate Random data and place data in both the hardware model (i.e., via warm loading techniques) and the softcopy that the environment holds. At this time generate Good ECC for the data in both copies.
3) The simulation environment dynamically forces random error(s) to the data in memory (i.e., the hardware's copy of memory). The Unit Under Test should be correcting the errors when loading data from its copy of memory, and eliminating them from its storage when storing data back to memory. At this point there is no need to corrupt the softcopy, because it can also be used for load data prediction, and should be corrected by the Unit UnderTest.
4) When the end of test memory compares are done, the hardware memory is first checked for errors. If an error exists, the simulation environment "fixes" the error in this data by removing...