Maker Pro
Maker Pro

Strange SDRAM problem - Influenced bit corruption

Hello, I'm having some really strange SDRAM issues and hope someone
can point me the right direction - or at least help me understand the
cause of this..

We have some boards that have been working very well for several years
and we recently upgraded the standard SDRAM device (TSSOP) for one
with twice the capacity from a different manufacturer - the board is
designed to accommodate this size device.

We calculated the refresh/latency/page etc settings and all seemed
good. Except on a few devices where we see the following:

Written pattern: 0x5555aaaa
Read Pattern: 0x5557aaaa

On a failing board this is seen consistently at this one bit location.
We can manually read and write to this problem nibble and see that the
bit in error only gets set high when the bits either side of it are
set to '1', IE:

Written: b0000 Read: b0000
Written: b0001 Read: b0001
....
**Written: b0101 **Read: b0111
Written: b1100 Read: b1100
**Written: b1101 **Read: b1111


On different boards the problem appears at different bit locations.
The problem is made worse, with more boards exhibiting this problem,
when colder.

Can any one shed any light on this very very strange, please?

Best regards.
 
S

Silvar Beitel

Jan 1, 1970
0
Hello, I'm having some really strange SDRAM issues and hope someone
can point me the right direction - or at least help me understand the
cause of this..

We have some boards that have been working very well for several years
and we recently upgraded the standard SDRAM device (TSSOP) for one
with twice the capacity from a different manufacturer - the board is
designed to accommodate this size device.

We calculated the refresh/latency/page etc settings and all seemed
good. Except on a few devices where we see the following:

Written pattern: 0x5555aaaa
Read Pattern: 0x5557aaaa

On a failing board this is seen consistently at this one bit location.
We can manually read and write to this problem nibble and see that the
bit in error only gets set high when the bits either side of it are
set to '1', IE:

Written: b0000 Read: b0000
Written: b0001 Read: b0001
...
**Written: b0101 **Read: b0111
Written: b1100 Read: b1100
**Written: b1101 **Read: b1111

On different boards the problem appears at different bit locations.
The problem is made worse, with more boards exhibiting this problem,
when colder.

Can any one shed any light on this very very strange, please?

Best regards.

At voltage, temperature, process or timing extremes, all volatile
memory devices will exhibit pattern-sensitive soft failures. Signals
from adjacent rows or columns in the array can influence the state of
nearby bits. This isn't supposed to happen if voltage, temperature,
process variance and timing are all with spec, but it is economically
impossible to test all pattern combinations (although your particular
failure, if as consistent as you say, should have been caught with
simple tests commonly done).

In your case, I would:

a) Check the operating voltage. Raise it or lower it a bit if you can
and also look for any noise on the rails.

b) Try parts from a different manufacturer if possible.

c) Contact the manufacturer of the problem parts, explain the problem
in detail, and see if they're willing to try to duplicate it. If it
is a relative recent, high volume part, their design and/or test
engineers may be interested in helping you as it might uncover a
design flaw.

Good luck!
 
At voltage, temperature, process or timing extremes, all volatile
memory devices will exhibit pattern-sensitive soft failures.  Signals
from adjacent rows or columns in the array can influence the state of
nearby bits.  This isn't supposed to happen if voltage, temperature,
process variance and timing are all with spec, but it is economically
impossible to test all pattern combinations (although your particular
failure, if as consistent as you say, should have been caught with
simple tests commonly done).

In your case, I would:

a) Check the operating voltage.  Raise it or lower it a bit if you can
and also look for any noise on the rails.

b) Try parts from a different manufacturer if possible.

c) Contact the manufacturer of the problem parts, explain the problem
in detail, and see if they're willing to try to duplicate it.  If it
is a relative recent, high volume part, their design and/or test
engineers may be interested in helping you  as it might uncover a
design flaw.

It would probably also be a good idea to check out the control signal
timing. Every input to an SRAM has a set-up time and a hold time, and
no output is guaranteed stable until the defined propagation delay
from the appropriate input or inputs.

This is elementary stuff, but when I've had to work out why other
people's circuits are acting oddly the most common explanation is that
they've missed a timing constraint. I even did it once myself - by
assuming that the propagation delay through a couple of logic gates
was going to be too short to be a problem. Sod's law dictates that you
never meet the the problem on the prototype.
 
F

Frithiof Andreas Jensen

Jan 1, 1970
0
Can any one shed any light on this very very strange, please?

Best regards.

Maybe the manufacturer also upgraded the speed of the devices (i.e. faster
risetimes) and your layout is now moving into transmission line territory.
 
E

ehsjr

Jan 1, 1970
0
Hello, I'm having some really strange SDRAM issues and hope someone
can point me the right direction - or at least help me understand the
cause of this..

We have some boards that have been working very well for several years
and we recently upgraded the standard SDRAM device (TSSOP) for one
with twice the capacity from a different manufacturer - the board is
designed to accommodate this size device.

We calculated the refresh/latency/page etc settings and all seemed
good. Except on a few devices where we see the following:

Written pattern: 0x5555aaaa
Read Pattern: 0x5557aaaa

On a failing board this is seen consistently at this one bit location.
We can manually read and write to this problem nibble and see that the
bit in error only gets set high when the bits either side of it are
set to '1', IE:

Written: b0000 Read: b0000
Written: b0001 Read: b0001
...
**Written: b0101 **Read: b0111
Written: b1100 Read: b1100
**Written: b1101 **Read: b1111


On different boards the problem appears at different bit locations.
The problem is made worse, with more boards exhibiting this problem,
when colder.

Can any one shed any light on this very very strange, please?

Best regards.

Look for ringing on the data lines & at their termination
loading.

Ed
 
Top