Yes, sorry, I wrote that message faster than I could think.
I'm even more embarrassed about this mistake since I should have known better. I've actually designed both on-chip (i.e. using standard logic cells in an ASIC) sensors for fast (tens of ps) transients and also FPGA-based hardware testers that behind the front-end had a high-speed data analysis part.
While I know nothing about the choices or limitations that the designers of commercial devices faced during the development or validation of their systems, here are a few observations from my experience. Please note that in my field, the notion of waveform/second is not used, as the devices I mention doesn't present waveforms, they present a (data) snapshot whenever the event we are capturing occurs. They are more Logic Analysers-like, although the ASIC sensor reported analog waveforms.
I. You can receive incoming data at pretty high bit rates, that's for sure.
In one of the systems I worked on, there were like 6 x 32 (+4 parity bits) SRAM asynchronous memories, working at around 30 MHz. That makes around 5.76 Gb/sec of gap-less incoming data. In other one, we had a standard 64 bit DDR2 memory module and some glue logic in FPGA (FIFO-based) to allow gap-less/uniform access time function
II. You have to do something with that data, preferably (or I rather say absolutely) in realtime.
For many reasons, in our systems, the trigger was in hardware (on the FPGA or ASIC). That ensured a realtime treatment of the data and the start of the snapshot procedure whenever the trigger occurred. Except the snapshot data, everything else was discarded.
I would guess that doing all this in software could be possible, although taxing. Do you need a high-performance CPU just for this? Do you need a realtime OS to guaranty the timed execution of the tasks? We didn't used a software-based approach because of the fact that the estimations for the required CPU power were too big. Our devices are rather compact, fault tolerant, low power, able to work in vacuum and we use tens of them at a time.
If the realtime criteria is not meet, you will certainly accumulate too much data to store or analyze and you will be forced to discard some of this.
I would hazard to think that a software-based trigger is not feasible always in real-time because of the required computing power?
III. You need to present the measurements to the user at some point.
This is more an extension of the II. really. In my case, the measurements were stored in files on the controlling PC. Since the devices only sent a snapshot of the captured event, the only requirement is to have an event rate low enough to not overwork the PC.
Best regards,
Dan