Triple buffered digitizer

[Karri Kaksonen]

After reading through the forum there does not seem to be a contribution to do exactly what I am looking for.

In our radar interfacing we need only 1024 samples at maximum available resolution and a nice UDP transport to get them out of Red Pitaya. The grace time between triggers is around 0.5ms. So the goal is around 2000 packets/second or 4Mbytes/sec.

The idea between triple buffering is:

A- input buffer
B- processing buffer
C- output buffer

So Red Pitaya should fill the buffers A, B, C in a round-robin fashion without any semaphores or locking mechanisms.
Then processing part should add a few environment bits to the buffer like heading and speed. Read through Ethernet in IEC 61162-450 protocol.
The output buffer would multicast the 2048+header bytes as an UDP packet.

All these three workers need to operate in parallell.

Would the best approach be to start by creating the triple buffer digitizer in the FPGA? Or would the current FPGA part be usable as it is?

As the amount of data is small then perhaps the fastest way to get this done would be to do the triple buffer system in C-code outside the FPGA and let the FPGA just do its job.

Any constructive comments?

Oh, and naturally copying the data is out of the question. So all operations need to operate on the original captured data vector.

Best regards,
Karri Kaksonen

[Nils Roos]

Hi,
I'm not sure if it's still relevant to you, but here are some comments on your endeavour:

• the scope FPGA block should be sufficient for your needs as it is
• splitting the processing between 3 workers as you suggest seems reasonable, where one worker waits for trigger and fetches samples into the current input buffer while the other two do processing and transmission on the remaining buffers
• it's not easy to do away with copying of data inside the network stack, but considering your moderate average throughput requirements, it shouldn't be a problem
• if the only processing to be done is adding direction information and timestamps to each batch of samples, a double buffering scheme where the info is added by the data-fetcher would probably be sufficient; this worker would idle anyway while waiting for the next trigger

Cheers
Nils

[Karri Kaksonen]

Thanks. The project is still mostly relevant.

There is one minor inconvenience that still bothers me in RedPitaya. The input bits work ok but it would be very nice to get an interrupt triggered on a certain bit. In radars you often have a bearing wheel that emits 360 pulses per rotation. Polling it feels kind of stupid.

[Nils Roos]

The current Red Pitaya FPGA design does not support interrupt generation.
The ZYNQ platform provides up to 16 interrupt signals from PL to PS, and one of the additions I am experimenting with at the moment enables those interrupts and ties them to sources within the different building blocks. When I reach a point where it's usable, I will let you know.

[Karri Kaksonen]

Thank you. An interrupt would be appreciated.

[jmadsenee]

Hi Nils,

Have you made any progress with the interrupts?

Thanks and regards,

John

[Nils Roos]

Well, I made some progress. I have routed 16 IRQ lines from the FPGA fabric to the ARMs, and adapted my driver to register appropriate interrupt handlers.
Then I generated some interrupts from the FPGA and lo-and-behold, the handlers were called and did the stuff I put in there without panicking the kernel.

So I do have a framework ready to use interrupts, I just have no idea what to actually do with them. Suggestions ?

[jmadsenee]

What to do with interrupts... Well, I'm a big fan of interrupts, really. I don't like to have to sit there and poll an input. You can go and do other things, then just deal with an event when it happens. An interrupt speeds the response and gets rid of the overhead of polling.

If the FPGA interrupted when it finishes and acquisition, I wouldn't need to do nothing while waiting: while (osc_fpga_triggered() == 0);. This may be less relevant when doing a short acquisition at 125MHz, but not at a lower sample rate, or in my case where I want to signal average. True you could just poll it every now and then, but that's a pain in the butt, and polling doesn't give you the fasted response.

Interrupts would be really nice on the Extension Connector. I am going to have a dsPIC processor on my extension board and an interrupt would be a superior way to notify the RP that it wants to communicate. A port like the PCA9537 could use it's interrupt output to notify the RP that in input changed state.

Less overhead, more speed. Isn't that what life is all about??

[Nils Roos]

Less overhead, more speed. Isn't that what life is all about??

A bit off-topic, I'd submit "procreation" for inclusion in the list ;O)

Back to the topic of interrupts, interrupt processing is restricted to kernel space in linux. You can do things with kernel owned memory, but you can not call back into user-land nor use resources from user-land.

The only way to use interrupts from an application is to call a system function that blocks and only returns when an interrupt occurs, like eg. select() does. As far as I know.

If that fits your needs, I can probably set you up with something.

[plauria]

Hi Nils,

I'd also be really interested in trigger code. What I plan to do is, on receipt of trigger, start stepping the PID setpoint. I've done this already in C, it's pretty easy, but I'd need a repeatablly timed way to trigger the start of the stepping. So some sort of blocking wait_for_trigger (DIO_PIN) would be perfect. If you have some interrupt code that's somewhat ready please share! Thanks.