New to FPGA, but considering it for ADC decimation - Page 1
Forum section: electronics / general

author: Amish_Fighter_Pilot
author_rank: Regular Contributor
timestamp: June 29, 2025, 11:43:28 am
content: Hello. I am putting together a flexible system that is basically a software defined radio. I'm currently trying to pick an ADC module and I am likely going to be using the AD9248 as the best compromise because I can find Chinese boards for them and I am very poor. This ADC is probably overkill considering I am mostly working in the 0-1MHz range, but the next step down uses more power and delivers a lot less performance(AD9220).So I want to process the input from the card(which will be sampling the output from my AD831 mixers), but I am unclear on how much FPGA power I need for that. I know I can run a 65msps load through a RP2350 thanks to a project I found, but it seems like everyone prefers FPGA for data decimation.My plan originally was to decimate the stream with the RP2350 and then process it further on an Android device, but maybe I should just process it entirely on the FPGA? I'd love to involve a bit of machine learning to make the device useful for telemetry and other anomaly detection. Does FPGA do that well? Should I still use the RP2350 to run my DDS boards and other MCU tasks and dedicate the FPGA to decimation work? Whatever solution I use: power is an important consideration. I think I'll still control it all via Android because I have tons of old Android devices and can't afford a good dedicated touch screen anyway.Can anyone recommend an FPGA to start with? What about the Tang 25K? Is that powerful enough to do my project with some room to breathe? Is there some other brand or model that would be a wiser choice?

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: June 30, 2025, 01:34:40 am
content: This you ?because it was me with the long answer about doing it on XMOS/RP2350If you're not familiar with FPGAs, I'll caution that it's quite the learning curve to start off with - I'm only saying that because "doing machine learning on an FPGA" isn't necessarily beginner stuff. You have to get used to working at a much lower level than C/C++ on a CPU, even if it's just for wiring other blocks of hardware together. I'm not saying it's impossible - I'm a software guy that uses FPGAs on occasion, but it's not a straight skill-match, not by any means. I may in fact be underselling the difficulty here, I found it "not terrible" but others have struggled quite a bit.

author: Amish_Fighter_Pilot
author_rank: Regular Contributor
timestamp: June 30, 2025, 02:24:51 pm
content: Yes, thank you for the replies. I feel like I really need to learn FPGA regardless of it's value on this project. I may have to keep my FPGA component of this project simple and do the more complicated final processing of the data at the Android/PC level. My C skills are rusty AF to be honest, but I've jumped down a rabbit hole on this project and now I can't stop. I'm not sure if you're familiar with autistic obsessions, but I'll eventually learn any and all skills needed to make it happen because doing otherwise just isn't an option....I need to email the author of that HSDAOH project and see how they think the RP2350 works for the job comparatively.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: June 30, 2025, 04:33:03 pm
content: Replying here because it's easier with imagesSo now I know you're more of a hardware person, the FPGA does make some sense. I still think you have some significant learning ahead of you if you go that way but that's all part of the funSome things to consider for FPGAsYou need to get used toeverythinghappening in parallel. Even when you don't want it to...A test harness is your friend, you'll need to simulate (and simulate, and...) pretty much everything. The design should probably be "proven" to work by the simulator before you even consider transferring it to the FPGAAnd then it's unlikely to work first time because you did some things in the simulation that the FPGA doesn't support, or there's metastability as you cross clocking zones, or your clocks aren't set up correctly in the first place, or...Speaking of clocks, there is a consipiracy to make the syntax for "give me a clock at this frequency that just bloody works" completely unintelligible to anyone who hasn't got so much experience that it's leaking out of them. Ok, it's not that bad, but it's a pretty steep learning curve.You'll also have to get used to the tools - I've heard various vendor tools described as "pushing on a rope" - sometimes coding it *this* way is necessary for one vendor and coding it *that* way is needed for a different vendor. You just have to learn.On the other hand, once you "master" them, FPGAs can be awesome tools in your grab-bag.Having said all that, I still think the XMOS idea is probably worth an investment of time, at least understanding if it would work for you. The board I have right now (this isn't proven yet) looks like:or as a 3D render:I think something like this would work fairly well for you. In fact (at a push) something *exactly* like this would work well - the edge connector consists of a 16-bit bus, a 15-bit bus (address, in my case) and 4 1-bit signals, and there's another 16-bit bus going to the USB3 port which can support 200MByte/sec. Since the edge-connector bus is software-defined, you could do whatever you wanted with those pins.The built-in USB2 port of the XMOS chip is exposed in the middle, and there's a RP2040 (I didn't need the pins of the 2350) to act as a "board controller". The RP2040 has control over the flash attached to XMOS and can hold the XMOS in reset while it writes to the XMOS's QSPI flash. There's the usual boot/reset buttons for the RP2040 so you can just attach the board to a PC, run the boot cycle, upload a flash image that contains the code for both XMOS and RP2040 and the RP2040 will flash the XMOS on next boot.There's also (though not necessarily useful for you) 16MB of SDRAM there, voltage level converters on the edge-connector, and an I2C bus (which I intend to use to drive a display).

author: Amish_Fighter_Pilot
author_rank: Regular Contributor
timestamp: July 02, 2025, 12:59:16 pm
content: Thanks for all the excellent feedback. Like usual: the feedback I get here sends me down rabbit holes of learning.I found this excellent idea for synchronizing timing and thought it would be relevant:https://youtu.be/dAa5hcjiqz0?si=vhh5ZLY7ZBfF2WCb

author: zapta
author_rank: Super Contributor
timestamp: July 12, 2025, 02:43:28 pm
content: If you go with the FPGA approach, I recommend Apio, an open source FPGA toolbox that was designed for easy of use with commands such as 'apio build', 'apio sim' and 'apio upload'.Home page:https://github.com/FPGAwars/apioDocumentation of latest version:https://fpgawars.github.io/apio/Daily releases:https://github.com/zapta/apio-dev-builds/releasesIf you happen to have python installed, you can just run this to install Apio as a pip packagepip install --force-reinstall -U git+https://github.com/FPGAwars/apio.git@develop(I am an Apio user but also contributed code recently)