As in all engineering related choices, there are tradeoffs that make the decision between FPGAs and DSPs:
Similarities:
->Both are specialty items, with specialty dev. environments and proprietary libraries.
->Both are designed to do fast processing of highly parallel data (DSPs are known as VLIW processors, at least in all of the architectures I'm familiar with).
->Both require knowledgeable specialists to really get a whole lot of benefit from
Differences:
->DSPs were at a point in time much cheaper to build into a product, and sibling comment's mention of the BeagleBone's onboard resources reminds me that they were a big part of TI's business once upon a time. Relatedly, they are often included in SoCs because they're built using the same process node at the fab as the main ARM core. I'm not a silicon expert, so I'll defer to someone else for confirmation of this, but my general understanding is that FPGAs have been built on different transistor designs and such to optimize the LUTs and their routing, causing them to be uneconomical to include in SoCs. Given that both Altera and Xilinx offer such things now, I'm not sure how current that statement is, but there is some amount of engineering tradeoff in the silicon layout itself.
->DSPs are still a processor, with a fixed layout, pipeline depth, etc. that all causes them to be optimal for certain sizes/shapes of data. If your application doesn't meet that, you might be better off with an FPGA.
->On the other hand, an FPGA is more easily scaled to weird data sizes... Do you have a 6 bit super high speed ADC? You very likely want to use an FPGA.
->FPGAs are pretty much the go-to choice when dealing with really high speed sampling. I'm not sure exactly where the line is drawn, but I've worked on a couple of medical imaging devices during internships that both used FPGAs to acquire the data, do some gentle massaging and packaging before offloading it to something else to do real image analysis, image processing, computer vision, etc.
->A sub point to that, the resources on an FPGA that do that signal acquisition are pre-built blocks designed by the FPGA manufacturer and built in regular silicon, so they can acquire data at gigabit sampling rates. You can then apply place-and-route modifications to make sure that all processing of that data gets done on the LUT fabric as close to the signal acquisition point as possible to optimize timing, for example. This is the main area that FPGAs shine in.
->FPGAs have another interesting split: if you need to do complex verification of logic design, you might test on an FPGA and then build an ASIC. If, on the other hand, you're only going to produce, say, 10 MRI machines a year at north of $10 million each, it might not be worth building a custom ASIC, so you just stick an ultra high end FPGA in as a daughter board to the rest of your design. (Read this as "cost plays a major factor in picking FPGA vs. DSP")
Final closing thoughts:
The other major consideration between the two is who you can hire and what they know. A major portion of wireless devices (wifi routers, femtocells, etc.) uses a DSP to do the heavy lifting on the signal processing after the analog front end, so those companies have a lot of built in history, available example code, training for new engineers and an expectation that older engineers from a competitor will be used to that same technology. Medical device manufacturers, oscilloscope manufacturers, etc. have the opposite expectation since they've been using FPGAs for years. Once you're used to paying a particular license fee to Xilinx for the IP Cores you just dropped into your design, you're unlikely to be able to sell your boss on getting a bunch of custom code written by TI to make their DSP work as well, so you'll be using what the tech stack already calls for.
One thing that might tip the balance in 2018: there's a growing familiarity and body of open source knowledge now around fpga signal processing among the sdr community.
There are now a lot of well documented open source fpga-based data acquisition boards being sold today at comparatively rock-bottom prices - we just call them sdrs.
The bandwidth requirements for ultrasound would seem to fall easily within the open source state of the art.
Similarities:
->Both are specialty items, with specialty dev. environments and proprietary libraries.
->Both are designed to do fast processing of highly parallel data (DSPs are known as VLIW processors, at least in all of the architectures I'm familiar with).
->Both require knowledgeable specialists to really get a whole lot of benefit from
Differences:
->DSPs were at a point in time much cheaper to build into a product, and sibling comment's mention of the BeagleBone's onboard resources reminds me that they were a big part of TI's business once upon a time. Relatedly, they are often included in SoCs because they're built using the same process node at the fab as the main ARM core. I'm not a silicon expert, so I'll defer to someone else for confirmation of this, but my general understanding is that FPGAs have been built on different transistor designs and such to optimize the LUTs and their routing, causing them to be uneconomical to include in SoCs. Given that both Altera and Xilinx offer such things now, I'm not sure how current that statement is, but there is some amount of engineering tradeoff in the silicon layout itself.
->DSPs are still a processor, with a fixed layout, pipeline depth, etc. that all causes them to be optimal for certain sizes/shapes of data. If your application doesn't meet that, you might be better off with an FPGA.
->On the other hand, an FPGA is more easily scaled to weird data sizes... Do you have a 6 bit super high speed ADC? You very likely want to use an FPGA.
->FPGAs are pretty much the go-to choice when dealing with really high speed sampling. I'm not sure exactly where the line is drawn, but I've worked on a couple of medical imaging devices during internships that both used FPGAs to acquire the data, do some gentle massaging and packaging before offloading it to something else to do real image analysis, image processing, computer vision, etc. ->A sub point to that, the resources on an FPGA that do that signal acquisition are pre-built blocks designed by the FPGA manufacturer and built in regular silicon, so they can acquire data at gigabit sampling rates. You can then apply place-and-route modifications to make sure that all processing of that data gets done on the LUT fabric as close to the signal acquisition point as possible to optimize timing, for example. This is the main area that FPGAs shine in.
->FPGAs have another interesting split: if you need to do complex verification of logic design, you might test on an FPGA and then build an ASIC. If, on the other hand, you're only going to produce, say, 10 MRI machines a year at north of $10 million each, it might not be worth building a custom ASIC, so you just stick an ultra high end FPGA in as a daughter board to the rest of your design. (Read this as "cost plays a major factor in picking FPGA vs. DSP")
Final closing thoughts:
The other major consideration between the two is who you can hire and what they know. A major portion of wireless devices (wifi routers, femtocells, etc.) uses a DSP to do the heavy lifting on the signal processing after the analog front end, so those companies have a lot of built in history, available example code, training for new engineers and an expectation that older engineers from a competitor will be used to that same technology. Medical device manufacturers, oscilloscope manufacturers, etc. have the opposite expectation since they've been using FPGAs for years. Once you're used to paying a particular license fee to Xilinx for the IP Cores you just dropped into your design, you're unlikely to be able to sell your boss on getting a bunch of custom code written by TI to make their DSP work as well, so you'll be using what the tech stack already calls for.
(edit: formatting)