Using async SRAM in homebrew CPU

Question

I am building a homebrew CPU and have now reached the point of designing the SRAM part. I plan of using a simple 32K x 8bit static RAM (such as the Cyprus CY62256N). My concern is that the part is asynchronous but I want it to act like a synchronous part.

In the the rest of my design, registers are written to on the rising edge of the clock with the required new value already on the data lines. During the rest of the clock period the new instruction is processed and a new value might be placed on the data lines. This is fine because the register only updates on the rising edge and not later on, even though the clock happens to still be high.

I presume this approach will not work with asynchronous SRAM. I am concerned that the rising edge of the clock will update the SRAM, but if the clock happens to still be high when the value of the data lines is updated for the next instruction it will cause another update that is not wanted.

Is there some common technique to achieve what I need?

Answer 1

Generally, any real part will have what can be considered to be a contamination delay which is the propagation delay between a change at the address or control input, until the old values of the outputs cease to be valid and begin to transition towards a new value, quite likely through various invalid intermediates.

If you can ensure the the driving of the address and control outputs from the processor happens at a closely related time (or even after) the latching of inputs from the memory, a finite contamination delay will likely ensure that you receive valid values.

However, keep in mind that a typical synchronous memory imposes an extra clock's pipeline delay, while an asynchronous memory will only have propagation delays. Adding an extra pipeline register on the address lines would make an asynchronous memory act more like a synchronous one - at least as long as it makes timing.

Answer 2

SRAM is like a transparent latch. When a write cycle is in progress (CE and WR are low) the data on the bus will be stored in the RAM at the current address. During this time the address lines must be stable, or else multiple memory locations could be written to. At the end of the write cycle (when WR and/or CE goes high) the RAM continues to hold any data that was stored in it.

Just as with a clocked register, you must meet the RAM's address and data setup times. However SRAM is much slower than a typical register, so its access time will probably extend well into 'the rest of the clock period'. If your address and/or data lines are only valid just before the clock rising edge then you could latch them and start the write cycle on the rising edge, then terminate the write cycle at some later time (eg. when the clock goes low). Of course you will not be able access the RAM again until the current write cycle is finished.

Answer 3

I'm attempting to solve this issue by only pulling /wr down when the clock is low.

           _______         _______         __
clock    _/       \_______/       \_______/

/fetch   ___                 _______________ 
enables     \_______________/               \

/instr.  _________         __________________
latch             \_______/    

/execute     _______________
enables  ___/               \_______________/       

/execute _________________________         __
latches                           \_______/
(inc. /wr)

I do this by using the clock as the high bit on a BCD decoder and only using outputs 0-7. I get 3-bit instruction destination decoding and short latch periods from one IC.

The enable signals are delayed by a counter and logic gates.