Observing the 10ns read hold time with fast SRAMs

[Aaron]

Sooooo...

I created the following thread a couple of weeks back regarding building an NES music player:
viewtopic.php?f=12&t=5099

I set off down this path with high hopes, but as soon as I got to where I was dumping music to play, I found that far too many of my favorite game tunes used the 2A03's delta modulation feature (sampled audio), making the ever-so-wacky diode matrix approach problematic.

I took a detour and decided to build the Arduino-to-2A03 interface using a dual-ported SRAM. I'll be using a larger one next, but for starters I'm using this 1k x 8 SRAM:
https://www.idt.com/document/dst/713040-datasheet

My request of the wise: How best to provide for the 10ns read hold time? My immediate thought is to generate the SRAM's /OE signal by simply NAND-ing the 2A03's Phi2 and R/W signals, and to generate the SRAM's R/W signal by NAND-ing the 2A03's Phi2 and the NOT of the 2A03's R/W, but when I look at the timing diagrams of both ICs, and consider that the datasheet for the 74HC00 doesn't say much about *minimum* propagation time, I become concerned that this approach, if it works, will be...fragile. Am I again worrying about nothing? Or should I be sticking a large even number of NOTs in there to introduce delay?

Thanks in advance (again) for thoughts/advice!

[BigEd]

Hmm, I see 'provide for' and 'OE' and I wonder if you're thinking what I think you might be thinking.

As it's a dual-port RAM, you've got the timings on two ports to worry about, and possibly both for reading and writing. But TOH isn't a constraint, it's a behaviour.

It looks like to me like TOH is what the SRAM chip does, not what it requires. So the question is whether such a hold time is enough for the device reading the SRAM, which is to say, the CPU (presumably?) - so you should be worried if the PHI2 clock is going to go low rather late compared to the trailing edge of RnW and CE. That probably isn't going to be worrying if those signals are derived from PHI2, because then they will surely lag the clock.

For the writing-to-SRAM, it looks like TDH is the constraint your system needs to obey, relative to either CE or RnW. But I would guess, putting a fast RAM into a slow system would make this an easy constraint to meet.

Hope this helps.

[GARTHWILSON]

Do you have 74LS logic in there? If a line has only CMOS (which essentially presents zero DC load), the capacitance on the line (a few pF per pin) holds the data plenty long after the line is no longer being driven. I'm not talking about just nanoseconds or even microseconds. When I was making the tester for the 4MB SRAM modules shown on the front page of my site, I happened to observe the undriven lines holding the data for milliseconds. I did not experiment to find out how much further I could go with it. My point however is that you don't have to worry about a lack of hold time if there's no 74LS or other DC load on a line.

[Aaron]

Thanks guys. My particular concern (which may not be the correct concern!) is the parameter called THR in the MOS/Commodore datasheets--the 10ns period that begins when Phi2 falls to .4V during which the data being supplied to the 6502 is expected to remain valid.

To answer Garth Wilson's question: No, there is no 'LS' logic in there. The SRAM is connected directly to the 2A03. So what you're saying is: Because of this, when the /OE on the SRAM goes high and the data lines begin their transition to a high-Z state, the logic levels on them will decay at a sufficiently slow rate than the 10ns THR time is not a concern ... ? Of course, the datasheet for the SRAM does not declare a minimum transition time.

In any case, it does seem to (mostly) work. Here's a short video of the thing:
https://www.youtube.com/watch?v=UM9OqdAa4GA

I'll be tearing it apart tonight and rebuilding it with a larger SRAM. (And also using the Arduino's memory interface instead of bit-banging it like I'm doing right now.)

Unrelated to the question of the thread, but I'll mention it anyway: One of the problems I'm having is that, seemingly randomly, the 2A03 will not come out of reset. The bus remains high-Z, although Phi2 is oscillating at the correct frequency. The reset signal on the 2A03 has a pull-down resistor on it, and then the Arduino pulls it up after it's loaded the SRAM with the 6502 code. I've got an Epson programmable MEMS oscillator part supplying the clock for the 2A03, and it's got a rather nasty-looking waveform. I'm wondering if that could be the issue? Maybe I'll follow it with a Schmitt trigger inverter and see if that helps. The duration of reset doesn't seem to matter. I can hold it in reset for seconds, and still, perhaps one out of five times, it won't come out of reset when the reset signal goes high. Nuts!

[BigEd]

A clean clock input is a very good idea. It's not uncommon to start with a 2x clock, so that the conditioning includes a divide-by-two, which assures a 50/50 duty cycle.

[GARTHWILSON]

Aaron wrote:

So what you're saying is: Because of this, when the /OE on the SRAM goes high and the data lines begin their transition to a high-Z state, the logic levels on them will decay at a sufficiently slow rate than the 10ns THR time is not a concern ... ?

Right.

Quote:

I've got an Epson programmable MEMS oscillator part supplying the clock for the 2A03, and it's got a rather nasty-looking waveform. I'm wondering if that could be the issue? Maybe I'll follow it with a Schmitt trigger inverter and see if that helps.

The clock signal is more critical than any of the others for cleanliness.

Be sure to have read through the 6502 primer. (Maybe you have already. I don't remember if you've said.) It was written after our years of seeing the same problems and questions come up over and over on the forum.

[Aaron]

GARTHWILSON wrote:

Be sure to have read through the 6502 primer. (Maybe you have already. I don't remember if you've said.) It was written after our years of seeing the same problems and questions come up over and over on the forum.

Thank you! I remember cruising down this a couple of months back but had forgotten where I'd seen the discussion of oscillator circuits. Very useful indeed.

Relatedly: I dug into my parts bin last night and was unable to find my 74HC14's. So, as I've done an embarrassing number of times lately, I ran to DigiKey to order more of something I know I already have...somewhere. I'll be pursuing the oscillator dirtiness theory as soon as UPS shows up with the goods!