The "embedded" solution is: buy embedded on-board SRAM when you need it, and if necessary, buy an embedded on-board SRAM memory controller if you need it. Building your own memory-controller out of an FPGA sounds like hell to layout.
Anyway, if we're talking about cheap stuff, DDR3L isn't the technology of note. This is about simpler SDRAM-level stuff, maybe a few MB at a time is sufficient.
----
Furthermore: How many LUTs will your memory controller take up?
According to this, Lattice's DDR3L 16-bit memory controller is 2500 LUTs. The $25 FPGA only has 6300-LUTs, so you've already used up 40% of the chip on just memory-interfacing!
Yeah, you can accomplish a lot with a $600 FPGA with a Million-bajillion-LUTs and embedded cores. But at the $25 price point, FPGAs often run out of room. You don't have many LUTs to work with.
Dollar-for-dollar, a microcontroller will outperform an FPGA in most tasks. That's just the facts. ASIC-implemented memory-controllers and ASIC-implemented large banks of internal SRAM just work better for computer-like tasks.
FPGAs should be used for custom logic that isn't typically handled by a microcontroller / microprocessor. Not memory-controllers and ALUs that already exist in an easily packaged form. There's a reason why high-level FPGAs have embedded ARM cores and embedded memory-controllers in them (alas: such technology is likely out of the reach of cheap $25 FPGAs)
Includes 45K LUT FPGA with 250KB on-die RAM, DDR3, controller license and PCIe.. Actually this is so cheap I wonder if they are about to discontinue it.
Anyway, I otherwise think the capture the data with the DMA trick is cool. There are a bunch of projects which do the reverse: generate video with SPI output with tricks to make jitter free sync signals.
Only 1/3rd for the DDR3 controller? That's a great result, given the remainder of a logic analyzer is.. well let's just say there is not much to it, even with protocol decoding.
The point here is: you can get the DDR3 IP block, put it into your FPGA, and your timing will still work just fine. Which is of course kind of a big deal here. I can't put close to the level of logic in a DDR3 interface in a microcontroller and still have it hit the correct timing; all of that pretty much falls apart at the mention of "pipelining" or "vectored interrupt controller". Try doing protocol decoding on the same microcontroller that does the sampling.
Erm, you just buy a microcontroller that supports DDR3 out of the box if you care about large amounts of RAM. There are literally thousands of microcontrollers out there, with a configuration for every single possible task imaginable.
In contrast, you "contact the sales office" of an IP-block of Verilog and read through a ton of FPGA documentation.
I mean, if you really want to just "buy one chip" and do everything with it, be my guest. But honestly, its sometimes easier to just go to a different page in Digikey and buy what you need, instead of trying to build everything you need every time.
I don't think you quite realize what kind of microcontrollers would even come with a DDR3 interface. But if you want to waste away a > 500 MHz chip with sampling GPIO and DMAing that to memory (good luck hitting anything close to what an FPGA could do here, that kind of chip tends to come with multiple levels of caching, pinmuxing, ...) you must have a large BoM and power budget.
Point. I think most of the chips I was thinking about are simpler SDRAM controllers.
Nonetheless, I still think that you're grossly underestimating the needs of the FPGA / Logic Analyzer. The product communicates to the PC over USB for instance, performs RAM-level compression and seems to handle some logic-analyzing tasks as well (considering it natively supports I2C, UART, and the like).
EDIT: I think I see where you're coming from now. The next steps then would be licensing issues then. Like whether or not a company could effectively sell the IP-block of the memory-controller and distribute it over the internet (as what has happened in this project).
Throw down a single DDR3 Memory chip, and you've already eaten up like half the $25 hardware budget.
http://www.digikey.com/product-detail/en/micron-technology-i...
The "embedded" solution is: buy embedded on-board SRAM when you need it, and if necessary, buy an embedded on-board SRAM memory controller if you need it. Building your own memory-controller out of an FPGA sounds like hell to layout.
Anyway, if we're talking about cheap stuff, DDR3L isn't the technology of note. This is about simpler SDRAM-level stuff, maybe a few MB at a time is sufficient.
----
Furthermore: How many LUTs will your memory controller take up?
http://www.latticesemi.com/en/Products/DesignSoftwareAndIP/I...
According to this, Lattice's DDR3L 16-bit memory controller is 2500 LUTs. The $25 FPGA only has 6300-LUTs, so you've already used up 40% of the chip on just memory-interfacing!
Yeah, you can accomplish a lot with a $600 FPGA with a Million-bajillion-LUTs and embedded cores. But at the $25 price point, FPGAs often run out of room. You don't have many LUTs to work with.
Dollar-for-dollar, a microcontroller will outperform an FPGA in most tasks. That's just the facts. ASIC-implemented memory-controllers and ASIC-implemented large banks of internal SRAM just work better for computer-like tasks.
FPGAs should be used for custom logic that isn't typically handled by a microcontroller / microprocessor. Not memory-controllers and ALUs that already exist in an easily packaged form. There's a reason why high-level FPGAs have embedded ARM cores and embedded memory-controllers in them (alas: such technology is likely out of the reach of cheap $25 FPGAs)