6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Tue Nov 12, 2024 8:54 am

All times are UTC




Post new topic Reply to topic  [ 10 posts ] 
Author Message
 Post subject: SRAM latching /WE?
PostPosted: Wed Feb 08, 2023 1:02 pm 
Offline

Joined: Sat Oct 09, 2021 11:21 am
Posts: 718
Location: Texas
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


Top
 Profile  
Reply with quote  
 Post subject: Re: SRAM latching /WE?
PostPosted: Wed Feb 08, 2023 3:07 pm 
Offline

Joined: Fri Dec 21, 2018 1:05 am
Posts: 1114
Location: Albuquerque NM USA
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


Top
 Profile  
Reply with quote  
 Post subject: Re: SRAM latching /WE?
PostPosted: Wed Feb 08, 2023 3:16 pm 
Offline

Joined: Fri Jul 09, 2021 10:12 pm
Posts: 741
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.)


Top
 Profile  
Reply with quote  
 Post subject: Re: SRAM latching /WE?
PostPosted: Wed Feb 08, 2023 3:28 pm 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 490
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

_________________
"The key is not to let the hardware sense any fear." - Radical Brad


Top
 Profile  
Reply with quote  
 Post subject: Re: SRAM latching /WE?
PostPosted: Wed Feb 08, 2023 6:39 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: SRAM latching /WE?
PostPosted: Wed Feb 08, 2023 7:00 pm 
Offline

Joined: Sat Oct 09, 2021 11:21 am
Posts: 718
Location: Texas
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


Top
 Profile  
Reply with quote  
 Post subject: Re: SRAM latching /WE?
PostPosted: Wed Feb 08, 2023 8:34 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: SRAM latching /WE?
PostPosted: Thu Feb 09, 2023 3:52 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8482
Location: Midwestern USA
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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: SRAM latching /WE?
PostPosted: Thu Feb 09, 2023 3:33 pm 
Offline

Joined: Fri Apr 15, 2022 1:56 pm
Posts: 47
Location: San Antonio, TX, USA
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: SRAM latching /WE?
PostPosted: Thu Feb 09, 2023 4:45 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8482
Location: Midwestern USA
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. :D

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: