6502.org

Hello everyone, I feel this might be a newbie question so I wanted to ask here. This is leading directly from my post here: viewtopic.php?f=4&t=7407&start=30#p98189

Here's the situation: I seem to have a VERY fast SRAM chip, AS6C62256 32KB. Here is the datasheet: https://www.alliancememory.com/wp-conte ... rev1.2.pdf

According to the datasheet, if /WE is held low, it needs a minimum of 45ns to write when /CE falls. What I am doing (essentially) is having /WE rise while /CE falls at (essentially) the same time. On this chip, I am getting a write. The /WE pin is not ever floating, nor the /CE pin. 45ns MINIMUM. I am pretty sure that my design does not have that happening. Could be wrong.

Could this/these chip(s) latch or hold the /WE signal for longer than intended? Could it see me bringing /WE low as "you want to write, just give me the /CE signal" and instead of acting like an "active low" it instead acts like "falling edge" to write?

This particular 62256 chip I have has been known to be super fast. When using other SRAM chips I haven't needed to qualify /WE with more than PHI2. But with this particular chip I have needed to qualify /WE to the second-half of PHI2. But this current behavior is just strange to me.

Is there any way to test the actual speed of this chip with a TL-866II Plus programmer + 'minipro' perhaps?

Thoughts?

Thank you all.

Chad

You should read the minimum 45nS write pulse width as "the manufacturer will guarantee a correct write operation across all voltage and temperature range if pulse is 45nS or longer". It does not mean a write won't happen if pulse width is shorter than 45nS. This gives the manufacturer the freedom to speed up their process without violating the published spec. It is common to do "die shrink" to make device smaller thus yielding more devices per wafer; die shrink also speed up a device significantly. Also remember the 45nS spec is across all temperature and voltage (2.7V-5.5V). You are operating at high end of the voltage, 5.0 and room temperature, so expect your RAM to be much much faster than 45nS. Furthermore, you are concerned about write corruption which can occur with shorter pulse than valid write. Adding all these together, you can have a device responding to write corruption with pulse width under 10nS, even shorter, probably.
Bill

This is how long you should hold them low concurrently to assure a stable write. It doesn't mean that shorter times won't write, or won't have nasty side effects which is also possible.
In an analogue world, nothing ever really happens simultaneously. If you initiate a rise of /WE at the "same time" as a /CE fall, then they will both be transitioning together, and may very well both be below a threshold for a period of time, and the rate of transition will depend upon things like how many devices are connected to that net, trace capacitance, etc.

For things which are level-triggered like this, it is best to try to ensure both signals are high for at least a short period.

FWIW I strongly suspect that memory chip manufacturers are not really charecterising their chips very carefully, at least for these legacy parts, and the datasheets mostly look like generic "this is how standard memory works" specifications rather than anything specific to the individual chip.
No I don't think it's latching anything deliberately, that's against the standard protocol for these kinds of chips as implemented by a variety of manufacturers. It's more likely that the transitions take a while both in the wires and inside the chip itself and it needs a little breathing room between these transitions to guarantee it doesn't see an overlap.
Typically you qualify /WE with PHI2 but /CE should transition as soon as the CPU puts an appropriate address on the bus (plus your decoding logic). In cases like my video circuits where CE can't transition until PHI2 starts, I delay /WE until at least halfway through PHI2 so that the address decoding has a chance to settle down first as that too can spuriously activate random components very briefly while the address lines are transitioning.
I'm not sure, even if there was though I wouldn't advise it except for interest's sake - you should make your design more conservative, and it will then deal better with ranges of temperature, replacement components, wear and tear, and other additions to the circuit. (Not that I always get that right! But this is what I've learned.)

Hey Chad,

Here are a couple of threads you might find useful. This one in particular is solid gold. You might want to start with Adrian's post on page 10, but the whole thread is worth reading. There are particularly good posts from BDD on page 7 and SamCoVT on page 9.

#1 - "Strange memory write problems:" viewtopic.php?f=12&t=7371&start=135#p96774
(direct link to Adrian's post on page 10)


#2 - " Slower SRAM works but fast doesn't????:" viewtopic.php?f=4&t=5180

Chad, I agree with plasmo that you seem to be misinterpreting the meaning of the access time or minimum write pulse width.

I see two kinds of write cycles described in the datasheet: one where CE is already low and then WE goes low, and the other where WE is already low and then CE goes low. I don't see any constraints about a minimum time from CE going high to WE going low, but it sounds like you've violated an unstated constraint: most likely the chip has seen the low-going WE with CE already low and started an internal write cycle. (Write Cycle 1 in the datasheet)

It's important to understand that memory chips are not combinatorial: they are internally clocked, sensing changes in address pins and/or control pins, detecting what looks like the start of an access and then going through some sequence of internal operations. So, it seems, you need your design to be quite decisive about which kind of supported access it is that you're trying to do. In your case, you have a race condition as WE and CE both change together.

Thank you all for the responses.
Thank you, I read through a lot of it near the end.
As I use your basic design, same goes for me.
And that was what I was mistaken. I see now, makes complete sense.
Indeed. It does seem like I have a race condition. That is very concisely what is going on.

Now I just need to consider how to 'fix' it. But that will be a whole different topic or a whole different day. Thank you all for the clarification. This helped a lot!

Chad

One thing to note about datasheets: there are two kinds of numbers within. One type is a constraint: something which you need to do, if you want things to work. The other type is more like a promise: this is what the chip will do for you, if you treat it right.

In this case, the access time is a promise, but the WE pulse width is a constraint.

I'll disagree with that interpretation. Page 6 of the above linked datasheet shows 2 timing diagrams - one for /WE-controlled write and the other for /CE-controlled write indicating that either option is supported.