Eric HertzTurn 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!
http://hackaday.com/2016/03/15/sdram-logic-analyzer-uses-an-avr-and-a-dirty-trick/
(Thanks Al Williams!)
http://hackaday.com/2016/07/19/hackaday-prize-entry-the-cheapest-logic-analyzer/#comment-3094325
(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 Hackaday.io, 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: https://sites.google.com/site/geekattempts/home-1/sdramthing 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+ RPi can't do!)... Sacrificing half of a 128MB DIMM--which was already in the trash--in order to gain 64MB of raw sample-data and no need for a custom controller seems totally worthwhile!
(I want to take a moment to thank @frankstripod, @James Newton, @Al Williams, and many others who took the time to understand this obscure project amidst all the even-more-obscure explanations I gave! Oh, and just discovered this recently: http://www.epanorama.net/newepa/2012/10/11/diy-logic-analyzers/ Cool!)
-------------------------------
"sdramThingZero" is a bit of a play on words...
The PiZero is definitely an intriguing "host" for this new venture in sdramThing, being that the PiZero has capabilities for display, user-interface, can run Linux and other open-source software, and has plenty of processing power (and internal memory) for doing-so.
Second... And, really, more importantly, sdramThing, previously, required *precision timing* which was only achievable via tight-coupling with the "host" (AVR) and the assembly-based instructions necessary for such precision-timing. This new venture in sdramThing attempts to relieve those tight timing-constraints such that it could run on any host, regardless of timing-ability. Thus, this new iteration (sdramThingZero) is no longer host-dependent, it's host-less, it haz zero onboard hozt. sdramThingZero is more of a peripheral rather than a complete system. And is done-so with little more than an SDRAM DIMM and a bit of glue-logic.
-----------------------------
Current status (UPDATED):
sdramThingZero is "Free-Running" at speeds greater than the host, and soon to be sampling/outputting data!
The vast-majority of concepts remaining to be implemented in sdramThingZero have been well-proven in the long-functional #sdramThing4.5 "Logic Analyzer"... so it's really just a bit of plug-and-chug, at this point.
BUS: The limited number of GPIOs available on most Single-Board-Computers (and other interfaces) necessitates whittling down the number of pins on the SDRAM DIMM to a more manageable "bus"-like interface. I'll probably go with something similar to the 8051-style bus-interface, which (pretty cool) is also supported by e.g. the FT2232H, meaning that sdramThingZero could be directly interfaced via USB2.0, with nary a microcontroller inbetween!
Previously, I'd intended to go straight to that bus-interface with this project. Though, doing-so also limits the speed that the host can read-back the data sampled. SO... I'm taking a new approach: I'll be designing this system with regular-ol' GPIOs in mind, at this point, via high-pin-count microcontroller. Once a board is designed, it can be connected to a daughter-board which then whittles that pin-count down to the desired bus. For the 8051-style bus, this can be accomplished with nothing more than some D-latches and some network-resistors.
CKE: This project--interfacing Synchronous DRAM to a completely asynchronous host--was previously deemed "impossible" by myself, as a result of the precision-timing necessary for sdramThing<=4.5... And then, a breakthrough:
https://hackaday.io/project/4159/log/33427-cke-well-shit
THAT concept has now been proven-reliable!
CLOCK: There's the clock-source which has yet to be determined... sdramThing4.5 used a dedicated crystal-oscillator, but a clock-generator might be in-order to allow for different sample-rates.(External-clocking? Must be *steady* (e.g. pixel-clocks, but not e.g. I2C), and in the MHz(?)... Also: switching clocks for Free-Running and read-back?)
PCB: Currently, sdramThingZero is running at speeds up to 23MHz on a solderless-breadboard. sdramThing4.5 was limited to 30MS/s, likely due to the utter ratsnest of point-to-point wiring on its soldered-breadboard, as well as due to the speeds of the old 74-series chips used. A PCB with decent shielding and some amount of trace-length matching (as well as consideration of added-delays e.g. by multiplexers) should improve those speeds dramatically.
POWER: SDRAM DIMMs may take a bit of power... I'm not certain how much is available from, e.g., a PiZero, another power source may be necessitated.
GUI? There's no reason sdramThingZero needs to be limited to logic-analysis in the GUI-sense... It could also be used, e.g., as a data-logger, oscilloscope, peak-detector, etc.
But, as a logic-analyzer, the most-useful interface might be via a GUI... I don't plan to write one, myself, as I'm sure there are already those that are much more sophisticated than I could come up with. I have yet to do a deep search for existing open-source tools, but have heard good things about sigrok. (If you've other suggestions, let me know!)
Still, there needs to be developed a driver/ interface between e.g. sigrok and the GPIOs or USB device connecting to sdramThingZero.
TRIGGER: This is to-be-determined, but my vague-idea, at this point, is a simple trigger (one input, High or Low), with a circular pre-buffer before-hand. This could likely be accomplished on the "Free-Runner" by e.g. outputting an additional "Chip-Select" data-signal--one for the circular-buffer, and another for the regular-sampling. The trigger-input, then, is the select-input of a 2:1 multiplexer which routes one of the two chip-select outputs back to the actual chip-select control-signal. Similar could also likely be accomplished via an address-signal.
"DDR" emulation: Simply connect two opposite-edge-triggered D-latches to each input-signal, fed into two separate SDRAM pins, and now we're talking 16ch 266MS/s :)