FPGA interactive mode in multiple develeloper environments

[cbl-jnj]

Multiple developers creating LabVIEW code for Windows, NI-RT and NI-FPGA, all code kept in SVN. Multiple working environments with numerous windows computers, NI Real-Time Hardware Targets and ethernet networks (ie, company (169.xxx.xxx.xxx), local (192.xxx.xxx.xxx) and hardware (10.xxx.xxx.xxx)). Experiencing that the FPGA Interactive mode does not work in numerous situations (ie, the FPGA code requires to be recompiled before using FPGA Interactive mode), with shared (again this is thru via SVN) LVprojects with the code and .lvbitx files.

Best I could find via google is this idea exchange posting that describes a perceived defect in this area (change in IP address of NI Real-Time Hardware Target - and am going to investigate if this is the root cause of the experienced issues):

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Enabling-use-Labview-FPGA-front-panel-in-interactive-m...

As asked in the above link, is this different IP issue a defect? Any insights or experiences to share regarding this described situation?

Thanks for your time - Chris

[cbl-jnj]

I've cross posted this to lavag forum as well, to increase exposure - Chris

[natasftw]

In order to work in interactive mode, you need to be connected to the FPGA running the code you have in your project.

If you're all working on the same cRIO, you'll have issues with connection.  You won't all have that connection built in and running.  If you make any changes, you'll need to deploy your code.  To deploy your code, you'll need to recompile it.  If someone else is running different code, you'll need the bitfile locally to do this.

Even with projects being shared, you're creating an application space, in memory, on your PC.  Try opening the projects and checking them back in to see little changes that take place.

This isn't meant to work.  It's a rather strange use case.  What makes you want to do this?

[cbl-jnj]

>In order to work in interactive mode, you need to be connected to the FPGA running the code you have in your project.

Yes, definately need the hardware for interactive mode. All configurations used have a windows machine with NI-RT hardware.

>This isn't meant to work.  It's a rather strange use case.  What makes you want to do this?

Not exactly sure what the use case is that you are refering to at this point, so let me describe our use with more detail. If that doesn't answer your questions, please ask a follow-up.

A developer, who is using a specific windows machine with a specific NI-RT target (with IP address x), compiles the FPGA code and then runs it in interactive mode. All files are then placed into SVN, including the .lvbitx file. Another windows machine checks out the SVN files, opens the LVproject, connects to a different NI-RT target (with IP address y). The ip address for the rt target is changed in the project. Interactive mode does not work after this simple ip address change, as the FPGA code starts to be recompiled before it starts to run.

At least two other reports of this issue are in the idea exchange thread, and the questions raised here and there have not been answered yet.

Thanks for your time - Chris

[natasftw]

Interesting.  It sounded like multiple developers, same cRIO.

Are all of the cRIO the same target type or are they different targets?  I'd imagine with just the IP changing they would have to remain the same target.  If you were to open the bitfile by linking to it through the RT VI, would it require a recompile?

[cbl-jnj]

>Are all of the cRIO the same target type or are they different targets?

Yes

>If you were to open the bitfile by linking to it through the RT VI, would it require a recompile?

That is a interesting question. In attempt to isolate the root of this observed behaviour, I have only added the FPGA VI to the lvproj. I will attempt what you suggest. But I have to admit that the configuration page "Configure Open FGPA VI Reference" that opens from Open FPGA VI Reference has soooooo many options, it seems like it may generate too many test vectors. But it may, provide more insight though. 

I have learned a few things, during this exercise as I debug this issue.

• another way to determine if a recompile will occur, is the use of Check Signature, available by right clicking on the FPGA compilation item in the build specification section. Much more convenient and consistent with the need to recopile the FPGA VI in order to enter interactive mode
• A simple FPGA VI, with minimal functionality, performs as expected. This suggests something in the FPGA code is the culprit, I'll wager SoftMotion, but will investigate. I've laid another bet, but it is a longshot.

Chris

[Jacobson-ni]

I would imagine that referencing the bit file would not make you recompile but then you will not be able to run the FPGA code interactively.  

You need to point to a VI to run interactively but I thought pointing to a VI in the Open FPGA VI Reference really just pointed to the bit file in the build spec.  Is this true?  If it is would you have to build to a common location?

[natasftw]

---

@cbl-amo wrote:

That is a interesting question. In attempt to isolate the root of this observed behaviour, I have only added the FPGA VI to the lvproj.

Chris

---

Am I understanding this correctly?  Are you adding a VI to the project prior to it asking you about compling?  If so, it's not a shock that it's wanting you to compile.  You'd want to build the project with the VI already included and then compile the FPGA code before sharing to other systems.  Then, the project is already compiled and can find the bitfile.

[thoult]

When your developers check out the code, is there a local copy? For instance, we have a central repo and local clones; I work on my local clone and push back to the main repo when finished.

If so, then the absolute path to the bitfile changes, and this is encoded in the bitfile filename. Editing the bitfile path is usually enough to let the project know it doesn't need recompiling.

See here.