Options to transfer data from host processor to FPGA

[StMartin81]

Hello,

I'm a LabVIEW beginner and I try to understand the options on how to transfer data from the host processor to a FPGA target. I'm working on an exisiting project which I try to understand and which I want to optimize. The project uses a control structure which is an array with elements which consist of cluster data types. For simplicity assume that each element of this cluster is a UInt32 type variable.

In Limiting the Number of Top-Level Front Panel Objects in FPGA VIs (FPGA Module) it is recommended to limit the number of front pannel objects (especially the array type ones) because they use a lot of FPGA ressources.

I was considering the following options to transfer the data to the FPGA:

• Use a front pannel object but don't transfer the complete array but send each element individually using handshaking signals
• Use User-Defined I/O variables and and send each cluster element indivudially. I'm not sure if there is any benefit comparing it with transfering each array element indivudually through a front pannel object
• Use a DMA-FIFO and send the array as a stream. My idea was to serialize the array as a UInt32 stream and then to reconstruct the cluster on the FPGA side. But I have no idea if/how this is feasible.

Is there another option which I haven't found and what would be the best method to transfer the data in my case?

Regards

Martin

[LocalDSP]

The recommendation to restrict the number of FP objects only applies if you are having space problems in your FPGA. There is nothing wrong passing a cluster of U32 directly through the FP unless of course your cluster is gigantic. So your different methods are all worth considering. How many control elements do you have?

One good thing about the cluster approach is that it automatically synchronizes all your values so they are latched in your code during the same clock cycle. This can be important especially in control applications since you don't want to mix control parameters from different situations. If you use FIFO to transfer your values you'll have to build a copy of your entire cluster before using the new values and that requires FPGA resources too. And btw. where do you plan to store the values if not available on a FP cluster? In a global variable? In Memory (BRAM)?

Alain

[StMartin81]

I have attached an example project on what I currently have.

What I don't like about the current implementation is that I use the falling edge of a switch in my FPGA front pannel to latch my input data. The realtime system has to write the cluster first and then it write a true and then a false value to the switch, so that I can detect the falling edge. I think in terms of speed a DMA-FIFO would be much better but in terms on simplicity of implementation my solution is easier.

My question is if there is a better way on how I can implement the data transfer?

[nathand]

---

StMartin81 wrote:

The realtime system has to write the cluster first and then it write a true and then a false value to the switch, so that I can detect the falling edge.

---

I can't open your project (still using LabVIEW 2015 here) but a quick comment about this. A better approach is for your real-time system to write the true value, and then have the FPGA set that value back to false (using a local variable) after it reads the associated cluster. This simplifies the logic and allows the FPGA to signal back to the real-time system that it has read the value.

[LocalDSP]

A couple of comments and suggestions.

I agree with you that a Host-Target - DMA FIFO would be the most efficient approach in your case. Instead of packing your cluster data in a U32 array You may get away using two independent FIFOs each configured for U64 so you can latch 128 bit per call (Can you reduce your Ticks value to U16?). This could simplify your unpacking process (but require sync'ing between the two FIFOs).

Out of curiosity, I can see your main FPGA VI calls a subVI once with input parameters and then that subVI runs indefinitely since it has timed loops inside. That approach would not work in Win-LabVIEW since the input cluster would not be updated inside the subVI. Does it really work in FPGA? But I would recommend to move the timed loops to the top level VI, if not for functionality then for clarity. You should be able to run all you transfer code inside the same loop.

[StMartin81]

---

---

@nathand wrote:

---

A better approach is for your real-time system to write the true value, and then have the FPGA set that value back to false (using a local variable) after it reads the associated cluster. This simplifies the logic and allows the FPGA to signal back to the real-time system that it has read the value.

---

 Thanks! This is solution is definately better than the solution I was using.

LocalDSP wrote:

Out of curiosity, I can see your main FPGA VI calls a subVI once with input parameters and then that subVI runs indefinitely since it has timed loops inside. That approach would not work in Win-LabVIEW since the input cluster would not be updated inside the subVI. Does it really work in FPGA? But I would recommend to move the timed loops to the top level VI, if not for functionality then for clarity. You should be able to run all you transfer code inside the same loop.

---

No, it didn't work. 😉 But what works, at least in the new attached example, is when I draw a while loop around my FPGA code. 🙂

[StMartin81]

There was an error in the previous example and it didn't work.

The only way to pass a value through different simultaneously running VIs I have found (https://forums.ni.com/t5/LabVIEW/Using-Sub-VI-in-FPGA-possible/m-p/3226792#M937916) is to use variables.

But when I want to use several instances of the SubVI they would also access the same global variable. Is there another option than using global variables to get data out of running loops or is it possible to set a parameter so that the SubVIs use different global variables?

[LocalDSP]

Any reasons why you can't run all your code inside the same top-level loop and pass your variables to/from subVIs through controls/indicators? All the subVIs would then read and write variables for each main loop iteration (unless they a placed inside case structures).

You could then get rid of all globals and have full control over your timing.

[StMartin81]

---

@LocalDSP wrote:

Any reasons why you can't run all your code inside the same top-level loop and pass your variables to/from subVIs through controls/indicators?

I have a SubVI which uses a while loop and a timed loop. But I think I can restructure the code so that I can split the SubVI so that one part runs in a single cycle loop and the other part runs in a normal while loop.

Another thing is that I use the while loop to initialize my signals inside the SubVI? Is there a recommended way to initialize signals in a SubVI which are no controls?

[LocalDSP]

It is still very confusing to have parts of the code running in different loops at the top level and parts running sub-VIs with embedded loop. I think you should rework everything to run in a single top-level loop. A couple of coding techniques you may not be aware of.

- You can achieve the same functionality as a subVI with a timed loop by removing the loop in the sub-VI (but keep the code) and place that modified sub-VI inside a top level loop (same type of loop)

- If you have code that needs (or you want) to run inside a single cycle loop (SCTL) but has no specific timing requirements, you can place that code inside an SCTL that only run once (stop for i=0) and then place that SCTL inside a main while loop.

Regarding initialization. If it is an init operation that only happens once when the FPGA is started, you can create a frame structure and call the Init in the first frame and your main loop in the second frame.

If I miss the point, can you please explain why you need so many different loops and why they have to be distributed around the way you do?