sdramThingZero - 133MS/s 32-bit Logic Analyzer

Add an old SDRAM DIMM to your SBC for a 133MS/s 32-bit Logic Analyzer, add ADCs for a Scope...

Similar projects worth following
Yes, it likely seems a bit ridiculous to add an old SDRAM DIMM to today's single-board computers with their whopping e.g. 512MB of onboard DDR2, but believe it or not THERE'S GOOD REASON!!!

Turn your SBC into a logic analyzer, data-logger, or an oscilloscope... You'll see! Read the Details!

This is a re-envisioning of its "father", sdramThing4.5:

This new revision is more of a peripheral (rather than a complete system) which can be attached to microcontrollers, single-board computers, or even a PC's parallel-port.

The UI, datalogger, etc. can then be programmed in any language available on the host.

Turn your Raspberry Pi (or nearly any Single-board or even regular computer) into a 133MS/s 32-bit Logic Analyzer, or a 3-channel 10-bit 'scope, etc.!


This project and its "father" were blogged at Hackaday!

(Thanks Al Williams!)

(Thanks Brian Benchoff!)

And, was chosen as a finalist for The Prize!

(Thank you, judges!)


Here's how I see it:

Add this ten-gallon "hat" to your PiZero, load a piece of software, possibly supply your own old SDRAM DIMM, wire it up to your 3.3V logic-to-be-analyzed, and you're ret-to-go.

(WHAT?! You're sticking an SDRAM DIMM on a single-board computer with already more/faster memory than that?! Why???)


So, here's the deal...

(I'll use the Raspberry Pi as an example of the sorts of device this is intended to work with)

The Raspberry Pi is, essentially, a single-board computer. Its end-goal isn't interfacing to hardware at the bit-level, as much as it is to be a tiny full-fledged workstation...

This is different than, say, the BeagleBone, which (as I understand) is designed for high-speed interfacing with the outside world (For a great example of what it's capable, see @Kumar, Abhishek's #BeagleLogic. If you're looking to build an embedded-logic-analyzer, that's probably a better way to go!)

So, it's taken a few great minds*, here at, to bring me to the conclusion that sampling data straight from most (but not all) Single-board-computers' GPIOs into their internal RAM causes a bit of a bottleneck.

* (Thanks especially to @usedbytes and @Vikas V over at #Operation: Try to Bare-Metal the Pi and #Logic analyzer using raspberry pi)

Enter External Memory...

By adding a bit of memory between the "real world" (logic analyzer inputs, ADCs, etc.), it's possible to sample data *really quickly,* then read that data into the RPi at whatever rate possible. Then, after it's read-in, it can be displayed, manipulated, zoomed, etc.

This isn't unlike most logic-analyzer peripherals.

Enter SDRAM:

SDRAM is, as far as I'm concerned, the last of the "easy-ish" memories to interface-with... It runs at 3.3V, doesn't require complex timing schemes (and huge sensitivity to skew) to handle data on each edge, etc... (At another level, it allows bursts longer than 8 data-locations, allows for somewhat-arbitrary clock-halting, and more).

Besides all that, it's pretty easy to find SDRAM DIMMs unused in piles... Why limit yourself to a single 16-bit-wide 16MB chip, when you can easily have 32 parallel bits and 64MB already wired-up for 133MHz speeds?

Enter sdramThing:

sdramThing is a (series of) project(s) I've been working on for several years. The latest version, prior to this, acts as a 30MS/s 32-bit "Logic Analyzer", of sorts, when connected to an AVR and an Oscilloscope.

The basic idea of all versions of sdramThing is to connect the SDRAM's "command"/address pins directly back to its data pins... Thus, by filling data-locations with specific instructions to be fed-back to the SDRAM, the SDRAM itself can "Free-Run" at the highest-speed its capable (133MHz, soon?), independent of a controller. It's definitely a loop, and definitely a "loopy" explanation. :)

Check out: #sdramThing4.5 "Logic Analyzer" and the home-page (

a bit outdated) at: for detailed explanations of how this "Free-Running" is possible.

Note that "Free-Running" uses one of the two "banks" of memory on a DIMM to store/repeat the commands. This bank, and thus half the available memory, can't be used for sampling data (however, it can be used for *outputting* data, arbitrary-waveforms, etc.). It may seem a bit wasteful, in a logic-analyzer-sense, but consider the alternative is a dedicated controller with 20+ GPIOs capable of precision timing at these speeds (which we've already determined the Gigahertz+...

Read more »


Intel's PC SDRAM Serial Presence Detect (SPD) Specification Rev 1.2B - Describes the information contained in the SDRAM DIMMs' EEPROMS. This *can* be useful, but again, don't trust that the data read is *entirely* accurate, as some manufacturers cut corners.

Adobe Portable Document Format - 141.08 kB - 08/05/2016 at 09:40

Preview Download


Micron SDRAM chip Datasheet: MT48LC8M8A2 pretty much general-purpose for most SDRAM chips.

Adobe Portable Document Format - 5.99 MB - 07/23/2016 at 21:55

Preview Download

unb_001 SDR.pdf

Intel’s PC SDRAM UNBUFFERED DIMM SPECIFICATION Rev 1.0 Pinouts, etc for DIMMs (Be sure to look at section 5. Also browse my gallery for a pinout I drew-up) BEWARE: NOT ALL DIMM-MANUFACTURERS FOLLOW THIS SPEC!

Adobe Portable Document Format - 438.95 kB - 07/23/2016 at 21:51

Preview Download

  • 1 × PC-133 SDRAM DIMM Most will work
  • 1 × 74AHC574 Electronic Components / Misc. Electronic Components
  • 2 × 74HC00 Electronic Components / Misc. Electronic Components
  • 1 × 30MHz Crystal Oscillator
  • 1 × Solderless Breadboard

View all 9 components

  • Random Updates...

    esot.eric01/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:

    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.

    esot.eric12/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


  • FAIL, sorta expected...

    esot.eric11/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

    esot.eric11/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

    esot.eric11/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!

    esot.eric11/10/2016 at 22:35 2 comments


    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.


    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 »

  • Side-Kick one-shots, or not?

    esot.eric11/08/2016 at 22:00 4 comments

    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...

    (UNRELATED TODO: Activation-Redirection Trigger-method and delay of other commands, such as Read? Should only be a problem in the circular-buffer, right? Can shorten by one sample...?)


    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.

  • 60MS/s!? On this UGLY BEAST?! Woot! + Ugly IDE-breakout

    esot.eric11/07/2016 at 01:11 2 comments

    UPDATE2: Wow! 27 hours! I mean, yahknow, it'd be *easy* to bump a wire on this thing sitting right above my keyboard... but still running at 50MHz. Cool.

    UPDATE: Been "Free-Running" continuously for over 5 hours straight at 50MS/s... I might go so far as to call it reliable! (and more notes added below regarding 62.5MS/s and the IDE-breakout... and completely rambling below.)

    The short ribbon-cable is a "breakout" for the Free-Runner half of the DIMM's memory-chips, including the Address/Command signals. The longer ribbon-cable, leading to the left, is for the Side-Kick, which will handle the actual sampling of data to be [logic]-analyzed. Currently the Side-Kick/sampling/trigger-handler are not yet implemented.

    A brief overview (explained in various previous logs): The system is currently controlled by an ATmega8515 (upper-left 40-pin chip), running on a 16MHz crystal-oscillator (the "host"). The SDRAM is running at 50MHz. The circuitry with the 7400-series chips is "one-shot" circuitry, allowing the *slow* 16MHz processor to interact with the much faster 50+MHz SDRAM. Further, that circuitry alleviates any necessity for the "host" interface to require precision-timing... Simple GPIO-toggling gets the job done.

    The code currently running on the AVR is written in (mostly) plain-ol' C... so it should be pretty easy to port to any other system with enough GPIOs, including those running an operating-system like Linux (e.g. a Raspberry Pi... I've a PiZero in the works).

    The biggest hindrance to using such a device, however, is the *number* of I/O pins available on such a device. Thus, a bus-interface will be added in the future, to connect the 80ish data and address/command signals from an SDRAM DIMM to, say, an 8-bit bus. That'll require numerous latches and other circuitry, but I'm doing my best to keep that parts-count low by using as much of the SDRAM's inherent functionality as possible.

    The IMPORTANT factor is: Even though dropping these 80 parallel signals down to 8 would slow down the interface between the "host" and the SDRAM, this will have *zero* effect on the *sample-rate* of the overall system. So, this is no different than how one might have a 100MS/s logic-analyzer connected to their computer via a 115200b/s serial-port. Except, in this case, using GPIOs via a bus, there's no need for a dedicated microcontroller in the logic-analyzer "peripheral." (The AVR, in this current incarnation of this system would be replaced by your own "host" be it a Raspberry Pi, or your FT2232H breakout-board, etc. In a sense, the "Free-Runner" half of the SDRAM-DIMM is your dedicated controller, with "firmware" uploaded by your "host.")

    (Today's interesting realization: This is kinda like the equivalent of a "WinModem" wherein there's no dedicated controller handling the brunt-work... Except, that's a bad example, because the brunt-work of *sampling data* is handled, *in real-time* by the SDRAM itself... OTOH, the brunt-work of telling the system *how* to sample the data is handled by the "host" before-hand... making this a bit more like today's USB-attached devices which don't contain their own firmware until it's uploaded by the driver... except, again, that "firmware" is generated and modified on-the-fly... so, maybe, this is a unique sorta thing altogether...?).


    Previously: The system maxed-out at 30MS/s... Now...

    Replaced the 74AHC574 and two 74HC00's with a 74LVTH574 and 74ALVC00's... still on the solderless-breadboard.

    Looking at the wiring, and a few other things, I would've been impressed if it bumped up to 40MS/s... But that worked pretty much right off the bat.

    Threw in a 62.5MHz crystal... and... it works! -ish

    It's a little bit wonky at this speed, but worked one time, allegedly. Didn't a couple times between... now it is running again.

    UPDATE: And a couple more did-work/didn't-work scenarios thereafter. Interestingly, one of the recurring "didn't-work" phenomenon is that of allegedly free-running at something like 50MS/s...

    Read more »

  • Resistor-Latch-Logic, loading, capacitance... Two separate paths?

    esot.eric11/02/2016 at 10:15 0 comments

    I've mentioned this a few times in past logs, using resistors to route data-flow where otherwise it would be "logical" to use logic (gates, buffers). Especially to interface with the *bus*. A few reasons: adding buffers requires the addition of another control-signal for each device connected to the bus, resistors are cheaper than buffers, and of course I'm attempting to use the SDRAM's inherent features wherever possible... Maybe not *great* reasons, probably not ideal in a *product*, but maybe easier in some cases for hobbiests, etc., and just another way of looking at things...

    (Of course, the DQ-latches have an Output-Enable, which gets toggled as-appropriate).

    So, a little bit of math might suggest that this would be quite difficult, especially when connecting *multiple* devices to the bus. The input-capacitances of all those devices (and the processor's bus, itself) add up...

    E.G. at 133MHz, say, 3ns is a reasonable rise/fall time... And say the capacitance of the inputs is something like 50pF... T=RC... that'd be 60ohms for our resistors. Yeah, that'd be tough... lotsa milliamps when several DQ-latches are holding a "1" and the bus drives the latch-inputs to "0". Etc. Etc. (OTOH: In most of these cases, there's no reason to drive the outputs at the same time as there's data on the bus... hmmmmmm)


    One big consideration is the fact that the bus is generally *not* going to be 133MHz.

    (Pi's GPIO toggle rates allegedly max out at around 50MHz, and the step-wise process of controlling the bus is several steps between each read/write).

    So, we might be able to bump those resistor-values up a bit without dramatically slowing *bus* transactions.

    Here's some data from the Micron 64Mb SDRAM Datasheet:

    But, this shizzle adds-up, right? Each DIMM may contain up to *16* chips (8 per side) all connected to the same command/address lines... That's 16*5=80pF! But, also, the Command/Address pins are directly-wired to DQ's, so that's 86.5pF, then the output of the DQ-latch...

    And that's on the *non-bus* side of things... (is this going to affect free-running?)

    Output-High and Output-Low voltages are spec'd at 4mA, too... (but not listed as a PC100 spec). so, hmm...

    So, not sure... There may be some more in-depth pondering to do as we bump up this thing's speed...


    This might be turning into two separate paths...

    One that can be built with a minimum of parts, on a breadboard, etc... and maxes out at a low-speed (30MS/s, currently), depending on your available parts... That's still greatly-functional for many people's needs, especially for something that could be assembled in a weekend from parts-at-hand.

    The other, to achieve 133MS/s, might require more and higher-quality parts; buffers (maybe latches?) in the feedback-path, buffers instead of resistors in the bus-interface and other locations, an additional 8-bit latch for the bus-buffers' output-enables... Probably a couple extra 8bit latches, as the "address-jumping" technique wouldn't then make sense to implement... And, of course, would need to be on a PCB.

    At this point, the second path seems a long ways off, if at all. There's still a lot to be seen regarding just how much can be pushed outta solderless-breadboarding, etc.

  • PiZero now with HDMI!

    esot.eric11/01/2016 at 03:12 0 comments

    In a previous log I mentioned that I finally received my PiZero...

    I haven't done much with it, yet... though I did try a "bare-metal" blinky-example... I think I wrote about it over at #Operation: Try to Bare-Metal the Pi, If I didn't, and you're looking for it, please let me know!)

    But, I think it was that same log, or else one at #Ridiculous [LCD] Display Hacks, where I realized I didn't have a monitor with an HDMI input... So I came up with a ton of ideas of *how* to hack together one of my old displays to accept HDMI... And then I discovered that the PiZero has a composite output, as well. So, yahknow...

    But today! TODAY! I found a LCD-TV in the "free-section" in my building. No shit. With two HDMI inputs, no less! So, now I just need a miniHDMI adaptor and cable, and I'll be set!

    But, seriously, read the ridonculosity that ensued after I got this thing:

View all 51 project logs

  • 1

    Unless you're a masochist, DON'T FOLLOW THESE INSTRUCTIONS. They are not ready... even as a follow-along, as described later. Check out the "Instructions Status" in the last "instruction"... That's all outdated, too.

    NOTE: These instructions are *in no way* complete enough for a functioning sdramThingZero, yet... But I'll add to them as my own prototype progresses. You're welcome to follow along! (lemme know if you do!)

    This Prototype is a low-speed version... probably limited to something like 16MHz due to being built on a solderless breadboard... Faster sampling will definitely be achievable with a custom PCB... but that's a ways off.

    I'll try to make these instructions as general-purpose as possible (for whatever SDRAM DIMM you may choose).

  • 2

    Select a DIMM:

    • SDRAM (PC-66, PC100, PC133...).
    • Preferably SINGLE-SIDED (for this prototype)
      • Double-sided DIMMs will only have half their memory available to this sdramThingZero prototype
    • Sorry, DDR++ support is a long ways off (if at all).
    • SODIMMs (from laptops) are not yet "supported"...

    (Note: For This Prototype I'm using Kingston ValueRam KVR-PC100/32, also marked: 9902384-003.A00 558111 on another sticker and four chips on a single-side marked VG3664164-IDT 04532391U -7L and, more importantly, the PCB is marked 2022364-002 A00

    #sdramThing4.5 "Logic Analyzer", which used the same DIMM since v2.0 used a DIMM simply labelled "PC133 128MB". 8 chips on one side marked ARC USA ARC4V128S30DTP-7 16MX8T3 0052. PCB marked: B6781A

    sdramThing1.0 seems to have vanished into thin-air... I'll try to remember to list its markings when I find it next. However, it didn't make use of the "Side-Kick" (it only used the first 32 data-bits) which is necessary for sdramThingZero.

    Note that it's probably *not* enough to just rely on the markings/stickers, as what really matters is the PCB-layout... Check the "oddities" below. You're a hacker, right? Get out your multimeter!

    For sdramThingZero, the important factor is that there are two separate chip-selects used per side... And I've only run into ONE DIMM that didn't meet that spec. The remainder of the notes, below, are a bit overkill. The odds you'll come across a 168pin DRAM DIMM (not SDRAM) is *quite low* unless you've worked with servers or really high-end workstations, plausibly Macintoshes, or got hand-me-downs from someone who did).

    Avoiding oddities (I've encountered):

    Make sure you actually picked an SDRAM DIMM!

    • It should have a "Serial Presence Detect" EEPROM (8-pin chip on the right-side
      • If not, it's probably a DRAM DIMM (yep, they exist), which will not work
      • If you got it from an old Pentium++ Workstation/PC (rather'n a server), you're probably alright...
    • It should have 84 "pins" on each side with a separator between pins 10 and 11 and another between pins 40 and 41
      • Higher pin-counts probably indicate DDR++, which again is not supported.
    • It should only have 4, 8, or 16 identical ICs in addition to the EEPROM)
      • Additional (non-identical) ICs likely indicates buffered or registered-DIMMs which are not supported
      • If it has e.g 9 identical ICs, it's likely ECC, which should work fine
        • Hey! More bits! Whatcha gonna do with all them bits?
    • Those SDRAM ICs should most-likely have tightly-spaced pins, and a lot of 'em, while also being quite thin (if they're as thick as a DIP, then they're most likely DRAM)
      • If in doubt, try searching for the part-number on those chips...
      • These stupid DRAM DIMMs are rare, but somehow I wound up with as many of them as SDRAM DIMMs... Sorry for making a big deal of it.

    The DIMM must make use of at least two *separate* Chip-Selects:

    1. Get out the multimeter
    2. Verify that there are no shorts between pins 30, 45, 114, and 129
      1. (I have no idea how that manufacturer got away with calling it "PC-100," how it worked at all in many systems, nor how we haven't heard more about a lot of fried motherboards)
      2. (Hey! If you happen to have a double-sided DIMM with 30 shorted to 45, and 114 to 129, but not between 30 and 114, then you might've just found the perfect use for an otherwise shitty DIMM that should never be installed on a motherboard! But I won't go into the details of how to make it work with sdramThingZero, as it's probably rather rare)
    3. Verify that there are two chip-selects, each connected to half of the available ICs:
      1. Put one multimeter probe on Pin30
      2. Slide the other down the pins on each chip until you hear a beep.
      3. Pin30 should be connected to one pin on half of the SDRAM ICs
      4. Do the same for Pin45, it should be connected to the remaining ICs
      5. NOTE: AND BIG TODO:
        1. The chip-selects may be connected to alternating ICs, or e.g.
        2. One chip-select may be connected to four ICs on the left and the other to the four on the right. (NOTE: This is per the Intel PC SDRAM Unbuffered DIMM Specification, located in my 'files section')
        3. This is a BIG TODO: Depending on which chips they're routed to, and more importantly which *byte* pins those chips connect-to, the sdramThingZero wiring may need to be changed accordingly! Hmmmm... The PC100 spec, Section 5, shows that /S0 should route to the ICs associated with DQ0-15 and DQ32-47 (which are on opposite sides of the PCB) and /S2 should route to the ICs associated with DQ16-31 and DQ48-63, this would correspond to the CS's being grouped into "left" and "right" groupings, rather than alternating. Though I have definitely seen alternating. Huh.

    This is my pinout used in sdramThing3.0-4.5 Note the groupings of the Chip-Selects with their associated bytes. #sdramThing4.5 "Logic Analyzer" used an 8-chip single-sided DIMM. This first prototype for sdramThingZero will use a 4-chip single-sided DIMM (due to supplies), the Chip-Select->Byte-Mapping appears to match.

    (Only look at this for the pinout/mapping of the DIMM... this is the *old* schematic... new schematics are in the following steps).

  • 3

    Plan your approach

    For this early prototype, I plan to use a solderless-breadboard...

    I won't be making use of all 32 bits that could be used for logic-analyzing... maybe just a handful for now, I don't feel like soldering *all those pins* for this proof-of-concept. (That's best left for a PCB!)

    Looking again at the image, above, you can see there are still quite a few pins to be soldered-up...

    So, how am I going to connect this thing to the breadboard?

    Normal breadboard-wires are pretty heavy-duty, soldering them directly to the DIMM's pins will most-likely rip up the pins (aka "Pads") after a while. So, it's a good thing to consider.

    I happen to have a bunch of thinner solid copper wire from old phone-wiring... This stuff works well in new breadboards, but old worn-out breadboards may not make a tight contact with these wires... So, again, think about what you've got to work with...

    If anything's gonna fail first, it'll be at the connections!

View all 9 instructions

Enjoy this project?



ksemedical wrote 02/01/2017 at 11:34 point

WOW, truly impressive. I have a few things I am trying to work on, but one side issue is the need of a logic analyzer, this is great work from both real practical and fundamentally interesting (you seem to be at "one-with-" fast fourier transform ha ha (really, great work, I saw some of your soldering handiwork in your pics which is amazing by itself, but this is really great work, and you clearly did very well working with (and recognizing) the other folks (this is really a quite deep project crossing all kinds of normal category barriers. Cool stuff, and I will try to make my needed logic analyzer following this project..... hat's off bro, great stuff

  Are you sure? yes | no

Rogan Dawes wrote 08/31/2016 at 19:53 point

This may be a stupid question, but I hope that I have managed to understand how this works enough to not make a fool of myself!

I'm trying to find ways to capture video from a PC. After using something like a TVP7002 chip to handle the video signal, and turn it into a parallel bit stream (or an equivalent HDMI transceiver/decoder), one then needs to actually do something with that data. That generally requires something capable of really fast sampling, in order to keep up with the video signal.

Would it be possible to have the parallel bitstream feeding in to the SDRAM data lines, and the sync bits used to clock the address lines, so that the video data is written to the SDRAM as long as the appropriate signals are present? My thinking is that when the controller decides that it wants to read in a frame, it would set a line high. This, in combination with the "start of frame" signal (i.e. VSYNC or similar), would then trigger the free running of the SDRAM acquisition, until end of frame. Capture would then stop. At this point, the controller would be informed via an interrupt that a frame had been captured, and could then read it out at leisure, and do whatever is required.

Does this sound feasible?

  Are you sure? yes | no

esot.eric wrote 09/01/2016 at 02:31 point


Some great thought-points in here, as well. I want to get back to you on this when I've got a bit more time. There's a "Star" And "Unread" in my inbox.

But I wanted to say, I think you're spot-on in your understanding of how it works and how it can be made-use-of. 

Totally awesome, thanks!

  Are you sure? yes | no

Rogan Dawes wrote 09/01/2016 at 03:20 point

Excellent! Glad to know I have the basic concept down, even if the details are a mystery! :-)

It's something I've been trying to solve for ages, a cheap KVM, essentially. With this technique, your frame rate is limited only by the rate at which you can send the frames to the client. Enough SDRAM to cache two frames allows for sending only differences, a la VNC.

  Are you sure? yes | no

James Newton wrote 08/08/2016 at 17:56 point

Is there a specific SDRAM that we could purchase which you are pretty sure would work? e.g. is the SDRAM you are using for the prototype available? Or is there an available SDRAM that you think would match the requirements?

  Are you sure? yes | no

esot.eric wrote 08/11/2016 at 19:43 point

Great question... why aren't I listing the models I've worked with...? I'll throw the current model in the instructions "Selecting a DIMM" section... and think about how to approach a list later down the road.

When I get around to designing a PCB, I'll definitely be taking into account flexibility with most *standard* DIMMs (though, things like shorted Chip-Selects from *really shitty* quality-control I can't help).

Thanks for this thought-point. Because of it, I actually took a different route with this prototype than the instructions (and prior versions), using a DIMM socket rather'n soldering directly, so I can test compatibility amongst all the modules I've got. I'll be posting that soon.

  Are you sure? yes | no

Kurt Roesener wrote 08/03/2016 at 06:10 point

I really look forward to see how this project progresses.

Especially since I still have a bunch of these sticks just laying around  ;)

  Are you sure? yes | no

esot.eric wrote 08/05/2016 at 12:09 point

Woot! Thanks for the motivation! 

In my mind, it's already done... The mods from the already-functional #sdramThing4.5 "Logic Analyzer" to make this possible are minor. But... (aside from the sampling-speed improvements) a large part of the point of this "version" is to make it more easily approachable to others. I think it's time to focus on that aspect, and worry about speed later. Thanks for reminding me of that!

And, lo-and-behold, focussing on the "approachability-factor," rather'n speed, means I can use 74xx-series parts already in my collection (from the 80's!) , rather'n having to buy high-speed LVTTL chips :)

After all these revisions, I'm looking at either breaking up some 128MB matched-pairs or using a 32MB DIMM... and as backwards as it may sound, I think I want to keep that matched-pair for my socket-7 mobo in case I ever want to revisit the ol' ISA slots/cards... (and the much-more-sophisticated BIOS settings it offers over my newer systems). 

So, sdramThingZero's prototype may well be much smaller than the prior prototypes... but that's only due to available (unhacked) supplies. And, of course, once this prototype is running (and documented?) Moving on to 133MS/s, a custom PCB, a tremendous amount of more sample-space, and more will be in the works.

  Are you sure? yes | no

jlbrian7 wrote 07/21/2016 at 01:06 point

I just read the blog.  Good job!

  Are you sure? yes | no

esot.eric wrote 07/21/2016 at 03:27 point

Woot! Thanks, bro!

  Are you sure? yes | no

Nimajamin wrote 04/06/2016 at 15:42 point

Fabulous!! This screams to me as being a fundamental tech/technique.. Given that Fpga's are built up of Look Up Tables that are used in this way, with numerous examples of the BRAM blocks in Spartan-6's being used for Fifo's, Serialisers, State Machines, etc.. to name a few. 

Now we've gone from approx 4k to 64Mb!! Awesome stuff. Hats off to you! I'm sure this could be used to build a great many things. :))

  Are you sure? yes | no

esot.eric wrote 04/07/2016 at 03:31 point

Hey, right on! I'll have to look more into this BRAM thing. There, of course, is quite a bit of external work to get an SDRAM to look like a gigantic lookup-table, but now that you mention it, it wouldn't be *that* difficult to, say, have two separate address-busses (for rows/cols) broken out to make it look like one *really huge* lookup-table (as opposed to thousands of selectable 1024-byte lookup-tables).

Got me thinking, yo!

  Are you sure? yes | no

davedarko wrote 03/13/2016 at 16:21 point

thinking form factor here, may some old notebook sdram might work as well?

  Are you sure? yes | no

esot.eric wrote 03/13/2016 at 16:23 point

Indeed, just saw an image of a PiZero with someone holding it, and realized the SDRAM would be quite a bit larger... (Crazy!)

SODIMM might be a great option, especially if this goes somewhere beyond my workbench... But I think my proto will use DIMM since... quantities.

  Are you sure? yes | no

Vikas V wrote 03/13/2016 at 15:57 point

Neat idea Eric. I think this might be the way to go. It also helps that SDRAM sticks/modules are available at throwaway prices. Ultra cool !

  Are you sure? yes | no

esot.eric wrote 03/13/2016 at 16:21 point

Cool, thanks yo! But don't be deterred from trying it the other way! This is one of those "fits together with my other project..." moments, had to take it :) 

Thanks for all the insight on your #Logic analyzer using raspberry pi

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates