Mwahahaha... Somehow it slipped my attention, until now, that the Side-Kick requires a one-shot circuit for /CS, just like the Free-Runner does.

Briefly: The Free-Runner and Side-Kick are each made up of separate halves of the DIMM's SDRAM-chips. These two halves run somewhat independently. (Though, the Free-Runner controls the Side-Kick most of the time).

So far, for this project, I've got the Free-Runner up and running, and basically that's the most complicated part. BUT, I'd forgotten that the Side-Kick *also* needs to be initialized, per the SDRAM-initialization-sequence, and a few other things, as well, like refreshing. Unlike the "Write" command (which will be used for *sampling* data into the side-kick), some of the other commands can *not* be repeatedly-executed (e.g. by holding the /CS line active for more than one clock-cycle). And, since our host-interface is most-likely much slower than the SDRAM-clock, one way to assure a /CS is only active for one clock-cycle is to insert a "one-shot" circuit...

The one-shot circuit takes in a long /CS pulse output by the "host" and shortens it to a pulse that is only a single SDRAM-Clock-period.

Here's the Free-Runner, as currently-wired... (The Free-Runner is the top "chip"). Note the "/CS One-Shot+Override" circuit between the host and the Free-Runner.

(Note that my plan is to share CKE between both devices, so I don't need to repeat the CKE One-Shot circuit, just the /CS One-Shot circuit).

Here's a higher-level diagram showing the Free-Runner's CS output interfaced with the Side-Kick's /CS input.

This diagram also shows the Trigger-Handler circuit which will most-likely be inserted between ... no. No, the Trigger-Handler circuit is inserted between the FREE-RUNNER's CS_DQ and its /CS input... Huh. Some thinking to do...

-----------

K-Den... If I've got this straight... We can basically ignore the trigger-handler on the side-kick...

But we still have to insert a one-shot between the host and /CS_SK...

Or Do We...?

The whole point of the Free-Runner/Side-Kick scenario is that the Free-Runner sends commands... Both to itself and to the Side-Kick... And, inherently, those "fed-back" commands are *exactly* one SDRAM-clock-width, each.

So, if I have this straight... I could allocate, say, a page on the Free-Runner (say the first page) to the Side-Kick's initialization-sequence. (And, maybe, some other pages for other things, like refresh, and row-activation/precharge?)

Note that this is possible because: CKE allows *pausing* reads/writes. (Unfortunately, per the SDRAM documentation, it isn't spec'd to be used for pausing *other* commands... so while some devices *might* allow it, others might not).

So, first, I use the host's GPIO to load each /CS-strobe into the Free-Runner's /CS_SK_DQ. And even though the host's GPIO is much slower than the SDRAM-Clock, we'll pause the "Write" command using CKE... Thus, the actual /CS strobe is written to only *one* memory-location in the Free-Runner. Then we execute a burst-read from the Free-Runner to the Side-Kick, which will execute the commands, one sdram-clock-width each.

Only thing, then... I might need a way to *block* the host's write to /CS_SK_DQ from affecting /CS_SK... so, maybe a NAND gate, and inverting /CS_SK_DQ to active-high, instead of active-low.

One Gate, vs several gates and several latches... Might be worth it. Again, a bit more software, but maybe not so bad. And, again, taking more advantage of the SDRAM's abilities, rather than throwing more/redundant circuitry at it, which I dig.