1. Home
  2. Electronics Design
  3. Strange SDRAM problem - Influenced bit corruption

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.

Reply to
junk
Loading thread data ...

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!

-- Silvar Beitel (former memory chip designer)

Reply to
Silvar Beitel

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.

-- Bill Sloman, Nijmegen

Reply to
bill.sloman

skrev i en meddelelse news: snipped-for-privacy@34g2000hsf.googlegroups.com...

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

Reply to
Frithiof Andreas Jensen

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

Ed

Reply to
ehsjr

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.