LabVIEW FPGA Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
manu.NET

Don't compile if not needed !

Status: New

Hello,

 

This morning, after a night of FPGA compilation, i moved my Labview project path into an other location.

(Without modification of relatives path inside the project directory)

 

And then ... when i tryed to launch my FPGA main VI ... Smiley Mad the compilation started again !!!

 

I would be nice that the  "change detection mechanism" which detect if a compilation is required or not, doesn't take care of absolute paths !

 

I think that the "change detection mechanism" of FPGA code should be modified in order to only take in account the FPGA code dependencies.

 

The dependencies should not include ...

 

 

  • Absolute path references
  • disable conditional items ... if not used in the FPGA code 
  • ...
  • All things not directly needed and called by the FPGA code
  • ...
Angry Manu.net.

 

 

Manu.net
8 Comments
SKauth
Member

Can't you use the bitfile of the last compile in this case? It should not include any path references on your development system.

 

But you're right, the "change detection mechanism" should be made smarter. I could safe much time if it wouldn't recompile just because I

- moved a wire

- changed the layout of the frontpanel

- added some labels

- ...?

 

Regards,

Simo

JonathanH
NI Employee (retired)

The bitfile name by default contains information about the absolute project path, so moving the project will result in a different bitfile name. If you're using LabVIEW FPGA 2010, you can open the Build Specification Properties page and change the Bitfile name to match the one that is already compiled. You can also right click on the Build Specification and choose 'Check Signature' to see if a compilation will be required if you hit the run button. Of course, this suggestion will only help with the absolute path issue you encountered. Your other points about code in conditional disable structures and so forth are still valid concerns.

 

As suggested by SKauth, you can configure your FPGA Interface Open node to point to the bitfile, but you won't be able to run the FPGA VI in interactive mode nor configure the FPGA Interface Open node for VI or Build Specification.

 

Hope this helps.

manu.NET
Active Participant
Hello, How can run the "debug" FPGA interface only with a bitfile ? Manu.net
Manu.net
JonathanH
NI Employee (retired)

I'm not sure what you mean by "run the 'debug' FPGA interface." There are generally 2 ways to interact with code running on an FPGA device from within LabVIEW. When you click the 'run' button on an FPGA VI, if it is already compiled, the front panel controls and indicators are updated by the NI-RIO driver which is communicating with the FPGA device. This is called interactive execution or running interactively. Using this method requires the VI and project signatures to be up-to-date with the bitfile, or else a new compilation will be initiated when the run button is clicked.

 

The second method is writing FPGA Interface VIs (sometimes called 'host interface') which run on the host computer and communicate through the RIO driver in a more programmatic fashion. The Open FPGA VI Reference node can be configured for an FPGA VI or for an existing bitfile. The reference from the Open node can be wired to an FPGA Interface Read/Write control to provide access to the values on the FPGA device. If the Open node is configured for a bitfile, the VI and project signatures do not need to match.

 

Does this answer your question?

manu.NET
Active Participant

 

Hello JonathanH,
In place of my 'debug' FPGA interface you must understand "interactive execution", of course !
My previous question
"Hello, How can run the "debug" FPGA interface only with a bitfile ?"
was in fact not a question but a way to say ...
How can i run in "interactive mode" a moved FPGA project without having to recompile the FPGA side ? Or without having to patch manually internal project files ?
I think that the actual signature of a FPGA bitfile should be modified in order to not take in account absolute paths ... and other unused features.
If not, a tool should be added to Labview FPGA in order to "Reactualize" the FPGA signature according to the project location ...
Perhaps the signature should only take the FPGA interface in account ... It's then to LabView FPGA user to recompile if needed !
Or a best idea should be : the signature should be divided into 2 parts :
-> A signature for the host interface
-> A signature for the FPGA inner code
If the "Host interface signature" has changed ... The recompilation is needed ! The hosts applications are no more compatible !
If only the "Inner FPGA code signature" has changed ... then the host applications are still compatible ...
But a warning should then ask if a compilation is required or not. (Up to the developer needs) 
Manu.net

 

Manu.net
MattWhitlock
Member

Don't know if it's been submitted as a bug, but I view this as a bug in LabVIEW FPGA, not a feature to be added.  This is an especially problematic issue for team-based development. Unless all developers use the same absolute path for their working copies, they end up fighting the FPGA compile issue.

 

Basically the .lvproj should not hard code the absolute path for FPGA Bitfiles.

 

Matt

Lars.B
Member

To mention as second annyoing thing I have learnt in the past when checking out my SVN-repository on another path than checked in...:

After some debugging/analyzis I found out that in the XML-file lvbitx used typedefs are linked as absolute paths - and LabVIEW cannot be persuaded to use an other, "coincidentally" equal named typedef, like the one in the project-file... Interestingly to note, editing the path in the XML doesn't fix the problem, HostVI is still broken and complains about an unknown typedef.

 

So... please change your method to hardcode an absolute path of typedefs used in the FPGA-VIs-interface in the FPGA-bitfile!

It is really really time-killing to be forced to recompile a bitfile only just because the project is put in another directory....! Especially happens gladly then when you're staying at customers site and wondering why the before-all-good-project now is broken... and for example, "F:" is not availabe at your laptop as workaround. 😉

 

 

PBP
Member
Member

I have also faced this problem but now What I do is I go to FPGA build specification properties and change bitfile name to previous complile name. This works if you have just moved your code from one location to another without changing in FPGA VI.

 

Second problem is host VI shows error. For this I right click to "Open FPGA VI Reference" VI and Configure Open FPGA VI Reference option and repoint to build specification.

 

Above steps always solve my problem incase of source code is transffered from on PC to other PC or change source code location (Provided no change in FPGA file).

PBP
Labview 6.1 - 2019