4 ms·
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
by bcrl 2y ago
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.
- CuriousCosmic 2y agoThey 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.
- ckemere 2y agoYes, 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.
- bcrl 2y agoAdapter 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.
- ckemere 2y agoTotally! 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...