And that's pretty much it- Lattice includes "Reveal" a logic analyzer which can run on the FPGA in their tools. It's intended to debug designs, but there is nothing stopping you from capturing data from pins. Pretty sure it would capture signals up to ~200 MHz.
When your entire chip is programmable-logic, you don't have much room for RAM. The MachXo3LF-6900 has a grand total of 240 kBITs, or 30kBytes of storage.
In contrast, the STM32F746G will get you 320kBYTES of storage, 10x the capacity.
At 75MHz and 1-bit per cycle, that's still only 35ms of storage. Furthermore, it'd be a lot easier to program a Microcontroller to compress the data as its reading it, rather than use the FPGA.
The Microcontroller will still get you the Ethernet and USB connections too.
--------
I think this is a job for a microcontroller, not an FPGA. FPGAs are nice and flexible of course, but Microcontrollers offer you far more performance if you're going to use the specific features.
The STM32F746G has GPIO -> DMA directly to its RAM, while the CPU can compress 1/2 of the signal and send it out while the GPIO pins are simultaneously working. That's... pretty good. I have doubts that a cheap FPGA can accomplish all that at the same speed.
I believe the FPGA is often being used for converting fewer high speed inputs, to a greater number of lower speed outputs for the GPIO of the FX3, I think that's called SerDes (please correct me if I'm using that phrase incorrectly).
Speed isn't the only consideration here. 5x the speed needs 5x the RAM to store it in. But FPGAs will NEVER have as much RAM as a dedicated microcontroller.
Again, you're looking at ~320kBytes on the $25 STM32 microcontroller board, against ~30kBytes on the $25 FPGA board. With 1/10th the RAM, the FPGA will store far less useful data.
The typical Oscilloscope is like 100MHz. Getting a cheap 75MHz logic analyzer is perfectly acceptable. Storing and processing all that data (ie: outputting it to an Ethernet port) start to become the main issues once the speed issue is solved.
In my experience, those small FPGAs run out of room rather quickly too. Throw down something as simple as a Wallace tree multiplier and suddenly half your LUTs are eaten up.
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.
Sure, an FPGA does the job faster, but how popular are the FPGA boards compared to something like STM32 Nucleo? What we are trying to achieve is make a software logic analyzer that will work on top of the hardware that everyone has for prototyping anyway. 8 boards is just the beginning...
When your entire chip is programmable-logic, you don't have much room for RAM. The MachXo3LF-6900 has a grand total of 240 kBITs, or 30kBytes of storage.
In contrast, the STM32F746G will get you 320kBYTES of storage, 10x the capacity.
At 75MHz and 1-bit per cycle, that's still only 35ms of storage. Furthermore, it'd be a lot easier to program a Microcontroller to compress the data as its reading it, rather than use the FPGA.
The Microcontroller will still get you the Ethernet and USB connections too.
--------
I think this is a job for a microcontroller, not an FPGA. FPGAs are nice and flexible of course, but Microcontrollers offer you far more performance if you're going to use the specific features.
The STM32F746G has GPIO -> DMA directly to its RAM, while the CPU can compress 1/2 of the signal and send it out while the GPIO pins are simultaneously working. That's... pretty good. I have doubts that a cheap FPGA can accomplish all that at the same speed.