Testing 72-pin SIMMs

On Dec 28, 10:12, Douglas Quebbeman wrote: [...] 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