LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Richard_Jennings_Younicos

Shared memory between RT and FPGA

Status: New

I would like a shared memory region accessible from both RT and FPGA. LV FGPA has memory regions accessible from anywhere in the FPGA, however you need to use DMA or front panel controls to exchange the data with RT. I envision a much larger memory region within RT's memory space where RT and FPGA could peek and poke values. The user interface would be like the current FPGA implementation with a matching interface on RT.

9 Comments
Dragis
Active Participant

Do you mind sharing some specific examples of what type of data you want to share between the FPGA and RT systems? There are a lot of issues with sharing memory between two very different (heterogenous) platforms that make it hard, for instance, to guarantee coherency with the data on the two systems. Most requests in the past for shared memory have ended up requiring something like DMA to handle the disparity in the way the two systems process data. Having some concrete examples will make it easier to understand the requirements for the feature.

Richard_Jennings_Younicos
Member

A 1D array of Integers  I can take care of manipulating scaling etc... This is similar to the way I use Modbus. Reads and writes are U16 to predefined registers. 

 

My FPGA VI writes to memory locations as a holding register but I have to jump through some hoops to get the data back and forth from RT. 

StephenB
Active Participant

I've wanted this for a long time. Glad to see others with the same idea.

 

this is great for an IO scanning architecture. The fpga reads writes all IO to a data table and RT just interfaces with that data table. The transfer is now implicit.

 

arbitration could be handled by the user any way they see fit. Its up to them to make sure they don't simultaneously access. Even better for this would be a second idea... Proper time between FPGA and RT so you could just set up a "real" timed loop in FPGA and RT with the same rates and an offset set on one of them.

Stephen B
SteenSchmidt
Trusted Enthusiast

Kudos, but this really belongs in the Real-Time or FPGA idea forums.

 

/Steen

CLA, CTA, CLED & LabVIEW Champion
tom_ifms
Member

I agree that there should be a hardware-closer way of directily accessing common memory (DMA). The DMA FIFO implementation is good for data aquisition task but not for controller tasks where latency matters (see http://forums.ni.com/t5/LabVIEW/Zynq-7000-performance/m-p/2517454/highlight/true#M765455).

AristosQueue (NI)
NI Employee (retired)

Suppose there are situations where using the shared memory is approrpriate... would this shared memory be inappropriate for other situations? I.e. would we end up supporting both DMA and this new shared memory? If so, how would LV guide a user into picking the right one to use? Maybe this is more a case of needing to unify the diagram API used to access the FPGA memory and the DMA so that it is the same essential node with different configurations ("local to FPGA" vs "shared with RT") or something like that?

Richard_Jennings_Younicos
Member

DMA FIFOs are great for streaming data between FPGA and RT, but they are not that great if you only need to read or write specific registers in the FPGA's local memory. Presently we can set up a memory region on the FPGA as "Block Memory" or "Look-up Table". Having the extra option "Shared with host" would be great.

AristosQueue (NI)
NI Employee (retired)

This sounds very similar to the distinction between using a global VI vs using a queue on the deskop (similar in that one is a raw variable [albeit with some syncronizing magic between the two different hardware systems] and the other is a lossless stream of data). One of the aspects of LabVIEW that people don't like is that they may find one before the other and then try to use the one for everything OR they use one and then are very frustrated rewriting the system for the other. The network shared variables are the subject of many rants, but one thing they get compliments for is unifying the experience of working with an ubuffered value vs working with a buffered value just by reconfiguring.

 

I am someone who knows very little about the relationship between FPGA and RT -- I have done a lot of work in the compiler within FPGA or in the execution system of RT, but almost nothing at their interop boundary. I'm about on par with a new user. I've written exactly one application that had to use both RT and FPGA. For that one application, I didn't really know what I was doing insofar as sending data between the FPGA and the RT, in either direction -- I  followed some instructions and those instructions worked out great. So...

 

Under this new proposal, I know I need to get data from my FPGA to RT. What principle should I use to decide whether to use shared memory vs DMA? Is there any mechanism you can think of whereby LV could simply decide for me which one to use so that I don't have to know the distinction? Is there some way that LabVIEW could notice at runtime "hey, the things you're doing with this memory are inappropriate"? Is there an easy way to convert a program written with one into a program written with the other?

 

All of that might play in to how such a shared memory feature might be exposed. Contrariwise, if introducing this shared memory makes it harder to program in FPGA because now there's one more thing to get wrong, it might be a feature we would choose not to do, depending upon how it weighs against the programs it would enable users to write. LV tries to strike a near-balance between "all the power of the universe" and "enough tools to get the job done without getting lost".

Dragis
Active Participant

@Richard_JenningsXP: You brought up some fairly common use cases, and I do agree that there is a need to have a simple way to read and write to shared control registers. A possible solution that would meld well with standard host code would be a way to retrieve a data value reference to a single register on the FPGA that is accessible on RT. We can then extend that to allow you to reference individual elements of a memory on the FPGA, etc. but that gets more complicated since you probably don't want to lock the entire array from being written but rather just single elements.