Are you talking about latency, or about whole cycle time (tRC) ? That's two very different things. Latency in SDRAM is measured in cycles, not in time. So, for example, total latency from ACT command is 4 cycles. At 133 MHz that would be half the time than at 66 MHz (30ns vs 60ns). This is your critical timing since the CPU asserts AS until it latches the data bus.Badwolf wrote: 13 May 2022 16:59 Also, but irrelevantly to what I said, clocking the SDRAM faster doesn't help at all with 68000. We don't have a burst mode or any kind of cache to fill!
What's the random column access time of an SDRAM chip at 133MHz versus my chip at 66MHz? I'll tell you: it's (virtually) the same.
Now, the command period (tRC) is 60ns in either case. That means you can't access two random locations at less than 60ns apart. So what? That's the time from one full 68K bus cycle to the next one, which takes 4 clock cycles. With a CPU clocked at 32 MHz it's 125 ns. So this timing is not really critical. Even with the CPU at 64 MHz, it is still ok.
Ah, you are saying that some RAM speed always goes to waste? (sorry for the misunderstanding) Yes, of course, well, unless you can use the RAM concurrently for something else. Not sure why you would care as long as it doesn't affect price significantly?I've said with ANY RAM, because of the way the 68k latches data after DTACK, there will come a point where you either have to optimise for a clock speed or accept you will never achieve your theoretical ram speed. SDRAM, SRAM, DRAM, manually assembled banks of flip flops.
