Project Logs

Collapse

• sdRamblingThing Concepts, revisited

  Eric Hertz • 04/15/2022 at 19:46 • 0 comments

  I've been contacted, recently, about someone's interest in trying this out... Specifically, if I understand, trying to create a state-machine with lookup-tables.

  I think it important to note HOW this thing [supposedly] works:

  Unlike typical Static or Dynamic RAMs, which you just supply an address and it gives the value at that address, SDRAM has a function called Read-Burst (also write-burst).

  When you start a read burst at some address, it outputs the data from that address, then automatically outputs the data from the address after that one during the next clock cycle, and so-on for a selectable number of addresses. E.G a typical burst-length setting is 4 or 8 locations.

  All the SDRAM chips I've worked with can be configured to burst an entire row of data (usually 256, 512, or 1024 bytes). 

  But, of course, a 1MB chip has way more than 1024 bytes... So a single read-burst /cannot/ output the entire chip's contents. 

  To do that, you'd have to start a new read-burst in the next row immediately after the first burst completes. (actually, due to CAS-Latency, it has to be started a few clock cycles *before* the previous burst completes, if you want an uninterrupted burst of two rows, or i.e. 2048 bytes).

  So, what I've done is add a second identical SDRAM chip in the mix (This is easy when using a DIMM!). This second chip is addressed with the same address bits, uses [most of] the same command-inputs. When a read-burst is initiated on the original chip, that same read burst occurs in this new/second chip. So, now, the two chips together burst 2 bytes simultaneously.

  Now, there's no reason to limit this to two chips. A DIMM actually has 8 chips or 8 bytes' worth of chips... So, I group them into two groups, each 4bytes wide...

  The memory I want to burst-read (or write) is 4bytes, 32bits. This is the Sample-memory in sdramThingZero (and #sdramThing4.5 "Logic Analyzer") logic-analyzer.

  This can also be, say, a framebuffer to drive a LCD... or, basically anything one might want to output/input in a huge continuous burst.

  Again, that group of chips, alone, would only be able to burst a maximum of 1024 32bit words, before requiring a precisely-timed NEW read-burst command, telling it to begin a new burst from the next row.

  So the other group of chips, 4 bytes' worth/32bits, is loaded-up with that command. This group (I call the "FreeRunner") has its data outputs tied [mostly] directly back to both groups' command/address inputs. (The other group, the "memory" for sampling, or a framebuffer, I poorly named "The SideKick"). 

  So, Now, the FreeRunner and the SideKick BOTH burst the same addresses at the same time. The FreeRunner is MOSTLY filled with "NOP" commands, so mostly doesn't interfere with a row-burst. BUT a few addresses shy of the last address in the burst, it requests a new burst in the next row. Which begins a few clock cycles later, immediately after the first completes.

  That's a bit simplified, but should do for now.

  Fill the FreeRunner with commands such that the SideKick will burst its entire contents in a continuous stream, 32 bits from each address, once per clock cycle.

  Great for sampling data in a logic analyzer, great for refreshing an LCD, I dunno what-all.

  ....

  So, the FreeRunner basically does little else than cycle through all the addresses in the DIMM.

  Unfortunately, not much at all like an EPROM lookup table, more like a VGA card. Heh. 

  ...

  However, it /is/ a bit like a very limited CPU, The addresses' incrementing after each NOP is a bit like a program-counter.

  Now, it is possible to send different commands to the Sidekick and Freerunner. Each group of 4 bytes has a separate Chip-Select. So, e.g. in a logic-analyzer setup, the Freerunner is always burst-reading (outputting the commands stored in it) while the Sample Memory (SideKick) may be burst-writing (sampling data, storing it in memory) OR burst-reading (outputting the stored samples back to the host...

  Read more »

• Why'd I Stop?

  Eric Hertz • 01/11/2022 at 17:18 • 0 comments

  This's been in my drafts since the turn of the year (It's now mid-April, and it's been snowing!?). I didn't finish this writing, there's a TON more could be said about how things like this have taken their toll on me. And, quite frankly, I'm a bit afraid to talk about this stuff, for COUNTLESS reasons. But... It happened, and things like it continue to happen. These things affect me every day, some near-decade later, and to lesser-noticed extents some decade prior. Facts are facts, I suppose. Whatever the heck it is, it seems I just can't wrap my head around it, nor really how to function in any reasonable capacity with it's presence in my life. It is what it is (what is it?!). I'm doing the best I can with what I understand.

  Here's the original draft. Actually, I've tried to write about this COUNTLESS times, and I bet there are years-old drafts about it all over my projects' logs. Heh. Here's the January 2022 attempt:

  ....

  This project, you may've noticed, went from ludicrous-speed to full-stop in basically one evening.

  I've tried to explain to countless folk countless times and countless ways...

  I haven't explained, here, because, frankly, it scared me. The event itself, and the implications. Still affect nearly all my projects to this day. Years later. Heck, frankly, it affects nearly every aspect of my life.

  ...

  Today I woke with an analogy in my head...

   Imagine the "Pinball Wizard". This guy got really good at pinball, so good that he gained an audience. During a competition he made a mistake... he knows he did. He slipped, missed that button... No one else saw it. The paddle did its thing as though he hadn't. At the time he really didn't think about it... But after the excitement died down, he remembered his fumble... That should've been the end of his game, early-on. Instead, he went on for many more rounds, ultimately winning. What's he supposed to think? Eventually he puts it out of his mind... continues playing when he has time... Until another competition... huge crowd gathered around... He fumbles, again, yet the paddle hits the ball expertly... right up through "The Impossible Loop" gaining a gazillion points, flashing lights, and so many dings nearly every remaining angel-second-class must've gotten their wings. The crowd's going wild, but there's no paddling to do as the ball travels the loop. He knows he missed that shot, has time to think, he starts flailing on the paddle buttons... If those paddles did what they were told, that crowd would've thought he was having a seizure. When the ball returns, he hits it once or twice, as usual, then intentionally starts missing shots, yet those paddles keep hitting it perfectly. Eventually he just stops even pushing the buttons, but the game keeps playing without him.

  Hey, this is the 70's, we're talking about, gaming AI is about as sophisticated as Pacman's ghosts... There's no way even the refridgerator-sized computers of the era could achieve the level of real-time physics calculation to keep that ball in play.

  So what's left?

  Remote controls and a video camera?

  Whatever the case, even "in the zone" he knows he missed those shots, especially the ones he intentionally missed.

  .

  sdramThingZero was at a point where I was coding... Really low-level, I wrote my code changes in "baby steps," thoroughly testing each along the way. Small change, recompile, upload to the AVR, test test test, repeat. There's no operating-system to get a virus on a chip like this, no WiFi for remote-control... I'm coding in C at the lowest level possible. I wasn't even using others' libraries aside from defaults like avr-libc... heck, not even stdio. Certainly not Arduino. Basically aside from the initial boot code that calls main() I'd written /every/ piece of code running on that AVR. Heck, I wasn't even using a bootloader! My hex file was flashed at address 0.

  Unlike pinball, there was no reliance on timing with external factors... My process was lock-stepped....

  Read more »

• TODOs

  Eric Hertz • 02/19/2019 at 03:16 • 0 comments

  Yup, sTZero's been on hiatus for a while... life 'n such.

  UPDATESs will be placed at the bottom...

  Here's a thought:

  SN74LVC1G123 - might just handle our one-shots... Personally, the idea of using RC timing doesn't quite sit with me, for this project, being largely variable in its sample-rate... But, maybe som'n can be done tying those R and C inputs to something like the SDRAM clock. Or maybe some other path, even with R and C fixed (e.g. at 10ns, for max-sampling at 100MS/s) as long as we can assure that 10ns pulse meets setup/hold times for the instruction-load clock-edge (when sampling at lower rates).

  Dunno...

  Anyhow: 

  https://hackaday.com/2019/02/18/inefficient-neopixel-control-solved-with-hardware-hackery/
  

  ----

  2-29-20:

  Vague idea: since trying to interface with an 8-bit bus, maybe read-back of the sampled 32bits could happen by a sort of bucket-brigade. [And maybe similar for writing the free-runner?]. E.g. read the first chip, write from the second to the first, read the first again. Thus, plausibly reducing the number of chips [loading] on the bus, and plausibly the number of latches/buffers. 

  Also plausible, read first SK chip to bus, read second chip to FR first chip, etc. [Overwriting FR, but can be rewritten], a sort of left-right-forward bucket-brigade. [May be more feasible; since data I/Os are a single pin, loading wouldn't be reduced much if B4->B3->B2->B1, but would if B4s->B3f, B3f->B3s... erm, no...]

  BUT: B4-/\/\/-B3-/\/\/-B2-/\/\/-B1-/\/\/-Bus... hmmm. Only not-so-much, *maybe* since all SK chips [and all FR chips] use the same command signals [ [all chips reading/writing simultaneously] I Wonder, since read-commands and write commands take a different number of clock cycles, maybe a read's data would linger long enough to be registered by a write, hmmm. Could be handy elsewhere, too [copying FR commands/NOPs from bank to bank?] ]. 

  BUT: B4s-/\/\/-B3f-/\/\/-B3s-/\/\/-B2f-/\/\/...B1s-/\/\/-Bus... wouldn't have that limitation [read from SK, write to FR simultaneously should work]

  [Of course, B4s=1, B3s=0, B3f=0.5... hmmm.... resistor values increase left to right? Diodes? Buffers, of course, but then more control signals /OE, when sampling, no?]

  Ideally, would also reduce the number of control signals necessary to select which byte to read-back [knowing they'll always be read in order]... a sort of byte-wide shift-register.

  ---

  8 devices attached to a bus with only one buffer [two slightly preferable]. A shift-register, of sorts...

  ---

  Ahhhh...

  But this overwrites one side's data with the other's.

  It works[?], in this case because the Sidekick's data is loaded from the sample inputs *not* from the bus, thus Read-only, from the bus's perspective. Whereas the Free-Runner is [or could be] write-only from the bus's perspective. 

  Sample-data can be destroyed upon read-back AND when writing the Free-Runner. Free-Runner data can be shifted back in during either process. Weird.

  The resistors could be replaced with buffers with /OEs tied directly to the other /OE's... I spose that'd be easier to design. And still no extra control signals necessary. 

  But I'm a bit fixated on using passives; making use of the circuitry inherent to the devices... dunno why. And resistor-nets are a *tiny* bit cheaper, no?

  ----

  And more pondering... I think it requires a DQ latch to store the new FreeRunner data to be shifted in while shifting the data from the SideKick into the other FreeRunner registers... because, at that same time, the last SideKick register is also outputting to the bus [so can't contain the new FR data simultaneously].

  Here we have a new dilemma... with another shift-reg comes another control signal [though "strobe" may be necessary elsewhere anyhow]. So, another option is to sacrifice 8 bits of sample-inputs to use as that register. Wastes a lot of memory and brings the sample inputs down to 24 from 32... but, easier to...

  Read more »

• Wouldja lookie there

  Eric Hertz • 09/20/2017 at 23:45 • 0 comments

  as an aside at #Floppy "Fun" -- Backing up a unique Kay-Pro disk ... I just happened across this:

  Heh... guess I'm pretty good at (eventually) reinventing the wheel.

  Those are from the z80 datasheet.

• Random Updates...

  Eric Hertz • 01/19/2017 at 03:47 • 0 comments

  UPDATE: Apparently I've found a general-spec... See the bottom

  -------
  

  sdramThingZero is still on-hold, but of course still runs 'round the ol' back of the head... There's nothing really stopping progress, just haven't gotten around to designing/ordering PCBs. In fact, the breadboarded sdramThingZero is still sitting on my desk right under my monitors.

  ------
  

  So here's something interesting:

  Does that look familiar, at all?

  Yep, it's pretty much exactly the same topology as the "one-shot" logic used in this project. Two flip-flops in series, both receiving (in some form) the input, performing some logic on the original and the delayed/latched output, and even an async-input (similar to my "one-shot Bypass" input). This is from the Intel 8284 datasheet, that's the clock-generator used for PC/XT (8088) computers. Besides clock-generation, the 8284's other key feature is what we see here, synchronizing an asynchronous "READY" signal to the system-clock... Just like my one-shots synchronize an asynchronous Chip-Select or Clock-Enable signal to the SDRAM's clock.

  Why's this interesting to me...? Maybe this is some sort of de-facto topology used all the time...? The fact is, I designed that circuit without having looked it up... I used knowledge of what was going in and expectations of what I wanted out, and I designed a circuit to do-so. I knew it *would* work, for the most-part (what happens if the asynchronous input comes between the setup/hold times? TI's thoughts here), but I didn't expect that it was good 'nough for a product. And yet, there it is!

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

  SDRAM initialization:

  Note, first, I'm no trained expert... this is all what I've gathered in my experience with hacking SDRAMs... (single-data-rate, NOT dual-data-rate!)

  See also: https://sites.google.com/site/geekattempts/home-1/sdramthing/using-sdram
  

  Someone commented on my youtube-video, prompting me to respond that... basically... the SDRAM initialization-process, unfortunately, pretty much requires the entirety of the functions one might need to make use of the SDRAM, including ones that are otherwise unnecessary, and more.

  What do I mean...?

  Well, it's not like SRAM, where you can just turn it on, write a byte, and read it back (and you can repeat the write/read process at any other address, immediately thereafter).

  It's not like DRAM, where you can just turn it on, select a row-address, write a byte, and read it back (and you can repeat the select-row/write/read process at any other row/col-address the next time 'round).

  So what's it like...?
  Well, first, let's *merely* look at the write/read procedure.

  Note that this example differs from the SRAM/DRAM examples given earlier in that this can only happen *after* initialization, it can't be done immediately after power-up (we'll come back to that).

  To write a location and read-back you have to open a row (similar to DRAM), then you have to perform a write at your column, then you can read it back... That's pretty much the same as DRAM, except that if you want to do-so again at a different row, you have to explicitly choose to *close* the original row, first. (Closing a row is called "precharging").

  So, realistically the write/read-back procedure is similar to DRAM *unless* you want to access another row.

  But, we're just trying to do the *simplest* experiment, right...? Just to make sure we're wired-up correctly.

  (See Note1 below)
  

  So, say you're developing a *really simple* project, wherein all you want to do is write data, and read back... And, say 256 bytes is more than enough for you... (when opening a row, you have access to a minimum of 256 bytes/"columns" from that row at a time... some devices support up to 1024).

  Then you'd be set, you'd never have to think about precharging. (And, another cool side-effect is that as long as a row is open, it is inherently stored in registers rather than merely dynamic-RAM cells/leaky-capacitors, so needn't be refreshed... Handy!). BUT, you *would* have to consider the fact that you can't "activate"...

  Read more »

• On Hold... + Great Quote.

  Eric Hertz • 12/08/2016 at 17:00 • 0 comments

  Not sure what my last log was, but this project has been put on-hold, as I've managed to bump some wires, or something, causing it to be much less reliable than it was previously. Time to PCBify, or at least point-to-point-solder it. And haven't had that kinda energy.

  In the meantime I leave you with this quote I stumbled upon, might say a bit about me:

  "SDRAM represents clinical levels of insanity to initialize" -- @Samuel A. Falvo II

  (https://hackaday.io/project/10035/log/49829)
  

• FAIL, sorta expected...

  Eric Hertz • 11/22/2016 at 10:59 • 4 comments

  In the last log was a TODO:

  TODO: Believe it or not I did all that layout without actually verifying the chips I have match those footprints. Usually that'd be the *first* thing I'd do... Usually I'd make my own, in fact, because I rarely trust those provided. This time, for some reason my brain's been on this tetris-style packing-kick. Could be risky. I guess we'll see. I can feel the datasheet-lookup energy building... may be a few days. Or maybe I'll just print the danged thing and set my chips on the printout.

  Whelp, I printed it out... and it turns out it was risky.

  Out of 7 footprints I chose and laid-out, only 3 were correct.

  The 20-pin 7400-series SOICs in my collection are *wide*... Easy enough to fix since it's laid-out on breadboard.

  The 56-pin SSOP is 0.5mm spacing, not 0.4mm... Whelp, that was a lot of work for nuthin.

  The clock-generator chip is actually SSOP-10 (?!) not SSOP-8, and... I dunno what spacing, smaller than 0.4mm, it seems.

  ........

  I suppose I should take a step back and re-evaluate this ordeal... Maybe I'll spend a few days cleaning the apartment, first.

  Or maybe I'll just go play some Tetris... My gameboy's long-gone, and I'm tired of staring at the TV/monitors... I hate using my phone's touchscreen for things like this...

  But I just happened to save one of those ridiculous cheapo hand-held games from the 90's with the custom LCDs, and it just happens to have Tetris on it... Time to dig out the file and scouring-pads and dig through the box of batteries.

• solder-proto for the next-generation

  Eric Hertz • 11/21/2016 at 20:22 • 0 comments

  Apparently it's brain-dump time.
  

  In the previous log I showed my thoughts on making a sorta general-purpose prototype-board that can be used for the first soldered prototype, as well as be used/usable for many other unrelated projects...

  Here's the latest fixation... Weee!

  What I didn't mention was how this proto-board also looks to the future of *this* project...

  This project has two main phases, I see...

  First is getting it as fully-functional (sample/repeat, high-speed, trigger, adjustable sample-frequency) as I can... That's easiest done with a uC that has plenty of GPIO pins... Thus I'm using my trusty ol' ATmega8515 40pin-DIPs... and, as I described in the last log, that lays-out perfectly over some otherwise currently-unnecessary breakout-space on my protoboard-design...

  The second phase is replacing the dedicated AVR in favor of whatever host one might want to use... e.g. a single-board computer like the Raspberry Pi, or even via an FT2232 chip connecting it directly to your computer via USB. The hurdle, here, is that this requires whittling down the number of required GPIOs to something reasonable... like an 8 or 16-bit data-bus.

  There's plenty of contemplation in my various logs regarding how I'll do that, and I don't doubt that I've got it mostly-figured-out... I could probably, if my brain works in my favor for that long, whip it out in less time than it'd take to receive this PCB order.

  But, I guess, I tend to take an iterative-approach with my projects, rather'n going gung-ho with a design->PCB... And, the current scenario is that the solderless-breadboarded prototype has become increasingly-flakey (largely, I'm sure, due to wires getting bumped, "antennae" everywhere, etc...(interestingly, when I run it at 50MHz, it interferes with my TV reception!))... The likelihood of this guy lasting a year and being able to just power it up and make use of it is... pretty low.
  

  So, iteratively, I still have a bit I could experiment with and implement while connected to an AVR... and, I wouldn't mind having a reliable prototype that I can come back to later down the line and turn on and expect to still work.

  -------
  

  Oy, all that explanation to say... no, I haven't forgotten about the second-phase, in this proto-board's design.

  Whittling down the GPIO-necessity is mostly just a matter of a bunch of latches... and low-and-behold, I've laid out this board for two 8bitters... Right under where the AVR goes, currently. And, again, I'll be using *two* of these boards for a single DIMM, so I'll have four 8bit latches available and broken-out. And, again, I've laid out SOIC-breakouts as well, 20pinners, which will also work for 74xx574 latches. So... I think we're set. And if not, then I can just as easily throw a third board at it. (Yay buying in quantities!)

  In fact, who knows, I might just bypass the AVR soldered-proto... It's plausible. I do have a PiZero and now also an LCD with HDMI, after all! And I plan to order an HDMI cable/adapter alongside this PCB-order... So, who knows.

  --------

  The image above shows the current state of the 574 breakout(s)... It wasn't easy fitting them in there, being that the other side is a TSSOP-80/56 breakout, but it wasn't particularly difficult, either. It was easier than I expected, though. A pleasant surprise, for sure.
  

  I *think* I might be able to squeeze that 8-pin TSSOP in between, but that might be almost as much work as the two 20pinners, and plausbly not possible, due to the number and positions of the vias and the red-traces necessary for the current setup.

  The idea, there, is to throw in the clock-generator chip... (also explained in previous logs)... That guy basically allows one to select from a huge selection of clock-frequencies anywhere from 500Hz to 200MHz (thus, sample-frequencies). Could be quite the gizmo, and I haven't yet experimented with it.

  (Also, it requires I2C, which I'm not expecting the "host" to provide, meaning I might be implementing it via bit-banging via the host-interface, or...

  Read more »

• solder-proto

  Eric Hertz • 11/21/2016 at 13:17 • 8 comments

  UPDATE -- New SOIC-breakout... see below.
  

  Working on a solderable-prototype... due to solderless-breadboard-wiring-wonkiness.

  Decided not to design a full-on PCB, yet, as it's still in the prototyping-stage...

  Decided on 70mm x 70mm boards, they're much cheaper than the width necessary for a DIMM, so I'll "cludge" two together... It's actually pretty easy and stable with thin PCB-material to just overlap them for one or two rows.

  So, the board design is somewhat generic.

  First things first, the DIMM socket will solder into two 70mm tall boards with this running from end-to-end:

  Might take a little hand-drilling for the support-mounts, etc. But I'm more than OK with that.

  The thing about the DIMM sockets is that they have this weird footprint with diagonals... more on that in a bit.
  

  Next we have some breakout for surface-mount chips, since 7400's in the speeds we're looking for mostly only come in SSOP, or if you're lucky (as a prototyper) SOIC.

  (Yes, this is a breakout, for prototyping. No these traces are not matched-length, and who knows what kind of signal-issues may arise due to their closeness to each other).

  Now, you might look at that layout and go "whhhaaaa??!"

  But check this out... If I'mma make a prototyping-board and have ten of 'em made, I'mma think of other projects as well... So the above was designed *after* (on the other side of) this:

  I don't actually have any SSOP80 chips, that I'm aware of, but I do have some TSSOP56's I'd been planning on using... So this'll break that out nicely, and leave room for later prototypes.

  (If you have better ideas how to label the "pin numbers" to accomodate an arrangement like this, I'm all ears. I've thought about A1-A9, B1-9, etc... just to make it clear that these numbers *don't* correspond to the pin-numbers on the likely-smaller chips that'll be installed. I know better, but've been caught slipping-up on TQFP100 adapters fitted with smaller devices).
  

  Again you might say "whhhaaa?!" at the breakout-layout/numbering... Herein, the layout is specifically-designed to occupy as little space as possible while *also* being easily "straddled" with a 32-pin DIP, or even 40-pin, yahknow, with a few extra holes at the ends.

  So, that may seem a bit ridiculous, but consider sdramThingZero's parts-tally so far... We've got a 40-pin DIP (AVR), a SSOP-20 (74xx574 latch), and two SOIC-14's (74x00 NANDs). (Though, since this's been designed, I might opt for SSOP-14's in future orders). And, again, consider that this single board-design will be used *twice* to handle the DIMM socket... On one board, I can throw the AVR over the above layout and not waste a whole bunch of holes under the DIP.. On the other board, I can already handle two of my three 7400-series chips... again in that same workspace.

  And, I'm currently working on a more generic SOIC-breakout... Which isn't too-difficult considering they're half the space of regular breadboard spacing... meaning that when they're not populated, that space can be used as regular 'ol breadboard:

  So, the SOIC can be placed, it's a bit easier to solder to a via than directly to a pin... and it makes for backside-wiring, which I usually prefer. Note, again, if I don't need to place a SOIC, then that entire space can be used just like regular ol' 0.1in breadboarding-space. Should also work quite well with e.g. SOT-3, no?

  Then, there's the "center vias" I thought Ted was talking about in the comments, below... But he was talking about different ones. These center-vias alternatingly attach to "planes" on the top and bottom layers, making it easy to essentially have power and ground-planes on a 2-layer board, and easy to "solder-blob" most pins directly to 'em, or insert surface-mount decoupling-caps, pull-resistors, etc. on the back-side.
  

  Debating the use of octagonal vs circular pins/vias... also experimenting with the planes' violating the DRC trace-width rules...

  ---------
  

  So, this, like all my soldered-breadboard prototypes, will be wired point-to-point with "wire-wrapping"...

  Read more »

• Trigger-Handler 2.0!

  Eric Hertz • 11/10/2016 at 22:35 • 2 comments

  DUH!

  Brief recap (better explained in past logs):

  A portion of the sample-memory will be used for a circular pre-buffer. Then, when a trigger is detected, it will jump out of the circular-buffer and begin sampling in the remaining memory.
  

  So the idea is to load the "Free-runner" (memory-controller) with two sequential "Activate [row]" commands... The first would activate the next row within the circular pre-buffer, the second would activate the first row *outside* the pre-buffer. But: Only *one* of these "Activate [row]" commands would be executed, depending on whether the trigger's been detected.

  This, previously, was handled by only outputting One "Chip-Select" signal for the two "Activate" commands, alongside only the *first* Activate command. The second would then be "Inhibited."
  

  The trigger, then, would control a MUX, which can selectively delay that "Chip-Select" by one clock-cycle. So, when the Trigger has occurred, that chip-select which was originally alongside the first "Activate" command, will now be delayed to execute the *second* "Activate" command, causing the system to exit from the circular pre-buffer, and enter into the sequential sample-memory.

  Here's a *simplified* example from a while-back. (Note that /CSLoop and /CSTriggered should be wired-together for a single /CS input to the circuit):

  (Note, this has issues with the case where the trigger occurs *exactly* between the two "Activate" commands, but that has been handled in previous logs. The concept is still the same; selectively delay the input /CS signal).

  This concept should work.

  BUT:

  After the trigger occurs, this system will delay *all* the chip-selects for *all* the commands... Including Read/Write commands. That's OK-ish... So, just repeat each command twice, only one would be executed... no biggie.

  I could get into the nitty-gritty details of how the "Free-Runner" (memory-controller) works, again, but I've gone over that in numerous previous logs. But, because of how it works, there remains one slight hurdle... Most commands can be shifted, slightly, without causing trouble. But there are two commands which actually (ideally?) have to occur back-to-back. The "Read" command tells the Free-Runner to begin executing commands from the next memory-page, and the "Write" command tells the sample-memory to sample data at its next memory-page.

  (This works because the Read command has an inherent "Latency"... it doesn't start until a couple clock-cycles later, whereas the Write command has no latency, it begins immediately. Thus the two commands can be executed at different times, but will actually *start* at the same time, keeping the Free-Runner and Side-Kick synchronized).

  All that to say, if I delay the chip-select after the trigger occurs, then I'd have to have two read-commands, followed by two write-commands, but since the read-command and write-command actually (ideally?) have to occur at specific times, the trigger-handler would affect that. They couldn't be back-to-back. It could be worked-around, but not ideal.

  Then BIG DUH:

  I really only need to delay the "Activate" command... Or, rather, I really only need to *select* one of two activate-commands... The other commands would, ideally, be left-alone...

  So, BIG DUH:

  The command-inputs are /RAS ("Row-Address Strobe"), /CAS ("Column-Address Strobe"), and /WE ("Write Enable"). of course, those can be "inhibited" when /CS ("Chip Select") is inactive...

  Those, basically, cover the major functions of the memory: Activating a Row and Reading/Writing a column.

  And, then, there's NOP... Which is functionally-identical to an "Inhibited" command, except occurs when /CS is *active*... Hmmmmmm

  NOP just *happens* to be what happens when all the active-low command-inputs are *inactive*, but again with /CS active.

  And /RAS just *happens* to be used for... Strobing a Row-Address... Hmm, like, maybe... "Activating a row"?

  Is it possible the *only* command-signal that needs to be activated to switch from NOP to "Activate [row]" is the...

  Read more »

View all 55 project logs