Okay then. I wanna know of a better way to take four 1 GSPS signals, demodulate them, and pump out another two 1 GSPS signals which encode decisions made every every four samples on the incoming signals. That's ONE of the problems in quantum control for stabilizing one qubit. We did it with an FPGA. If you know of a DSP or systolic array or processor or what have you for doing this, I'm ALL ears. Oh and the timing must be COMPLETELY deterministic down to the nanosecond.
In fact, if you know of ANY general purpose hardware that will talk to gigasample ADCs/DACs, I'd love to know about it.
ASIC. The timing will be better. Less power will be burned.
The only thing an FPGA wins on is NRE (non-recurring engineering).
The real problem is that the giga-sample DAC's/ADC's aren't willing to speak one of the actual high-speed interfaces or put a DSP directly on the ADC/DAC. So, everybody needs to use an FPGA to shoehorn the data into a useful form.
If somebody put an actual DSP on their ADC/DAC, FPGA's would evaporate for this application like they have evaporated for so many others.
Any FPGA application with volume eventually gets subsumed by special purpose hardware on a microcontroller. For example, people used to use FPGA's for PWM, motor control, etc. Now those blocks are standard on microcontrollers.
The grandparent is responding to the article, which is talking about general purpose computation. There's no question that your application is a prime use case for an FPGA.
Comments
Okay then. I wanna know of a better way to take four 1 GSPS signals, demodulate them, and pump out another two 1 GSPS signals which encode decisions made every every four samples on the incoming signals. That's ONE of the problems in quantum control for stabilizing one qubit. We did it with an FPGA. If you know of a DSP or systolic array or processor or what have you for doing this, I'm ALL ears. Oh and the timing must be COMPLETELY deterministic down to the nanosecond.
In fact, if you know of ANY general purpose hardware that will talk to gigasample ADCs/DACs, I'd love to know about it.
ASIC. The timing will be better. Less power will be burned.
The only thing an FPGA wins on is NRE (non-recurring engineering).
The real problem is that the giga-sample DAC's/ADC's aren't willing to speak one of the actual high-speed interfaces or put a DSP directly on the ADC/DAC. So, everybody needs to use an FPGA to shoehorn the data into a useful form.
If somebody put an actual DSP on their ADC/DAC, FPGA's would evaporate for this application like they have evaporated for so many others.
Any FPGA application with volume eventually gets subsumed by special purpose hardware on a microcontroller. For example, people used to use FPGA's for PWM, motor control, etc. Now those blocks are standard on microcontrollers.
I'd LOVE to make an asic, but we're a small lab and don't have that much to spend.
Exactly. It's not that an FPGA is better, more flexible, faster, etc. It's that you don't have the money for the NRE on an ASIC.
That is EXACTLY the reason to use an FPGA. I use them all the time for projects like that.
This is different from the software people who want a magically flexible brain for generic tasks.
The grandparent is responding to the article, which is talking about general purpose computation. There's no question that your application is a prime use case for an FPGA.