Simultaneous access to FPGA

[xl600]

I have an FPGA design which I would like to do the following (Simultaneously):

Realtime host VI (PXIe-8135)

• Access a DMA memory (Read) for high speed storage to disk
• Read various indicators
• Write to various controls

Host PC VI (Laptop)

• Access a different DMA memory (Read) for displaying images to the test operator
• Read various indicators (Many the same as the realtime VI)
• Write to various controls (None the same as the realtime VI)

Can this be done safely?  I've been very careful to ensure each control would only be written to by a single host VI (Realtime or a laptop VI).

How would I configure FPGA VI references so that no conflicts exist?  I know the laptop's reference will be different from the Realtime reference so how does LabView keep the FPGA straight in the PXI controller?

Thanks,

xl600

[nathand]

I have no idea what error you'll get, but I'm pretty sure you'll get one. The Real-Time application should be the only application talking to the FPGA, and it should provide some type of communication interface (network streams, TCP, shared variables, VI Server) so that the Windows application can connect to it.

[Michael_Strain]

What you are doing sounds OK based on the limitations you imposed on the access from the Host PC VI (such as using a different FIFO and not writing to the same controls).  It is a slightly unusual architecture as you would normally be communicating with the RT app, but it is supported.

As long as both VIs are running the same bitfile and not using any of the same FIFOs or writing to any of the same registers, there shouldn't be any conflicts.

[xl600]

Ok, the other poster thought this would cause an error so I'm not sure what to believe.

The architecture is fairly complex.  If I can access from two places at the same time, then it simplifies things considerably.  The FPGA has about 100 inputs and 2 DMA FIFOs transferring image data back to the RT app or laptop.

One of the FIFOs is for high speed image data that has to be recorded by the RT app.

The other FIFO is for transferring camera frames at a very slow speed (1Hz) for the purpose of presentation to the test operator and to perform slow speed image processing (Via the laptop) while the RT app performs the high speed recording function.

I was hoping to avoid having to have the RT app buffer and transfer the large slow speed frames for fear that might impact the high speed data recording functionality.

I'm still in the middle of deciding on how to handle all of this so creating RT wrappers and passing shared variables around is still possible.

[nathand]

If Michael_Strain says it works, he's more likely right than me, as he works for NI (and I don't). I've used LabVIEW FPGA quite a bit but have never tried the setup you're describing. My apologies for the misinformation. You could set up a test of this pretty quickly with a simplified VI, and see how it works.

That said, if you prioritize the RT loops appropriately, you should be able to handle the slower-speed data without affecting the high-speed performance. Also, simply writing data to disk at high speed should not require a lot of processing power. Write the data in as large blocks as possible.

[KHartley]

Michael is correct you can open multiple references to the same fpga using the same bitfile in parallel. You'll have to have dynamic FPGA configured for each reference. 

You are giving away quite bit  by not explicitly having rt handle the data. Don't be fooled by the convenience, RT still has to reach down and pass the data to the network stack. The RIO driver just makes it really painless to do. Also for an RT system you are giving away any hope of priority control. We may assign the default priority so it may not conflict with your app but you aren't explicitly setting it so you need to validate you don't have issues with priority inversion. 

[Michael_Strain]

I think the tradeoff here you should consider is how much control you have over the application.  When you open a remote session to an FPGA all the same buffering and transfering still occurs on the RT Target, but it occurs behind the scenes.

If you need good performance in your RT App, you might consider controlling the slow speed transfers in your RT APP so that you can prioritize them approprately and control when bus accesses occur.

[xl600]

Thanks for the clarifications.  There's not much by way of documentation on the newer capabilities of LV FPGA in this regard or the details on how RIO deals with RT communications vs network.

I think the notion of setting my own priority for the slow speed transfers is probably the winning argument for encapsulating the FPGA interactions within the RT app space.  A delay here and there in the transfer to the laptop isn't going to affect much in the near term.

I have done quite a few performance tests on bulk data writing and found that straight binary chunking of large data blocks is indeed the optimim way.  My FPGAs transfer image data as a binary stream so that works out well.

Thanks,

XL