Comment by bcrl | Hacker News Reader

Comment by bcrl | Hacker News Reader

Parent Full thread

So you want to pay for less than 1 week of dev time? Almost nothing can be done on an FPGA for that little amount of money beyond the smallest of changes to an existing design. Heck, the cost of simply getting your completed circuit board with the FPGA tested by an engineering firm that gives you the required FCC certification before you can ship your product starts at $10k. Realistically you need a bare minimum of $50k to bring a simple commercial hardware project to market when you understand the niche and already have the ability to deliver the firmware and software without significant external (paid) effort.

I took the time (and it takes time) to learn a bit about FPGAs (playing around with 1Gbps and 10Gbps ethernet as well as PCIe 1.0 x1 and 3.0 x4), and if you want to actually do something new, there is a lot of time to spend on learning the various protocols a given design will touch or implement. Most of the sample code on $vendor's website is shoddily thrown together and breaks as soon as you breath on it wrong. When you do anything interesting with networking protocols the constraints of clock speed and bandwidth make things extremely complicated with oodles of corner cases as you do things like use wide busses at low clock speeds where packets can start at multiple offsets in the bus. You can build on top of something like the NetFPGA project, but that only works if what you're building is close to an existing well known niche. But if you're just flinging packets, there are far less costly (especially in time) frameworks to play around with things.

I'd say away from building custom FPGA based hardware until the performance benefit will increase sales a factor of 100-1000x (depending on complexity) to cover the cost of the hardware. But keep in mind that it's harder and harder to compete with commodity x86 servers. In the past, every cell phone base station used FPGAs to do the signal processing. Today's 5G networks do most of the signal processing on servers because you can do cool things like noise cancellation across nearby antennas when all the data is in the same place, and the software developers to produce those changes are going to cost far less than a team of the size needed to support the same rate of change on an FPGA.

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.

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