Eric HertzI think I got it! Only one extra pin necessary for full-speed free-running SDRAM! That'll bump my logic-analyzer up to 100MS/s (I couldn't find a 133MHz oscillator at the shop I placed my order).
And I don't have to worry about the direction-changes of the CS pins!
This blurb was added to the project-documentation... It'll be revised, yet.
// CS0, CS1R, CS1W, DQMdata, DQMaddrCmd... all need to be one-shot AND
// fed straight-through from the AVR depending on what's being accomplished.
// (E.G. Free-Running should be straight-through, commands should be one-shot)
//
// Instead of having separate "RepeatedAccess" outputs for each of these,
// (as was the original one-shot design, never implemented, from sdramThing2.0)
// use *one* one-shot vs. dontOneShot selector...
//
// FURTHER: Doing this on the CS_En pins, instead of CS, relieves the need to be
// able to switch directions!
//
// NOTE: This logic might not be right for the active-low vs. active-high
// outputs... Also, might need to swap the Q outputs. Or swap the
// OR's input to the other Q...? Right, move the OR to the other Q,
// after the inverter. And the AND direct to the other Q TODO
//
//
// .--> This can be shared with other one-shots.
// | ____
// dontOneShot >-----------+----------\ \ //
// | OR >-.
// .---------/___/ | ____
// | '-| \ //
// _____ | _____ | AND |---> CS0_En
// uC_CS0_En >-----|D Q|--+---|D Q|--|>o---|____/
// | | | | ^(The value here was the *past*
// .--|>____| .-|>____| value!)
// | |
// SDRAM_CLK >--+-------------'
//
// TODO: If the last output is an AND, it's *plausible* to use the 7451
// already in the circuit (NOT 7451 or 74S51, and 74LS51 was found to be
// too slow(?) for 16MHz, but maybe 74HC/AHC...?)
//
// TODO: The position (and existence?) of the first D-Latch is questionable
// If logic-propagation-delay is a concern, move it to the output,
// instead. Otherwise, it may not even be necessary...
// (Maybe if the AVR's output doesn't toggle at a reliable time?)
The other nice side-effect is that it's a drop-in between the already-existing circuitry. Nice.
So, now, I just need to add a divide-by-8 and I should be good.
The only remaining gotcha, I can think of, is that it's maybe not possible to *read back* data in the SDRAM into the AVR... I don't use that functionality a/o sdramThing3.0 anyhow. But, when working with these high frequencies, I might need to consider doing-so to make sure no data gets corrupted (That was a big issue in earlier sdramThing versions, which was easily fixed by adding a shielded wire to the Clock... but now, what when all those other signals are running so fast?). If the AVR doesn't work reliably with these 16x faster inputs, then that's a bigger ordeal; would involve buffers and latches with output-enables. Here's hoping the AVR samples reliably on the falling-edge of its clock, as shown in the data-sheet, and that the various internal slew-rates don't interfere with the high-speed input signal... If I'm lucky, I won't need 17 buffers and latches and possibly yet another output pin or two.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
And... read-back might be necessary for initial-development for other reasons than just testing for noise...
The one-shot *should* be predictable as to when the output will toggle WRT the time the input toggles, BUT: I'm not certain the AVR's output slew-rate, etc. would guarantee its output to toggle *at* the specific clock-edge. And, because of the SDRAM -> AVR clock-divider, it's possible the one-shot output will be one (or more?) clocks *later* than ideal/calculated.
Generally, that doesn't matter... as it's configured, read/write-bursts *wrap*, so even if I write to column 0 and it ends up in column 1, it should be OK, as long as it's the same offset for *every* read/write (including: starting Free-Running at column 0, which might actually start at column 1).
NOOO!!!(?)
If the free-runner commands are offset by one, then the free-running will be off (right?). E.G. page 0--three columns from the end (due to CAS Latency)--should say "start a read-burst at column 0 in page 1
But, if my writes are off by a column, that means the data in page 1 for column 0 (which is usually empty, *except* for LCD timing info!) will actually be located at column 1... (and the "read" command in page 0 will actually be at 2 columns from the end, not three)...
So, In free-running mode, it will *actually* start at column 0 in page 1, which in reality will contain the data that should've been stored at its last column (due to the one-column-shift in writing).
Oy.
So, at some point, it might become a matter of *what* is stored in these columns... Does it matter if one or two columns are a full page off due to wrapping? Maybe not: I set it up so that each page only contains a full-number of pixel-data: That means even though each page is 1024 columns, only (int)(1024/7)*7= 1022 columns are actually *used/output*, containing 146 pixels' worth of data. That also means that if the offset is *consistent* (which it should be), then one or two bits of the LCD timing data in each page will be output from the wrong columns. Does it matter? It'll contain the LCD clock, which will appear to be output correctly, again due to wrapping at 1022. It'll also contain some timing information, which might be a problem.
ALSO, duh... because only 1022 columns are loaded, that means that burst-wrapping will *not* work as I described... if the data starts at column 2 instead of column 0 (due to a write-offset), then page 0 says to start the next read-burst at column 0 of page 1, then column 0 of page 1 will contain NO DATA. (not *wrapped-data* as I was initially thinking).
Oy.
So, in reality, it seems it's important that I know which column is *actually* being written to, and the only way to know that *for certain* is to be able to read-back the data and verify it.
This whole logic-path fed by some previous experiments (sdramThing2.0?), where it turned-out that writing *was* off by one-column, but in fact, so was *reading*, and, now that I think about it, maybe was *not* limited to full-pixels per page, and a bit more... It appeared to *function* as expected, but in reality it may be that the display was receiving some garbage and just went along with it as best it could...
So, then, even *reading back* the data doesn't assure that the data is stored in the right column. It could boil down to just trying the calculated/ideal column-offset value, and if it doesn't appear right, increment it and try again... In which case, do I really need read-back?
-----------
You see, I'm *really* trying not to have to insert buffers and latches and output-enables and direction-control for 17 bits. I don't know *why* exactly... I know it *can* be done, and *by me*. And, really, this whole project is so esoteric that my original goal of trying to do it *without* glue-logic--so less-experienced hobbiests/designers could make use of my findings--is kinda being defeated. OTOH, maybe not...
For instance, if I can rely on the AVR to sample a signal that's *synchronized* with its clock, but at a 8x-16x faster rate, then this opens up a whole world of possibilities...
Think about the use of multiple slow ADCs to sample a *fast* analog signal... This is not uncommon, though I can't recall its name, off hand. So, imagine you want to sample at 2x faster than a single ADC is capable... You just set two of the same ADCs to sample at their normal rate, but offset by half a clock-cycle. Want 16x the time-sampling-resolution, set up 16 ADCs to sample at their normal rate, each offset by 1/16th of a *single* ADC's sampling-cycle.
Or, if you know that the input signal *repeats* and you've got a reliable trigger, you can use *one* ADC to accomplish the same goal by sampling 16 "sweeps" of the signal, with a 1/16th sampling-rate offset each sweep.
So, if the AVR's input could be relied-on to be consistent, and with a very small "slew-rate" (for lack of a better word), then it could be entirely-possible to use an AVR (or several?) to sample a *much faster* bit-rate than its clock-frequency, without even needing external latches, etc.
Cool.
Are you sure? yes | no
Initial experiment, prior to actually switching over to the higher-system-clock (and one-shots):
Just intentionally write at an invalid offset. Tried -1 and +1 and got what I expected.
-1 causes no free-running. Likely because the *actual* starting-column is left unwritten, with whatever random data just happened to be in it... In which case, free-running could be (and likely is) feeding back an invalid command to the SDRAM... a jump to an unopened page, who knows. But it's not Free-Running, and that's what I expected.
+1 *does* free-run, but the LCD doesn't refresh properly, also what I expected. Instead of starting at the first column written in a page, it starts at the second... That means for every 1022bits in the data-stream (146 pixels) the clock/timing signals lose a bit. Free-Running works because it's just jumping ahead by one command at the beginning of each page, and the Free-Running commands only happen at the opposite end of each page.
So, it appears, it's pretty durn important I get the one-shot's timing right. It's been daunting to contemplate, but maybe these two effects will be enough to get it going without having to reimplement a READ/Verify system (not that I shouldn't, but it would introduce quite a few *new* potential bugs/offset-errors)
Also, Tried a 27MHz crystal, but it didn't even boot. I'm using an AVR rated for *8*MHz, so I'm not surprised. What I am surprised about is that it's running fine at 20MHz.
Next step, while waiting for parts-delivery, might be trying out a *small-scale* increase in speed, with the one-shots... e.g. run at 27MHz SDRAM-Clock and half-that for the AVR. I also bought 40som'n and 60som'n MHz crystal oscillators, so even if 100MHz is too high for my point-to-point hand-wiring, I should be able to find something fast enough to sample this data *and* test out the one-shot circuitry.
Are you sure? yes | no
Heh, and I've started contemplating digging out the ol' Pals/Gals/Peels. But that's another ridiculous venture...
Are you sure? yes | no