Continuous high-speed acquisition and analysis

[Program]

Hi everyone, I need to acquire and analyse data with the Red Pitaya in as close to real-time as possible (sampling rate needs to be 125 MHz). I want the FPGA buffer of one channel to be filled continuously with samples at 125 MHz in the background and at certain intervals I want to read out a fixed number of samples for further processing. I would like to accomplish this with a C program, but I guess the speed with which samples can be read from the buffer limits my rate. What is the quickest way to access the buffers of the FPGA and how long does reading one sample from a certain position within the buffer take?

[jerzydziewierz]

have you had a chance to look at the examples from the repository? i guess you can re-purpose one of the examples to do the signal processing on board.

data download with SCPI it takes around 600ms per buffer (16k samples) - if you can do it any faster by skipping SCPI, let us know!

(in fact, if I knew it takes that long, I would use my money on a real oscilloscope instead!)

By the way, I have managed to compile the current 'standard' fpga code and it takes approx. 45% of the FPGA resources, with both multipliers and ram-blocks still available. So if you throw out e.g. the PID controller, on-board FIR equalizer e.t.c., there is still a lot of place to *develop your own instrument* there.
see the compilation report at
https://gist.github.com/anonymous/e3501 ... -txt-L2626

for that matter, the ADC buffer takes only 7 ram blocks out of available 60! (7 per ADC channel, so that's 14; then 14 for DAC and 1 for a message fifo - see line 2626 of the report)

So theoretically, we could extend the on-chip full-speed acquisition buffer to nearly ~280k points by simply re-arranging the ramblocks on the FPGA... in such case, that would give it way more time for the CPU to handle the incoming data....

[Program]

Thank you for your reply. I've had a look at the acquire example programs and the files enabling acquisition in the oscilloscope app. As far as I can tell, however, they are not doing continuous acquisition, but rather acquire samples, then stop, then read data from buffer, then start again. Also, I'm not really interested in storing a very large number of samples (as in this program,) instead I want to process the sample values as soon as they are written into the buffer (or at least as fast as access to this buffer allows). I've not got any experience with FPGA programming, so would like to do this in C, although I am aware that an FPGA implementation would probably be better suited for this purpose.

[Nils Roos]

Hi,

you are right about the way the oscilloscope and acquire applications and the RP api read data. On the other hand, the AXI ADC example and the rp_remote_acuire you linked to can do what you want with some modification. Both can store sample data at the highest sample rate into main memory, where you can access them like any other RAM-based data (eg. by dereferencing a pointer in C). Strip out the network routiines and replace them with your own processing.
The AXI ADC code has the lowest latency from ADC to RAM, the internal FIFO transfers samples to RAM every 64 acquisitions. Also, it can be run with the official RP image.

So theoretically, we could extend the on-chip full-speed acquisition buffer to nearly ~280k points by simply re-arranging the ramblocks on the FPGA

The product table for ZYNQs lists the BRAM capacity as 2.1Mb, which would be enough for <160k samples of 14bit. But the problem is that there is no fast way to get them out of the BRAM. For capacity, speed and ease of access you can't beat the AXI ADC solution.

[jerzydziewierz]

Hi Nils,
just a note,

That a core feature distinguishing very-high-end oscilloscopes from the intermediate ones (not even basic ones) is existence of a deep sample memory, which can be inspected post-capture

So if we could advertise that RP can reliably record 128M samples into it's internal RAM - and at an incredible 14 bit resolution(!!!) and unlimited channels @ 100eur per channel(!!!) I am sure it would get us a lot of recognition

I was really sad when I heard it's just 16k samples, that's why i was thinking about re-arranging BRAM myself,

I have been trying to read up the forum on rp_remote_acquire and historically it had some issues - but,

If you feel that ADC-to-RAM is now reliable enough, it really should become a front page prime selling point, even if we can't get them into the host PC at the full sample rate.

[Program]

Thank you for your answers, I'll have a closer look at the ADC to RAM feature of the axi_adc program and see whether I can modify this for my needs. I've also got a slightly unrelated question: The trigger source is set in the FPGA via the 0x40100004 register, but how often does the FPGA check the value of this register? If I set the source to RP_TRIG_SRC_NOW in my C program and thus trigger manually, for example, it will take time until the register is actually set to the corresponding value 1 (not sure how long this will actually be) and then the trigger event is only recognised in the FPGA once the register value is checked, right? How long will this whole process be? This causes a delay between the time when I set the trigger event in my C program and the time when the trigger event actually happens in the FPGA. I guess a similar delay would be introduced if an external trigger was used, although this might be shorter since this would all be done in the FPGA.

[jerzydziewierz]

hi,

Possibly I am wrong, but as far as I understand, the registers in FPGA are literally wired to control ports of the the gates/multiplexers, so there isn't such thing as 'waiting for it to be checked'; Instead, electric propagation time (speed of light in copper) applies (picoseconds). For a -1 speed grade of the FPGA that we have here, it's approx. (1 over 450MHz) of seconds.

As to the time it takes for a C program to change the value of a register inside FPGA, i'd expect it to be no longer than 4-6 cycles of the CPU-to-FPGA bus frequency (667MHz?) after the instruction is issued to the CPU core.

so, not instant but quite fast.

Obviously, nothing is ever instant in a relativistic world, but I would be impressed if you were able to measure the total delay.

Please correct me if I am wrong.

[Program]

Okay, so as soon as the register is set to RP_TRIG_SRC_NOW by the CPU, acquisition starts almost instantly. What I was also wondering is how the triggering via one of the fast input channels worked: Is the threshold value for acquisition based on the analog input or the input after conversion through the ADC? In the former case acquisition would be triggered almost instantly, I guess, as soon as the analog signal rose above the threshold, while in the latter case triggering would only be possible at a frequency of 125 MHz (so every 8 nanoseconds). This would mean that in the latter case there might actually be a delay (although a very short one) between the point where the analog signal rises above the threshold and the point where the signal is digitised and the trigger happens. Is there any information available about this? Also, I assume triggering by and acquiring on the same channel is possible?

[Nils Roos]

Setting FPGA registers takes some CPU clock cycles (@667MHz) to be routed to the central interconnect, some central interconnect clock cycles (@222MHz) to be routed to M AXI GP0 interface and then some AXI GP0 clock cycles (@125MHz) to be written into the FPGA registers. At some points, current traffic conditions come into play, so the latency is not fixed. I'd say "some cycles" is usually a small one digit number at every step.

Once the trigger source register in the FPGA is updated, it takes effect at the next sampling clock cycle.

The trigger conditions are calculated from the sampled data stream after the digital filter and - if enabled - decimation stages, both of which add some fixed number of adc clock cycles of latency themselves.

In conclusion, the time delay between the analog signal crossing the trigger threshold and the internal recognition of that condition is fixed at some value around 100ns for 125MHz sampling (factoring in the ADC conversion delay of about 50ns). Triggering manually has some small uncertainty in the delay, but you don't know the exact time at which the code is executing anyway, thanks to instruction caches, reordering and other advanced compiler and processor features.

Recording the same channel as you trigger on is of course possible.

[Program]

Thanks a lot, this is exactly what I wanted to know.