He was probably pretty close. The problem isn't the RAM,
it's in what it's connected to (in this case the processor).
The processor wants valid data to be present for a few
nanoseconds AFTER the end of a read cycle and if the
data goes away during that time (to to the RAM being
deselected) the processor ends up latching the wrong
data.
At my Real Job a few years ago I had to figure out why
some newly built units were showing scrambled data on
the display. What I found out was that they had replaced
the original (obsolete) RAM with some new (incredibly
fast Cyprus) RAM. The system had a built-in 12 nS
glitch on the write line that the old RAM ignored. But
12 nS was a perfectly valid write for the new RAM.
And the glitch happened when the data wasn't valid.
jwelser@ccwf.cc.utexas.edu wrote:
> On Mon, 18 Jan 1999, Anders Knudsen wrote:
>
> > A reason the faster 2114 may be due to faster setup/hold times of the ram.
> > That is, now you have a ram chip with a faster setup time, but more
> > importantly in this case a faster hold time. So if the hold time is too
> > fast, the data out may not be on the bus for a long enough time for other
> > devices on the data bus. I havn't looked at the schematics, but it's
> > conceivable that one could replace the other devices with faster ones,
> > along with the faster rams, to compensate for the reduced hold times. It
> > should be easy enought to trace the ram data path and find which device(s)
> > (be they tri-state buffers, or whatever) are being affected by the reduced
> > hold time of the faster rams.
> >
> > -----------
> > a n d e r s
> >
>
> I think you're confusing hold time with ehhhh, something else....
>
> Hold time is the time required after some edge for some signal
> to be stable.
>
> For example, there might be a spec on the Data input, with respect
> to the Write Enable input, meaning that the Data must be held, even after
> the write enable is de-asserted.
>
> I think you're confusing hold time with transition time, but in
> this context, I don't see how even that would be a problem. Shorter setup
> and hold times will only help things. In practice, hold times are usually
> very small, and often negative (for registers, for example.)
>
> Maybe I totally missed what your were getting at though....
>
> Joe
Received on Mon Jan 18 13:22:38 1999
This archive was generated by hypermail 2.1.8 : Fri Aug 01 2003 - 00:31:14 EDT