From: Scott McMorrow (firstname.lastname@example.org)
Date: Mon Mar 12 2001 - 21:25:10 PST
There are many possible answers to your question, of course.
First, we'll discuss the difference in SRAMs. In general, the difference
between a 20ns and a 17ns part would be the bin split, if they are produced
from the same stepping. Thus, the difference is process variation. However,
it is possible that the 17ns part is produced from a new process shrink. Since
the spice model is the same for both parts, this is probably not the case.
Second, even though the devices are not "edge triggered", it is highly possible
that the input amplifiers for the SRAM array and the sense amplifiers are
quite sensitive and may be susceptable to signals which hover around the
threshold regions. There could be a plateau in the input delay time and
device access time when an input ledge is schmooed around the threshold.
(Rich Melitz of Intel hasa very nice presentation regarding this phenomena.)
Third, the spice model may not be accurate. I know this is blasphemy for
those who are spice inclined, but often the input structures, and especially
the input ESD structures are not well modeled. You may see threshold
failures which the model does not predict.
Fourth, our normal design practice for asynchronous strobe lines and address
lines for SRAMs at SiQual is to route them as balanced H-tree topologies, such
that all inputs are at the end of the line. With good driver and source termination selection
this will guarantee clean transitions across the threshold region.
Fifth, your package model may not fully account for the dynamic switching
currents and crosstalk which occur when the memory core and/or I/O switches.
It is likely that actual strobe failure occurs due to power and ground bounce, which is
worse for a fast process part.
To verify that the failure is due to input threshold violations, you can do the
1) use a heat gun to locally heat the devices which you believe are failing, without
changing the temperature of the driver. You should see a reduced number of
2) use freeze spray to locally cool the devices which you believe are failing, without
changing the temperature of the driver. You should see an increased number of
3) Use freeze spray to locally cool the driver, without changing the temperature of
the receiver. This will increase the drive strength and speed of the driver, and
should push the first incident pulse beyond the threshold area and allow the system
My guess is that your design is on the marginal edge for the original devices that you
used, and now a change of process has pushed it over the edge. Once you
root cause the problem, my guess is that you will need to redesign this circuit to
eliminate the first incident ledge.
-- Scott McMorrow Principal Engineer SiQual, Signal Quality Engineering 18735 SW Boones Ferry Road Tualatin, OR 97062-3090 (503) 885-1231 http://www.siqual.com
"Zabinski, Patrick J." wrote:
> To all: > > We designed a system around asynchronous SRAM memories with 20 nsec > access times. When we put the system together, it worked > great. > > 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 > thresholds. > > 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. > > Thanks, > Pat > > 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@example.com. 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 firstname.lastname@example.org. 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