[En-Nut-Discussion] SRAM speed

[ethernut at dotaussie.com.au]

Firstly, don't get me wrong - the Ethernut seems more stable than the
Windows machine that is being used for it's development! But I am looking at
the 'limits' of some things...

I was looking at this before, but I still can't see how the Ethernut
satisfies the timing requirements for the external SRAM accesses. I see that
many people are using 70ns SRAM with fast AVR, but I can't see how it is
"guaranteed" to work. It looks quite close, but could there be potential
problems at the ends of the temperature ranges? Or maybe I miss something in
the datasheets....

eg.
Assuming ATmega running at 14.7456Mhz, then tCLCL=67.8ns

for read cycle:

ATmega Datasheet:
-----------------
tRLDV = RD low to data valid must be a maximum of tCLCL-50ns = 17.8ns

tDVRH = data valid to RD high must be a minimum of 40ns.

SRAM Datasheet:
---------------

tAA time from address changing to data valid will be max 70ns

time from CS to output is max 70ns. Since address line A15 goes straight in
(and no propogation delay for high byte address), then this parameter is the
same as tAA. But if added a GAL or other address decoding, the propogation
delays would be an issue.

tOE is max 35ns, so data will be ready max of 35ns after RD goes low.

Doesn't this conflict with tRLDV requirement, that data be valid withing
(tCLCL-50)=17.8ns ?

Also, since tCLCL is 67.8ns, and the data will be ready within 35ns, this
only leaves a guaranteed (67.8-35) = 32ns of data valid time until RD will
go high. But tDVRH (time between data valid and when RD is allowed to go
high) requires minimum of 40ns in ATmega datasheet.

It all seems so close, and since the manufacturers of these chips will have
allowed themselves some leeway, I can see why it would work almost all of
the time (also they are probably re-badging faster SRAM, which could help
too).

But to guarantee performance, wouldn't it be necessary to have a SRAM chip
that can supply valid data within 17.8ns of RD going low? The 55ns version
of the samsung part gets down to 25ns for this parameter, but still need a
little faster it seems.

Alastair