myRIO-1900, FPGA vs RT Module

[JitheshS]

hi, I have an myRIO-1900 and I saw that it had two things in it: the RT processor and the FPGA

I saw when creating a new project in LabVIEW, I can make either a "myRIO-1900 template" or "myRIO-1900 custom FPGA project"

I'm confused as to whether or not the labview is compiling the VI to be run on the FPGA or the RT processor?

When I made a myRIO-1900 custom FPGA template, I see the FPGA Main Default VI and the RT Main VI.

The FPGA Main Default VI I saw has code which configures the I/O pins of the board, and so I build this using the xilinx compilation tools and i'm guessing this is now written into the myRIO-1900 fpga side?

now if I want to process some of the signals coming in using the FPGA fabric (not the RT processor!), do I draw the code for this in the FPGA Main Default VI and build it again? or do I just use the RT Main VI which will do it for me?

My idea is to use the FPGA only to process signals and I don't want to use the SoC RT processor at all since FPGA fabric code would be faster

[Bob_Schor]

Did you notice that the myRIO has no keyboard, mouse, or monitor?  To communicate with "the outside world", all it has is a USB connection and WiFi, which enables it to connect to what?  To a (Windows) PC running LabVIEW.  What does this LabVIEW program "talk to" on the myRIO?  To a LabVIEW-RT routine running on the myRIO's processor, not on the FPGA sub-system.

As it happens, I'm proof-reading a fascinating Blog article by Ben Rayner, one of the Forum's Knights of NI, where he discusses the interactions between the three sub-systems involved in RIO programming -- the LabVIEW code running on the Host, the LabVIEW-RT code running on the RIO Processor, and the FPGA code, developed using LabVIEW but compiled and loaded onto the FPGA processor by the Xilinx compiler (so you don't need to worry about the complex, very-low-level programming of Gate Arrays to do every little step for you).  I've done several "two-processor" designs (namely LabVIEW/LabVIEW-RT code using a PXI box to run the Real-Time component), but have only dabbled in the three-system FPGA world.  The basic idea is that the User Interface and Data Storage are on the Windows PC with a (typically TCP/IP) connection to a processor running a Real-Time OS and handling the time-critical I/O, with perhaps the possibility that the RT-processor, itself, hands off some of the time-critical stuff to an FPGA circuit, all these things tied together by code developed using LabVIEW.

You can, indeed, do "almost everything" inside the FPGA, and there it would stay.  Of course, the code running on the myRIO needs to start and stop the FPGA, and maybe wants to get the data in and out into myRIO memory, but then what?  How do you (a human) interact with it?  You need the Host/RT-Target communication that LabVIEW (also) provides.  It's a little complicated, but LabVIEW is a common theme.

Bob Schor

[cbutcher]

If the code you want to write doesn't require features not available on FPGA, then you can keep adding it to the main FPGA VI or SubVIs called in that VI. These pieces of code will be compiled (slowly) into an FPGA bitfile, which I think might sometimes be referred to as a "personality" in the myRIO documentation.

For my work, I carry out high(ish) speed digital communications directly on FPGA, but then I communicate with the FPGA VI using the RT VI, which can be changed and modified much more quickly.

The RT VI handles some of the data processing, along with networking to the Windows computer which displays graphs, stores to disk, and so on. The RT system also implements some code which doesn't require high speeds and is easier to write with higher level tools, like VISA Serial, or in my case, DAQmx (available on newer cRIO systems).

When deciding where to put your code, determine how fast/responsive you need it to be, or if it requires features not available on FPGA. Depending on those considerations, you can choose which "target" to implement the code on. At least for my application, often either is possible but one is a "better" choice for some reason.