SRAM latching /WE?

[sburrow]

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

[plasmo]

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

[gfoot]

sburrow wrote:

According to the datasheet, if /WE is held low, it needs a minimum of 45ns to write when /CE falls.

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.

Quote:

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.

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.

Quote:

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?

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.

Quote:

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.

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.

Quote:

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

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.)

[Paganini]

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

[BigEd]

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.

[sburrow]

Thank you all for the responses.

Paganini wrote:

Here are a couple of threads you might find useful.

Thank you, I read through a lot of it near the end.

gfoot wrote:

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.

As I use your basic design, same goes for me.

plasmo wrote:

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.

And that was what I was mistaken. I see now, makes complete sense.

BigEd wrote:

In your case, you have a race condition as WE and CE both change together.

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

[BigEd]

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.

[BigDumbDinosaur]

BigEd wrote:

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

I disagree on part of that. The SRAM in question here is specified by Alliance to be a 55ns part. Alliance guarantees, not promises, it will respond to an access request within that time period if setup conditions stated in the data sheet are met. What is not guaranteed or even implied is the earliest time after /CE and /OE or /WE have settled that the device will respond.

From what Chad seems to be describing, this is nothing more than a glue logic timing race, or reliance on a behavior that cannot be trusted. Something that needs to be understood in the latter context is this quote from the Alliance data sheet:

• To avoid bus contention, external devices should drive I/O pins only after outputs have been disabled with output enable (OE) or write enable (WE).

I interpret that statement to mean Alliance is telling you to use /OE or /WE to gate read/write access, not /CE.

[pjdennis]

BigDumbDinosaur wrote:

From what Chad seems to be describing, this is nothing more than a glue logic timing race, or reliance on a behavior that cannot be trusted. Something that needs to be understood in the latter context is this quote from the Alliance data sheet:

• To avoid bus contention, external devices should drive I/O pins only after outputs have been disabled with output enable (OE) or write enable (WE).

I interpret that statement to mean Alliance is telling you to use /OE or /WE to gate read/write access, not /CE.

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.

[BigDumbDinosaur]

pjdennis wrote:

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.

Yes, a /CE-controlled write is an acceptable procedure—I didn’t say it wasn’t. However, timing is different for a /CE-controlled write than for a /WE-controlled write. Assuming /CE is asserted as soon as a valid address is on the bus and only /WE is qualified by Ø2, the result will be faster overall response and more timing headroom.

Using a /CE-controlled write opens the door to a timing glitch at the fall of the clock should /CE be deasserted before /WE, something which is implied in the notes below the write timing diagrams. As this SRAM, and others like it, are designed for use on Intel or Zilog buses, not 6502 buses, reliable operation will occur if control input timing in a 6502 system replicates what would be seen in an Intel or Zilog system. Taking a decoding shortcut in order to minimize chip count or reduce the amount of work required to figure out the glue logic can lead to subtle timing issues that can challenge one’s patience. Been there, done that in POC V1.0.