RE: In search of bad 4164, 41256 DRAM

>> That wouldn't catch an error where 2 adjacent cells (physically, not necessarily adresswise) developed a short circuit. To catch this error, you'd have to fill the RAM, verify that state, then flip the bit in question and verify it is indeed flipped. So far so good... but now you have to check the RAM for additional flipped bits.

That is exactly what I did, let's look at bits 0-15 and say bits 1-11 are shorted

a) fill all bits with 0
b) read bit 0, is it 0? If not, this is a fail
c) set bit 0 to 1, read bit 0, is it a 1, if not this is a fail
d) repeated b&c all bits.

When we get to bit 1 it will seem to work fine. When we get to bit 11 the first read will return a 1 which is a failure. 

Jeff Birt

-----Original Message-----
From: Gerrit Heitsch <gerrit_at_laosinh.s.bawue.de> 
Sent: Monday, October 14, 2019 9:19 AM
To: cbm-hackers_at_musoftware.de
Subject: Re: In search of bad 4164, 41256 DRAM

On 10/13/19 9:40 PM, Jeffrey Birt wrote:
> Thanks Dave, I’ve read about the MARCH tests previously and to my 
> understanding parts of these tests are designed to find addressing 
> errors and/or for multi-bit wide memories. There is also the issue on 
> modern processors with making sure that you just not writing/reading 
> to/from cache.
> 
> I did just finish up adding a ‘walking value’ test which fill the 
> memory with all zeros or ones and steps through each bit, confirms it 
> is still at the fill state, changes the state and tests for the changed state.
> This should hopefully help catch any internal addressing (row/column) 
> errors where a write might write to adjacent cells as well.

That wouldn't catch an error where 2 adjacent cells (physically, not necessarily adresswise) developed a short circuit. To catch this error, you'd have to fill the RAM, verify that state, then flip the bit in question and verify it is indeed flipped. So far so good... but now you have to check the RAM for additional flipped bits.

  Gerrit