On Dec 28, 10:12, Douglas Quebbeman wrote:
> > I've never found a bullet-proof program for testing SIMMs under DOS or
> > windows,
[...]
> > Anybody know of one?
>
> I have a one, designed by Charles (?) Cook, and first
> implemented by John Molnar, which I've reimplemented
> for the Sol, some Z-80-based machines, and the 8051
> embedded systems I've developed. But I never got around
> to porting it to DOS...
>
> Our Dell servers shipped with a program called "Dell
> Diagnostics" which includes a comprehensive memory
> test that can check for stuck bits, shorts between
> address bits, short between address and data bits,
> etc.
>
> It complains when I run it on non-Dell equipment,
> but usually works, and it's so far caught problems
> nothing else would catch.
I don't know about Charles Cook, but the name John Molnar sounds vaguely
familiar. However, the best test I've ever found was one that runs in
linear time (ie twice as much memory takes twice as long to test; most
tests run in time dependant on some power of the size -- eg double the
size, triple the time, like a Galpat which depends on the square of the
size).
The test was devised and implemented by Suk and Reddy, and is described in
"A march test for functional faults in semiconductor random access
memories", published in IEEE Transactions on Computing Vol.C-30
No.12,December 1981. There were a whole lot of articles about memory
testing in the journals around that time, and there's a follow-up article
by Abadir and Reghbati, in Computing Surveys Vol.15 No.3, September 1983,
published by the ACM, which presents a kind of survey of methods.
This test will find stuck-at-zero, stuck-at-one, data coupling faults,
address coupling faults, data-address-coupling faults, and decoder faults.
It's pretty easy to implement, and *provided* each data bit is in a
separate IC, you can do all the bits in parallel. If not (eg if the RAMs
are 4-bit wide devices) then you need to do some manipulation to ensure
you're not affecting bits you don't want to -- a fact conveniently
forgotten by most RAM test implementors.
Anyway, Suk & Reddy's test is quite fast, and very easy to implement. I
did a Z80 version that tested the entire RAM in a bytewide array (so lots
of shifts and loops) without using any stack (what's the point in storing
data in the memory you think needs testing?), and it runs in just under six
seconds at 3.5MHz. If you had one bit per chip, obviously it would be much
more than 8 times faster (8 times because of parallelism and a further
factor of two or more by eliminating the shifts, some loops, and logical
ORs/ANDs used for masking individual bits).
The one thing most memory tests *won't* do is test for correct refresh
tolerance. You may also have trouble testing the parity fully unless you
can read/write the parity bits directly. Very few tests, by the way, will
detect pattern-sensitive faults. Luckily, these are very rare, and I've
only ever seen one true pattern-sensitive fault that wasn't a simple
coupling fault.
--
Pete Peter Turnbull
Network Manager
Dept. of Computer Science
University of York
Received on Thu Dec 28 2000 - 14:54:01 GMT