Hacker News Reader

Comment by CuriousCosmic | Hacker News Reader

They never mentioned building custom hardware anywhere and tbh I don't see why you would need to when reasonably cheap FPGA hardware already exists.

Alinx provides a bunch of cheap FPGA development platforms including SOMs that you can use with custom boards without needing to design the whole thing from scratch.

I'm willing to bet that unless they are doing something particularly exotic, they can probably complete their project using COTS parts without a single custom piece of hardware.

View on HN

Yes, absolutely. My preference is a devboard, to be honest. My goal is something that I can share for ~free with other labs who'd need to order the parts themselves. I'll likely have to spin an adaptor PCB, but ideally quite trivial. So just firmware, and I'm happy to write associated code in Linux.

Adapter PCBs still have to be emission and safety tested before you can start selling them. I have family in Germany that had been making and selling bee scales for almost 25 years across Europe up until compliance became extremely costly due to new regulations. Even minor changes (swap to an alternative part footprint due to EOL?) to PCBs trigger re-certification, and that is part of the lifecycle challenge in the embedded world. Certainly if people are making and assembling the boards themselves that throws a lot of overhead out of the equation.

I am quite curious what space you are doing this in... FPGA hacking can be a lot of fun. And it can be mindnumbingly tedious when you miss a subtle detail on a data sheet that makes the difference between an ethernet link working 100% of the time versus merely 98% of the time (Marvell gigabit ethernet phys are quite sensitive to the exact sampling time of data sent over GMII relative to the clock in a way that National Semiconductor gigabit phys are not. This requires setting a delay on the I/O buffer of the FPGA to make gigabit ethernet work reliably on the old Xilinx SP605). Having multi-hour build times for moderately complex designs to synthesize slows development down.

If you're doing anything with high speed SERDES (ie >= 10Gbps ethernet), know that Xilinx transceivers require insanely complicated witchcraft that involves incantations that only the most seasoned FPGA developers have learned. Clock routing between adjacent transceiver quads with the right wires going to the right PLL is bonkers to figure out on your own. Altera is a lot simpler, but the Polarfire transceivers were probably the easiest to get working.

Let us know how deep down the rabbit hole you venture.

Totally! Another reason why sticking with a pre-populated dev board (like the Zuboard) makes life easier on many levels. My application is basic neuroscience, so we're looking at slow signals, each channel is ~25 kSps, so we're at bleeding edge electrode technologies before we get to 10 Gb.

I actually teach a microcontroller class to sophomores/juniors. I'd love to build a multi-semester curriculum where we'd end up at crazy speeds, but it takes a lot of work to cover all of the theory (E&M and system) required...

25kSps sounds like it would work well using something like the RP2040. The PIO blocks would let you implement the sampling triggers with decent realtime accuracy, and it's an order of magnitude cheaper than most FPGA boards. External muxes are fairly cheap and easy at that relatively low sample rate. Sounds like a fun project!

I’ve spent several evenings pondering the PIOs and whether I could adapt them to this project. I think there’s a reasonable chance that the answer is yes for the new RP2350. For the aforementioned 25 ksps per channel, I actually need something like a 25 MHz clock (64 channels at 16 bits). With the original 2040, I convinced myself it would be hard without overclocking. But with the new one quite possibly possible. Handling variable cable delays of 8-10 bits also requires buffering in a way that I couldn’t quite wrap my head around, but I bet someone could!

That's 25 MHz if you're doing everything serially, but you could probably do it with a 11 or 12 bit parallel bus. There are ADCs on the market that have parallel rather than serial interfaces. The only reason I'm suggesting this is because 25ksps is a rate that's low enough that the headaches of using a parallel bus are minimal.

Deskewing isn't all that hard to do, and there are plenty of designs you can steal ideas from. FPGAs generally have FIFOs in the SERDES that are used to deskew multilane protocols like PCIe or 40/100Gbps ethernet (in QSFPs). You bit/byte slip during training until things sync up, then throw an error and retrain if sync bits don't match what's expected (to keep the check in the fast path cheap). That should work in software as well, but it could very well be challenging at 25MHz. Those are but a couple of the reasons serializers / deserializers are giant complicated bits of intellectual property found on virtually every chip these days.

Reply on news.ycombinator.com