So there were brainstorms...

But, obviously, development has been put on hold.

I get that 133MHz might require some better-designed circuitry, maybe a custom PCB; ground-planes, shielding, shorter traces, whatnot.

But I'm kinda surprised it seems to stop-dead at >30MHz.

The *method* of failure seems... unexpected.

Actually, now that I write this, it occurs to me that I had a similar failure, briefly, AT 30MHz. It seemed related to having the LCD attached, but experiments with different power-supplies, removing the LCD, and more, got it working, then putting it all back together *the way it was when it seemed LCD-related* still worked. So, maybe there's something there... the noise of the backlight-inverter...? Thermal effects on propagation-delays...?

Regardless, the actual *method* of failure seems... weird. It basically goes from stable/predictable to completely random. And, I can't seem to figure out any potential failure-point that would cause *complete randomness*. E.G. Sure, maybe, if the Chip Select multiplexer is too slow, the Chip Select signal might not reach full-on, which would result in writes that don't write, and reads that read floating pins. (Note that *delayed* chip-selects have been accounted-for in software). Sure, non-enabled-chip-selects would *seem* to result in utterly-random reads, as the pins would be floating... Then, consider, even if the read *command* was completely missed, the read process still continues, the data it should be receiving shouldn't be completely random, it should be the floating-values on the data-pins... Again, consider, it has been found in previous experiments, that when the data-lines are allowed to float, they tend to retain the last value written to them... (which would be and HAS BEEN the Read Command and its associated address, due to the fact that the data-lines are directly-connected to the command/address lines). That "Has Been" was at *lower* clock-frequencies, so seems reasonable to think it would be even *more* likely to store those values at *higher* frequencies... as... I believe it's capacitance that's causing the "floating" pins to retain their values...

And, unrelatedly: one must also consider that the memory has been holding previous values despite power-down, for *minutes* at a time, So read-commands that *do* go through (even if write doesn't), then, should be getting *something*.

I guess there're a few potentials in here... worth further consideration.

And then, the apparent link with the LCD display's being connected...? I dunno.

It's not like I'm jumping from 30MHz to 100MHz... these oddities appear at 40MHz, only 1/3rd faster. And even considering 1ns/6in of wire... worst-case-scenario we're talking differing propagation-times of 1ns due to wiring... routing some signals through other circuitry, while others go straight to the SDRAM. (neglecting the circuitry's delays, briefly, for this mind-experiment, see below). Then, of course, there's noise induced on nearby wires... it may *look* like a rat's nest, but in fact, I did consider the routing of the wires such that they shouldn't have much room for crossover.

These sorts of things, generally, in my experience, can lead to seeming randomness. But, they've been considered. And even the one-shots... even if *they're* too slow (which is possible) I still don't see *completely random* as the mode-of-failure.

So, it's on hold.