If you haven't noticed yet, I have a bit of a thing against moving this project to FPGAs...

The simple answer: A powerful enough FPGA and the right "software" loaded on it would basically be an entirely different project, rendering useless dang-near everything that makes this project what it is.

There's no question FPGAs can interface directly with SDRAM. Just take a look at the supported logic-analyzer devices at sigrok's site... a *significant* percentage of them use an FPGA and an SDRAM.

That's not to say it isn't a good way to go, nor to say it wouldn't be worthwhile for someone *to* implement this project *with* FPGAs... especially if they happen to have 'em in stock already.

The design goals of this project are, and have always been, to do as much as possible with nothing more than easily-available and commonly-understood parts likely already in many parts-bins (or worthy of being stocked, if not!)... to make the implementation-details as accessible as possible. As well as to make use of the SDRAM's inherent features whenever possible. Remember, SDRAM is, on its own, a state-machine of sorts. Atop that, it has latched-outputs, has direction/enable signals much like any bus-interfaced memory or I/O device, or even similar to an AVR's GPIO ports... These features can be made-use-of to make the memory a "processor" of sorts--a processor as fast as the memory itself--and that is very much the goal of this project...

But just because that's how *I've* implemented/documented this project doesn't mean that one couldn't make their own, moving all that glue-logic to an FPGA, and even expand on the system's functionality.

Others can reproduce it with minimal single-source components, but more importantly others can improve on it. Isn't that kinda the point of open-hardware?

------

So, now, we have a couple "One-Shot" circuits which use several latches and gates, and the Trigger-circuit isn't particularly uncomplicated. These guys could *easily* be handled by, say, programmable-logic... Reducing numerous glue-logic chips down to one single FPGA/CPLD...

Unquestionably.

Is it a good idea? Probably, especially if you're making a product, or have FPGAs laying around and already have the skillset/tools to use them.

--------

But, if you're still questioning why *I* am implementing this project with glue-logic rather than an FPGA...

I won't lie, I have a bit of "FPGA-avoidance syndrome." Welcome to my world.

But, let's look at this a bit differently...

As it stands, this project is a work-in-progress. A functional prototype that keeps improving.

Some might suggest, then, that having an FPGA in the mix would make prototyping that much easier... Just change the logic via a text-editor, rather'n on a breadboard! And, with the right FPGA they'd probably be right.

Herein lies the (or at least *a*) difficulty...

FPGAs with enough I/O pins to handle an entire SDRAM DIMM are... Well, lemme rephrase that. We already know that this thing can sample 32 parallel data-bits... So, our FPGA would need 40 I/Os merely to whittle those 32 data-bits down to an 8-bit bus (for read-back). That whole chunk of our FPGA would be doing little more than what a handful of 7400-series chips can do... and that doesn't even begin to handle things like the one-shot circuitry and trigger. (Nor the potential of adding a second DIMM in the mix for sampling up to 96 bits!). The "Free-Runner" (if we choose to still use it, when we've already got an FPGA capable of implementing it) would require at least 19 additional I/Os just for the Command/Address lines (which are tied-back to data-lines on half the SDRAM). Say we drop the immediately-fed-back signaling, an FPGA could handle that much faster than the time it takes to "boot" the Free-Runner... then we've got 19 command/address lines and several additional data-lines (64 total)... now we're talking 80+ I/Os. Now we're talking a pretty sophisticated FPGA... TQFP-100 seems reasonable, but don't forget all the power, clock, and other lines that are involved... now we're talking BGA.

So, let's scale it back, again... Say we keep the "Free-Runner", the directly-fed-back address/command lines, and we continue to use 7400-series latches/buffers for whittling the data-bus down... Now we only need, maybe, a handful of I/O's for e.g. the one-shots, the trigger-handling, etc... Basically replacing only the glue-logic with programmable-logic... alrighty! Well, frankly, at that point we could use a 22V10 GAL, or two, if we can find 'em fast-enough. And, therein lies another problem... Most of the FPGAs I've seen in smallish I/O counts are not fast enough... 133MHz is asking a lot of these things. That's not to say they don't exist, but I haven't seen 'em.

But, there's a bigger problem... We're still talking about prototyping, here... And, in several cases, it's turned out that I need to add another pin, here or there... Which means we really should've fed those signals through the FPGA's I/O's in the first-place... Now our FPGA's I/O count goes up again... Then there's discussion of complex-triggering, which means we need at least an additional 32 I/Os for that... And... we're back to a BGA and an FPGA more than capable of doing everything the Free-Runner does--again a completely different project.

--------

Here's another thought-point... Over the past several logs I've been working on the (simple) trigger-handler (with circular pre-buffer). In the latest design I've removed the need for two control-signals ("Safe-To-Trigger" and a second "Chip-Select"), I also removed the need for several additional gates. Had I done this with an FPGA from the start, there would've been no reason to do that "whittling"... my original "bloatware" would've done the job, but would've been that much more complicated, and that much harder to implement in glue-logic should someone decide they want to spend a weekend building a logic-analyzer with parts they have on-hand or could likely pick up at a local electronics-supplier.

--------

So... I'm not saying there's no justification for an FPGA/CPLD or any programmable-logic in this project... In fact, it might be a great approach to a reimplementation of this project... But I don't see its being within the spirit of this implementation of this project's goals...