Hi James,
It's the time to process a miss or the time to process a read in the absence of data cache.
I feel like I completely understand your explanation, but I still don't see what it has to do with the worst case time to access sdram.
Forget cache, how long does it take to for an address to show up on the avalon bus and then how long does it take for the sdram to place the requested data back on the bus?
Am I misreading the sdram datasheet? They just show address and chipselect activating and data being placed on the bus in just a few clocks. The number of clocks is equal to the CAS setting for accesses to the same row. (ie. figure 8 "Random Reads" in MT48LC4M32B2 datasheet)
So stalled/cached/queued or not, once the Avalon bus puts out the address and selects the sdram responds in CAS clocks with the result.
So that's 3 clocks with CAS3 setting. Now where are the other 9 clocks coming from? Dirk's scope shots show 12 clocks between back to back reads on the same row. The cpu stalling until the result is returned is fine, because the code needs that result to continue. I'm just not seeing the justification for a 12 clock stall to read a non-cached word from sdram.
Thanks,
Ken