( ESNUG 309 Item 4 ) ---------------------------------------------- [1/27/99]
Subject: DRAM Memory Testing Algorithms, Walking 1's, Address Testing, Etc.
> Would anybody help me in finding out the algorithms for DRAM Address line
> test, Data line test, Walking 1's test, and Walking 0's test?
>
> - Mohit
> Riverrun
From: "Paul Taylor" <p.taylor@ukonline.co.uk>
Try http://www.ednmag.com
The Feb1 '96 magazine has a very good article "Testing RAMs and ROMs"
on page 153.
- Paul Taylor
---- ---- ---- ---- ---- ---- ----
From: pkasieck@cognex.com (Philip T. Kasiecki)
I can give you two of them. These are both done assuming you test 8 bits
at a time, and moving along in the memory is not included. That should be
done just outside the for loops here.
/* Walking 1s -- 00000001, 00000010, 00000100, 00001000, etc. */
data = 0x01;
for(data = 1; data <= 128; data <<= 1) {
Write the data
Read the data
if(data_in != data_out) test fails
}
/* Walking 0s -- 11111110, 11111101, 11111011, 11110111, etc. */
data = 0xFE;
for(data = 254; data >= 127; data = ((data << 1) +1)) {
Write the data
Read the data
if(data_in != data_out) test fails
}
The walking 0s has a little more to it, as you have to account for a zero
coming in at the end when you shift. It's not as simple as the walking 1s.
- Philip T. Kasiecki
Cognex Corporation Natick, MA
---- ---- ---- ---- ---- ---- ----
From: Gary Wong <gary@cs.arizona.edu>
Actually, if you're doing a destructive test (i.e. you don't care about
clobbering what's stored in the memory you're testing), it's better to
step the address _inside_ the loop (ie. write _all_ the data, then go
back to the start and test it all starting from the beginning).
In some circumstances, writing the data and immediately testing it may
appear to pass the memory test even if the RAM isn't there at all (if
the test write values float on the data bus).
No test can detect _all_ failures in finite time, but some get closer
than others. Whatever you implement, give it a quick "sanity check"
and see what kinds of failures will go undetected -- typically the
most common failure modes are that the memory is not there at all, or
data and/or address lines are open, shorted, or crossed. Think about
which of these (and other) cases your implementation will detect.
Don't stop until you're satisfied that the failures that it can't
detect are acceptable. For instance, if you modified the "walking 1s"
test given above to test successive bytes on each iteration, it would
cycle through a pattern every 8 memory locations. It won't detect an
error if address lines A4 and A5 are shorted together, for instance.
This may or may not be acceptable, depending on your requirements.
- Gary Wong
University of Arizona Tucson, AZ
---- ---- ---- ---- ---- ---- ----
From: pkasieck@cognex.com (Philip T. Kasiecki)
> In some circumstances, writing the data and immediately testing it may
> appear to pass the memory test even if the RAM isn't there at all (if
> the test write values float on the data bus).
I guess a short delay (using sleep() or the equivalent in the particular
language being used) would help- or would it?
Another test that can be useful is alternating 1s and 0s, and then
switching them (i.e., first writing 0x55, then 0xAA, for 8 bits).
- Philip T. Kasiecki
Cognex Corporation Natick, MA
---- ---- ---- ---- ---- ---- ----
From: z80@digiserve.com (Peter)
No, the bus cap can hold data up for ages.
You need to write the test value to the test location, then write its
complement to another location (so the complement appears on the data
bus), then you read back the original test value from the original
location.
Personally, I like a simple 55/AA test - this picks up duff bits in
RAM chips (extremely rare) followed by a pseudo random fill. The P/R
fill fills the entire RAM with a pattern, than goes back to start and
reads it back. If you repeat this with just a few different seeds, the
chance of any type of fault is vanishingly small, and this is a very
easy test to write.
- Peter
Digiserve
---- ---- ---- ---- ---- ---- ----
From: jackklein@att.net (Jack Klein)
> No test can detect _all_ failures in finite time, but some get closer
> than others. Whatever you implement, give it a quick "sanity check"
> and see what kinds of failures will go undetected -- typically the
> most common failure modes are that the memory is not there at all, or
> data and/or address lines are open, shorted, or crossed.
I actually prefer reading and verifying pattern n-1 and then writing
pattern n to each location on each pass, instead of writing the whole
block then testing the whole block on each pass. Catches shorted address
lines because writing the new pattern to a location near the beginning
would overwrite the old pattern higher up.
- Jack Klein
AT&T
---- ---- ---- ---- ---- ---- ----
From: Darren Hutchinson <dbh@gbdt.com.au>
In my current project I've had to put together some simple, but fast,
memory tests. (I was inspired by an article of memory tests in Embedded
Systems programming from ~1993 (which suggested looking at the failure modes
rather than just doing things that were done in the past, and being
orthoginal about the testing to simplify problem diagnosis). I implemented
the following:
1. Simple walking 1/0 across the data bus (full width) at a single
location.
Rational: If the data bus isn't connected properly there is little
point testing anything else.
2. Simple address test (write address to each location, then go back and
read them all.)
Rational: There is no point testing the data cells until there is some
confidence that the device is correctly connected, otherwise it would
be difficult to seperate data cell errors from address line connection
faults, especially if a random sequence is used.
Also, given that the memory device connections are likely to be less
reliable than the device itself it will be much simpler to diagnose a
problem any problem found in the next test if we're sure that the data
and address lines are correctly connected!
3. Write the area with a few standard pattern (AA/55 etc).
Rational: Writes 1 and 0 to every location testing individual cells.
4. (optional) For DRAM devices it is worth writting the 'discharged cell'
value (memory failing me ...) to each location and then stopping all
DRAM access for a few seconds to test the DRAM refreshing.
Simple eh? Note that these tests don't test for every possible fault (for
example cross cell interaction in DRAM), but this can be done in
approximately 5 seconds for 4 MB of DRAM.
It's also worth considering WHY you're doing the memory test. For a go/
no go power-on test the ability to diagnose the fault isn't so important,
therefore a quick random value test may be quicker.
For production testing it is normally important to be able to diagnose
the fault. The tests above should make fault finding simple by, as far
as possible, testing a single aspect of the memory subsystem at a time.
- Darren Hutchinson
NEC Australia P/L
|
|
