RE: [SI-LIST] : differences in memory speeds

About this list Date view Thread view Subject view Author view

From: Zabinski, Patrick J. (
Date: Tue Mar 13 2001 - 12:43:32 PST


Thanks for the input. See comments inserted below.
> First, the OE rule: operator error. Were all solder joints
> examined and suspicious ones reheated? Was the failure isolated
> to a single part and, if so, was it replaced with the same results?
> A key bypass cap or filter could've failed open, or a trace could be
> marginal (fab error). Happens with more than 1 board?

Checked, double-checked. The failure is witnessed on all boards
(we have several), so we're confident it is not a problem with
soldering, bad cap, etc.

> If tests still fail...
> Perhaps the "dwell" at vdd/2 at the near end "pushes out" the
> effective access/write time such that the addr and/or data setup
> or hold time is no longer met due to increased 17ns part sensitivity
> to the write pulse threshold. This assumes a tight timing budget
> already and long lines relative to timing margin -- you didn't say.

Our read/write cycles are on the order of 100 nsec, and have
moved the timing around to ensure we have plenty of timing
margin, even with the pushed-out effective-edges.

> It seems you suspect write pulse is corrupted at the near
> end. The deasserting edge of the write pulse is the reference
> for setup and hold, so one of those could be violated.
> A contributing factor could be that a (previously undetected)
> marginal
> noise environment at one or more chips adds to the degraded
> timing margin
> for the faster part. This could include the chips own
> tendency to produce
> a larger gnd bounce due to its faster switching.

Again, I don't think it's a timing margin.

> The failure site(s) and which access is corrupted (read or write)
> must be found first. The ref. point for write setup/hold is
> where the
> pulse is stable at the Vin deassert level (like Vih)...
> An observation of the addr/data lines of the "failing" part(s)
> with a hi-BW scope seems required, using a looping test that
> generates failures. A late or metastable read output or violated
> write setup/hold may be observed.

I was suspecting metastability for a while, but I'm now leaning
away from it (see below for details).

> Also, observe VDD at the pin with a hi-BW hiZ probe w/ short
> gnd lead,
> using display persistence and correlate w/ errors (ie: same scope).
> I believe the gnd lead connection must be to the gnd plane directly,
> not to any chip's gnd pin, in order to see reality.

Here's some more info I just learned today.

We write each and every memory location with a logic zero.
We then try to read the same cells to ensure they come
back with a logic zero.

When we read the memory locations sequentially, we read a
proper logic zero at all sites.

However, when we read the addresses in a random-fashion
(i.e., skipping, jumping, etc. throughout the chip's memory
locations), we can get one of the output bits
to be stuck at a logic high (even though it should read
a logic zero).

We can toggle OE and the address bits while keeping CS and WE
steady, and the output bit remains high (when OE is enabled).

I'm trying to track down some details from the memory vendor,
but it almost seems as if the sense amps have some form of
latch that is getting into a metastable state. However, if it
was a metastability problem, I would think the circuit would
eventually get out of its stuck state and start outputting
a logic zero, but this never happens. The output stays stuck
at a logic one (until we read a different location).

This one has got me puzzled. We seem to have plenty of
timing margin, and the failure is repeatable under proper
conditions (address sequence), but I've never seen an output
remain stuck at the wrong level like this.


**** To unsubscribe from si-list or si-list-digest: send e-mail to In the BODY of message put: UNSUBSCRIBE
si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
si-list archives are accessible at

About this list Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Thu Jun 21 2001 - 10:11:11 PDT