FPGA programming for high duty cycles

[diracdeltafunct]

I am trying to develop the Red Pitaya board for an application we are building but am hitting a few snags. My goal is to produce a digitizer board that can record ~130microseconds of data and average [or accumulate] it in near real time.

For example:
I have a weak 130microsecond signal at 50MHz that repeats every 140us [a 10us delay from end to start]. I want to record each signal, without skipping any, and average[accumulate] that data on the FPGA. I want this to accumulate up to the bit limit of the FPGA (~260,000 acquisitions). This average is to be used as a noise reduction technique to measure very weak molecular signals so every point from every trace is needed to reproduce the 50MHz signal. Note: I can likely live with a shorter length of signal (say 20-50 microseconds) but they delay between signals still must remain very very short.

My issue comes in the implementation. I have tried modifying the C controller code to average in memory instead of writing the data to disk [which is actually RAM on the red pitaya]. This offered no speed improvement and each acquisition took, on average, about 6ms to acquire ~130us of data. This duty cycle of ~1-2% would mean our end goal of 1M averages would take 1.7hrs instead of <3 min for near real time streaming.

Other digitizers, such as the Keysight (formerly Agilent) U1084 [http://www.keysight.com/en/pd-1680831-p ... =US&lc=eng] have implimented streaming the ADC values to an onboard FPGA for very fast storage. They boast nearly 100% duty cycles (2us rearm time between acquisitions) by doing this. While the Keysight device above is great, we don't need the high sample rate that they provide (which likely eats up a large portion of their cost).

I have looked into reprogramming the onboard FPGA on the Red Pitaya to see if it can reach similar levels but I have hit a wall. I know the basics of how FPGA programming works [connecting IP blocks to build digital logic circuits], but when opening the Red Pitaya code provided on github in Vivado I am entirely lost as where to proceed.

My question is whether any one has recommendations on good resources for understanding how to implement this myself, or where to find consultants familiar with the platform that are willing to assist?

[KrEn]

Hi!
Boosting the ACQ rate - not a simple and straightforward task.
Should one consider it a project or a job offer?
KE

[hmaarrfk]

From my understanding the acquired data is never actually saved directly to RAM.

I guess that was a harder job than the RP team initially thought since the RAM could be in use by the ARM processor. Therefore the data buffer is quite small, I think 2^14.

Regardless, you should look at rp_scope or some file to that effect. There they save the data to a 2^14 buffer. That should be a good place to start.

[diracdeltafunct]

From my understanding the acquired data is never actually saved directly to RAM.

I guess that was a harder job than the RP team initially thought since the RAM could be in use by the ARM processor. Therefore the data buffer is quite small, I think 2^14.

Regardless, you should look at rp_scope or some file to that effect. There they save the data to a 2^14 buffer. That should be a good place to start.

(note: I only need the below to work for 1 adc channel, not both)

The way I see it here: http://wiki.redpitaya.com/index.php?tit ... oper_Guide, I would think the 2**14 buffer would reside in the first stage of the FPGA and the ADC/DAC. Once the buffer is filled to the preset value, the values would then be transferred to the C controller running on the embedded ARM processor, meaning that those accumulated values would now be in system RAM. There is clearly a speed bottleneck here. I thinkthe slow step is the data communication between the embedded ARM processor and the FPGA logic circuits. However, I am not sure if the bottleneck is in the setup and rearming of the buffers, or if it is in the actual transfer of the data buffer to the RAM.

The 2**14 point limitation isn't a problem if we can up the repetition rate, since we only need <130 microseconds of data. The way this is done in other systems is by accumulating the incoming values on the FPGA itself. These other systems are often using the spartan or vertex FPGA's and have a lot more logic circuits to work with. Honestly, I am not confident that I know how to translate the published specifications regarding logic circuits, DSP blocks, Block RAM and etc into bit counts and numerical storage capacity.

Also, I wanted to provide some additional detail on my application, please see below.

Lets say you have a signal that has values such as [16384, 16384, .....(fill to 2**14 points)]. We will call this the "horizontal" dimension. These are the values directly from the ADC into the FPGA buffer as the normal “acquire” command would retrieve.

If you did one single acquisition the end result you would see printed on screen would be [16384, 16384, .....(fill to 2**14 points)].

Instead I would like to take advantage of a vertical dimension (this is the “accumulation”). Everytime the ADC acquires a new signal [for my use case on an external trigger event], it will add it to the previous acquisition for up to 2**18 times (a 32 bit int when using a 14bit ADC value) while still on the FPGA, and then print that accumulated value back to the C controller.

They output you would likely see then would be [4294967296, 4294967296, ...(fill to 2**14 points)].

This retains still limits the total number of points that need to be stored to 2**14 (and thus the amount of data that has to be moved through the ARM processor) but requires that the FPGA be able to store up to a 32 bit number.

As a side note http://www.xilinx.com/appnotes/dspx5dev.htm here is an example from xilinx on how to integrate the onboard DSP processing into add and multiply operations.

[diracdeltafunct]

Hi!
Boosting the ACQ rate - not a simple and straightforward task.
Should one consider it a project or a job offer?
KE

Hello KrEn

Yes, we are interested in pursuing Red Pitaya as a solution to this application and are willing to invest in this project, provided it is indeed possible. Please contact me directly if you would like to make a proposal.

[hmaarrfk]

Instead I would like to take advantage of a vertical dimension (this is the “accumulation”). Everytime the ADC acquires a new signal [for my use case on an external trigger event], it will add it to the previous acquisition for up to 2**18 times (a 32 bit int when using a 14bit ADC value) while still on the FPGA, and then print that accumulated value back to the C controller.

What you are describing is what is called "averaging" on a regular oscilloscope.

To my knowledge, the RedPitaya does not have this feature.

You mentioned you might be interested on paying somebody to do this. This might be one way to go.
On other way to do this, would be to work at a lower sampling rate and therefore the observation time PER trigger event is larger.

[diracdeltafunct]

What you are describing is what is called "averaging" on a regular oscilloscope.

To my knowledge, the RedPitaya does not have this feature.

You mentioned you might be interested on paying somebody to do this. This might be one way to go.
On other way to do this, would be to work at a lower sampling rate and therefore the observation time PER trigger event is larger.

Correct. We just did not mind having to divide the accumulated values later in a controller program to recover a true average and figured keeping the accumulated values as integers would be easier.

Unfortunately we often require a reasonable bandwidth to dodge some potential conflicts when detecting weak signals. Even at that point, down sampling by a factor of 5 (the most we could possibly tolerate) would still leave us with a 5% duty cycle at best. Since we intend to signal average for 10000 to 1M individual acquisitions the time required would still be prohibitive.

Would you have any recommendations for people, or locations to find people, who might be able to take on this project?

[amalagon]

Hi diracdeltafunct,

I am trying to modify the spectrum application in order to be able to average fft traces on the redpitaya, and in looking for posts on averaging I came across yours. I'm not quite sure where to start with modifying the fpga code or any of the controller code in order to be able to have averaging (or addition) - from the discussion it seems like quite a thorny topic, but I figured I'd ask, do you have any suggestions on what I might try?

Thanks,

amalagon