When I compare the timing diagram between the lab sheet and the data sheet from MOSEL VITELIC, I find out that the timings for WE and OE signals are different. In the lab sheet, WE and OE change simultaneously but in the data sheet, WE and OE change at different clock edge. So, which timing should we follow?

Furthermore, when a refresch cycle is takeing place, what signal should we put on the bus to indicate this to the CPU? Should we allow the CPU to wait and then do a read/write operation after the DRAM is ready (If so, what is allowed waiting time range?)or should we raise AS and let CPU to decide what to do next?

-- Roy Leung (roy.leung@utoronto.ca), January 29, 1999

Answers

I'm not a TA, but might I make a suggestion: If you're given data sheets (specs) for a particular device you're designing for... USE IT!!! They're (almost) always the source for the correct info if there's a conflict between it and problem specs.

-- Vincent Lo (vincent@refreshed.com), January 30, 1999.

As Vincent said, the data sheet is 'always' right. (Or at least if it is wrong, that is the best you are going to do.)

For your design, remember that you are doing things synchronously at 100ns per clock. In the data sheets you will see that signals will have specs like 30-45ns minimum separations, but you cannot generate anything less than 100ns. If one signal has to be asserted before another one, then the minimum time chunk you have to work with is 100ns, so you shouldn't be anywhere near the minimum specs.

Also, if you look at the spec sheets, and you see that WE and OE don't change at the same time, are there any bars showing timing constraints for these two edges? If not, then that just happens to be how they drew the diagram: there may not be any constraint implied. The timing diagrams contain a lot of information, but it is very dense, so make sure you know what *is* there as well as what *isn't*.

The CPU knows nothing about refresh. There is no signal that you can assert that tells the CPU to 'not ask for anything right now'. You do not control /AS (it is an input), so you can't do anything to it.

If you look at the 68K bus timing diagrams, the CPU makes a request by putting out /AS and the address. After 'some time', a slave should assert /DTACK. If the slave needs more time for whatever reason, all it has to do is hold off the assertion of /DTACK. The CPU will just sit with /AS and the address asserted until it gets an answer, or an external (long) timer decides it has waited too long and generates a BUS ERROR. But your controller should be able to handle a refresh, then get back to the CPU's request long before a BUS ERROR timeout occurs. So just let the CPU wait.

Robin

-- Robin Grindley (grindley@eecg.toronto.edu), January 30, 1999.