Jump to content

LV RIO ... where exactly is the bitstream stored?


Recommended Posts

Hi,

me again ;) .

I am currently in big confusion about the way LV stores the FPGA configuration bitstream for a RIO device. As mentioned in other posts I have a setup where my project is transfered to a PXI controller where some SW framework loads it in a plugin approach. My project employs a R series FPGA board. I had some confusing experiences with this where the oscilloscope showed clearly different behavior than what the implementation should do. After some time I noticed it was seemingly and old bitstream used. I then introduced a revision number for my FPGA design that is set to a constant in the FPGA top-level VI and actually I saw that there was the wrong bitstream being loaded.

The way I do it is with the "Open FPGA VI Reference" VI that is configured to use a bitstream. The bitstream is actually copied to the build destination directory and is the latest according to the timestamp. But I doubt that really this bitstream is used because a) I once deleted it on the target system and my design would still boot happily boot without throwing an error when calling the Open FPGA VI Reference VI and b) my VI that calls the Open FPGA VI Reference VI is about 1 MByte big. Somehow I have the feeling that the FPGA VI is compiled into this VI although this is not stated anywhere.

So the question is what might I be doing wrong here or whether this is the way it is supposed to work. At the moment every time I did a new synthesis of the FPGA is explicitly open the "Open FPGA VI Reference" VI configuration dialog and point it to exactly the same bitfile and with this I have not seen a "wrong bitstream" problem but it is not nice to do so.

Best regards

flintstone

Link to comment

Hi !

I think now (LV2011 for sure) you can explicitly set the "Open FPGA Reference" VI to load a bitfile according to a build specification. Doing this may prevent loading an old bitfile...

Link to comment

How are you transferring the code to the PXI?

I think you are correct that the bitfile will be included with the VI (though I have to say I have not done this as a source distribution rather than an rtexe before. this means you may need to reopen the VI to link to the new bitfile rather than transferring the file separate with the VI. This is certainly the case wi rtexe but I may need to double check this with the source method.

The other option is you can burn the bitfile directly to the FPGA rather than depending on the Rt vi to download it.

Definitely in the VI:

Note  The Open FPGA VI Reference function extracts the bitstream from the compiled FPGA VI or bitfile and stores the bitstream when you save the host VI. The bitstream contains the programming instructions LabVIEW downloads to the FPGA target.

from http://zone.ni.com/reference/en-XX/help/371599C-01/lvfpgahost/open_fpga_vi_reference/

Link to comment

Oh, I have to apologise I did not find this although it is the first thing I should have checked ... shame on me.

But it brings up a second question: "When the Open FPGA VI Reference function first executes on the block diagram, it checks whether the compiled FPGA VI already exists on the FPGA target. If the compiled FPGA VI is not on the FPGA target, the Open FPGA VI Reference function downloads the compiled FPGA VI to the FPGA target. If you select Open and Run from the shortcut menu, the FPGA VI starts running if it is not already running."

This sounds to me as just downloading a bitfile would not help as the Open FPGA VI reference will overwrite it if it does not match the one compiled in. Maybe using the build specification approach is really the best.

Thank you!

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By OlivierL
      ShaunR's recent topic on Security reminded me of a situation we explored in the summer and need to revisit at some point. We were looking for a method to protect the communication with a cRIO.
       
      The situation is that we need to communicate between a cRIO and a host on an unsecured network (manufacturing environment.) We concluded that we needed some form of encryption as well as a standard login mechanism but identified that having a single symmetrical key would not provide enough protection (for various reasons and specific use cases.)
       
      Therefore, we looked into SSL and LabVIEW Web Services because it already includes that library and all the security features that we need. We figured out that it would definitely offer the protection required but that would mean rewriting most of existing code to use Web Service instead or establish some for of communication through a new Web Service. Considering the amount of unknown and risks associated with modifying our code, we looked into an alternative and came up with the following scheme:
       

       
      In short, we would use a Web Service for the initial login and create a new symmetrical key which would be passed to the host and to the main application on the target (cRIO) and would be used to encrypt/decrypt all data during the session. This way, we could still program all of our code in LabVIEW and easily download/deploy the services and applications to the Target using NI standard tools but benefit from proper security and only have to add fairly simple wrappers to some sections of our existing code.
       
      I wonder if anyone else has already gone down that route to add protection to an existing application. Would you suggest a different implementation method or an easier path to a similar result? Is there some obvious pitfalls in this approach that we do not see?
    • By Calorified
      Hi there,

       

      I have RIO in a Windows VirtualBox inside a Ubunbtu Host OS.

       

      I am sending data from a C++ program in the Ubuntu Host system to labview within the Guest OS.

      I can receive the data on labview installed on the windows guest os. Below is the png of the Windows working program.

       



       

      But when I tried to send the data to myRIO, I was getting a udp read only error 42.

       

      Somewhere on the NI forums, someone suggested the net address of the "UDP Multicast Read-Only" vi  be wired to the address of the RIO which I have done below

       



      .

       

      Now, the code runs on myRIO but I can't receive any data on RIO. The multicast address I am sending to from Boost Asio C++ is 235.255.0.1 on port 30001.

       

      The RIO has a public ip of 172.22.11.2 and I set up a static ip address for it in NI MAX as the address of the UDP Multicast : "235.255.0.1.

       

       

       

      At this moment, I do not see what I am missing. All firewalls have been disabled and I have set the permissions for RIO through the Windows security page.

       

      Any help would be appreciated.

      Thank you!

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.