From: John Lipsius ([email protected])
Date: Tue Mar 13 2001 - 12:11:35 PST
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?
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.
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.
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.
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.
> -----Original Message-----
> From: Zabinski, Patrick J. [mailto:[email protected]]
> Sent: Monday, March 12, 2001 7:00 PM
> To: [email protected]
> Cc: Zabinski, Patrick J.
> Subject: [SI-LIST] : differences in memory speeds
> To all:
> We designed a system around asynchronous SRAM memories with 20 nsec
> access times. When we put the system together, it worked
> For several reasons, we ran short of the 20 nsec parts, and we
> were forced to populate subsequent boards with 17 nsec parts.
> The two parts are stated to be "identical" with the
> exception of the different access times (i.e., they share
> a common data sheet, part number, mfr, package, etc.; they
> simply have different speed ratings).
> When we populate our system with the 17 nsec parts, the
> system fails, and we are trying to understand the differences
> between the two different speed parts. Any clues?
> For background, the memories are part of a daisy chain
> net that is driven by a source-series terminated source.
> The driver's output impedance roughly matches that of the
> line, so the initial signal out of the driver rides at
> about VDD/2 until the reflected wave makes its way back.
> The memory parts at the far end of the line work fine,
> while the parts at the near (driver) end of the line
> are the ones having difficulty. Our suspicion is that the
> initial pulse is too close to threshold for the 17 nsec
> parts, which is causing the problems. However, the
> 17 and 20 nsec parts are spec'd to have the same
> Even if the two parts did have different thresholds, because
> they are asynch SRAMS (i.e., supposedly not edge-triggered???),
> riding at/near threshold should not theoretically be
> a problem.
> Anyone out there tell me where I'm off in my thinking,
> experience something similar, or have some insight to
> the differences between the 17 and 20 nsec parts (other
> than access time)? I tried to simulate the difference,
> but the two parts use the same spice models.
> P.S. Are different speed memories designed/fab'd differently,
> or are they simply 'binned' depending upon effective
> resulting wafer lot process parameters?
> **** To unsubscribe from si-list or si-list-digest: send e-mail to
> [email protected] 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 http://www.qsl.net/wb6tpu
**** To unsubscribe from si-list or si-list-digest: send e-mail to
[email protected] 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 http://www.qsl.net/wb6tpu
This archive was generated by hypermail 2b29 : Thu Jun 21 2001 - 10:11:11 PDT