Re: 2114's ->RE: BattleZone probs....

From: Rodger Boots <rlboots_at_cedar-rapids.net>
Date: Mon Jan 18 1999 - 13:49:26 EST

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