It almost seems as though the SDRAM clock could be strobed whenever I so-desire... which would *REALLY* simplify the danged thing. Could probably get rid of one-shots altogether, dagnabbit!

DDR SDRAM has a "DLL" which, as I understand, is similar to a PLL... Further, the DDR chip-specs I looked up specify that operation without the DLL is not an option (even though action must be taken to enable it). The main point being: The DLL requires the clock-rate to be *stable*. In fact, it takes something like 200 stable-clock-pulses to synchronize before you can even use the DDR SDRAM... and changing the clock-frequency requires first putting the device in standby, then a resynchronization... It doesn't seem particularly easy to change the clock-frequency of DDR, and arbitrary pulse-durations seem to be out of the question.

Again, I designed sdramThing, from the start, with DDR in mind for the future... Was reading the manuals side-by-side throughout most of the design of sdramThing, and intentionally put some limits on the design based on what was possible with DDR. SDR SDRAM was proof-of-concept, at that point... since it's easier to work with, especially voltage-levels and the ability to run at the lower-clock-frequency.

Though, I have taken advantage of some SDR SDRAM features that aren't available in DDR... Mainly, the long bursts: SDR can do bursts of an entire page (usually 512 or 1024 words), whereas DDR's longest burst is EIGHT words. That... would definitely require some careful-timing when connected to something like an AVR... especially considering it's DDR (so 8 data-words is only 4 clock-cycles), and considering the minimum clock-frequency of 85MHz.

That part, the short-burst-length, is a big kicker which I have yet to wrap my head around... I'm pretty sure it'll work in Free-Running, but actually loading the DDR with those initial free-running commands is... questionable. The obvious option is a bunch of latches, but I figured I'd come up with something else somewhere down the sdramThing line, but haven't yet.

And, since I haven't achieved anything above 30MHz, yet, I figure ddrThing is still quite a ways off (and, frankly, unnecessary for most of my needs).

So, per recent log-entries, I've been contemplating another SDR feature that's not available in DDR: the ability to use CKE dang-near arbitrarily, especially during a read/write burst...

And... I've been contemplating clock-switching... E.G. load the initial commands while running off the AVR's clock, then switch over to the SDR's clock once it's loaded. This'd definitely reduce/remove the need for CKE... But, then, it occurred to me, again, that e.g. a Raspberry Pi wouldn't provide a determinable clock/instruction rate, so we're back to needing CKE.

Right... But then, it would seem from what I've read, the SDRAM's clock doesn't necessarily need to have a steady-rate in most cases. It almost seems as though, in many cases, the clock could be strobed whenever one pleases... Which could *completely* remove the need for CKE and one-shots altogether.

.... and, then there's this, which I hadn't come across in all my reading today, as a note-number that isn't even noted in the "NOTES" column of the table it's under... And somehow just happened to be centered in the PDF-window when I went to copy something else to put right here... (weird).

The clock frequency must remain constant (stable clock is defined as a signal cycling
within timing constraints specified for the clock pin) during access or precharge states
(READ, WRITE, including tWR, and PRECHARGE commands). CKE may be used to reduce
the data rate.

The part I was going to *look for* is that bit in the parentheses, which is *all over* the document:

(stable clock is defined as a signal cycling within timing constraints specified for the clock pin)

And, what I was about to say, was that the only timing-constraints I can find for the clock-pin are minimum-values for clock-high and clock-low, etc. Nothing regarding a specific frequency, nor about the high/low widths needing to be any particular duty-cycle (until that friggin' note, above, popped-up).

Alright, weird. So, the gist is that CKE is necessary, again.

-------------

Wherein, it's a bit of a relief I found that, since what I've been working on all day is to see if there's a way I can emulate the one-shot circuitry *with* an SDRAM chip...

The Free-Runner uses half a DIMM, but actually only uses three of the four chips. It uses half because that's how the Chip-Selects are separated on a DIMM. So, I could plausibly pop one chip-select and reroute it for this new purpose. (Alternatively, maybe, there'd be benefit from having two DIMMs serving different purposes).

One discovery that *could* be useful: If you start it *just right* you can alternate DQM pulses with every-other read-output (e.g. in a burst)... Not exactly sure *how* it'll be useful, but it might be. E.G., maybe, to have two separate free-runners running side-by-side... plausibly running two entirely different state-machines that needn't be lock-stepped. If the first is set to only output instructions on even cycles, and the second only on odd-cycles... Could be useful.

Actually, my initial thought was that maybe I could have the "new" chip do other things, as well, such as looking for "complex-triggers", or even generating new jump-addresses based on external input for the (single) "free-runner".

It's all up-in-the-air at this point, but definitely some new ideas generated by thoughts from the Blog-Comments. Awesome!