For debugging, using FPGA VIs in interactive mode can be very valuable. I have, to this day, not been able to find out how LV determines if a bitfile and a VI match.
Therefore whenever I click on the run button for a VI, I'm never quite sure if the bitfile will match or not and often have to wait 1-5 minutes before I can resume working with LabVIEW. This is a very high price to pay for something which I end up cancelling. I would like very much if the IDE would TELL ME that the bitfile and VI don't match before starting a new compilation and thus wasting my time.
This is opposed to a CTRL_Click of the run arrow which explicitly tells the IDE to compile.
Currently when you build a VI the bit file path is stored as relative (you can see it in the project XML). This means if you change the project location either:
You have to recompile the FPGA to use VI mode or run interactively. It seems the bitfile could be stored as a relative path like all VIs in the projects.
Per NI Applications Engineering, "If you intend to run multiple compiles in parallel on the [Linux] server then yes, you will need the Compile Farm Toolkit running on a Windows machine to handle the parallel workers." I would like NI to support the FPGA Compile Farm Toolkit on Linux, so I don't need a dedicated Windows server to outsource compiles to workers.
Hi, since there an be a queue for compiling FPGA code, it seems natural to me to also be able to make a queue for generating intermediate files.
I'm working with 10 build specs. for compilation per project and generating intermediate files for my design takes aprox. 3-4 minutes. This means that I need to sit by my computer for half an hour just waiting and clicking build on every build specification. Sometimes I work with FPGA VI which need to build intermediate files for something like 7-10 minutes, so this is a pain.
It would be great if there was a way of just highlighting all build specifications for compilation with shift and just creating the intermediate files for them automatically one by one.
Can this be done?
Even though ibberger touched the concept in the idea , I do think that most o people uses LabVIEW under Windows environment. Compiling a FPGA VI happens all in the PC under Windows. I noticed that during this process the compiler uses only one core. Since I'm using a machine with a 4 core processor, the CPU use rarely goes above 25%.
My idea is to update the compiler allowing it to be multicore. The user should have the option to limit the maximum number of cores available to the compiler. This is necessary because the user may want to continue working, while the compiling process is being done in background.
As the compilation goes on of the LabVIEW FPGA code to bitfile, there is an intermediary step when a VHDL file (or maybe Verilog?) is generated. This file would be very beneficial if you want to use another FPGA target, that NI supports. I know that this VHDL file cannot be directly used for non supported FPGA, but it would be a very good starting point for the ones that know VHDL language.
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 ... 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 ...
Sometimes I just want to compile a lot of Bitfiles (Be it for a release or a debugging test case) and I have to right click each and every Build spec and choose "Build". then wait about 10 seconds and do the same again for the next build spec.
How about being able to select multiple build specs and then select "Build Selection" and have time to go for lunch while the PC queues up all the compilations?
I don't use a compile farm and everything is done locally but at least the queuing could be automated.
I have several FPGA projects that require significant compile time (up to 1.5 hours), and for that I am thankful to have my compile server running on a separate computer.
The issue comes with the seven Pre-Compile steps that occurs before LabVIEW sends to the code to the compiler. On one particular project this action alone can take up to 35 minutes during which time I can do nothing on that machine.
I would like to see much of this precompile time moved from the development environment to the compile server. There already exists a mechanism for updating the user with the compile status so those precompile errors could be annunciated in a similar fashion.
Get the development system back online as quickly as possible.
Wouldnt it be nice if, when you build an FPGA, rather than poping up a modal window, and preventing you from doing anything usefull for 10 mins or so (or more, dependant on the FPGA vi), LabVIEW went away and generated the intermediate files in the background?
After all, the actual compilation is now performed asyncronously (and you are using the cloud compile, arent you? ), so why should we sit and watch the intermediate files being generated?
Imagine the hours you would save a week, just by being able to get on and do something else.
If you try to compile while pointed to a Compile Server that is for any reason inaccessible (server is down, firewall, typo in the hostname, etc.) you must wait through the generation of intermediate files, then you receive the error message that LabVIEW FPGA was unable to contact the Compile Server at your configured hostname/IP. Generating intermediate files can be a lengthy process and it shouldn't be necessary to wait through it just to find out if you have configured your Compile Server correctly. Any of the following would be a much better experience:
Simple one that I have heard a number of people request. Why is there no auto-increment on the versions of an FPGA build specification versus any other versioned build specification in LabVIEW? This should be a simple addition to bring the FPGA module inline with other LabVIEW modules.
I know its not necessarily a LVFPGA issue, but its us LVFPGA users that use fixed point numbers most often. Why don't fixed point numbers always show coercion dots. If every unnecessary numerical digit wastes chip resources, then isn't it more important that we know about these coercions so that we can avoid them?
For the moment, there is only one clock assigned with the FPGA main VI. "The top level clock"
This clock is used by the code created on the main block diagram. (Outside SCTL)
Today, if you need an other clock ... you have to use SCTL's ... but using SCTL generates many problems, because not all instructions are allowed in SCTL's !
I think that XILINX can handle a kind of partition !
My need would be, for example, to have one partition running at 40MHz ... and an other at 80MHz ... without having necessary to use SCTL's.
This is only an idea ... i think that behind my idea something heavy must be done !
The Top would be, to be able to share data between the different partitions (using FIFO for example) ... but i think this is one more difficulty !
The partition mechanism could be created in Labview FPGA as follow ...
Thanks for reading.
With multiple hosts in one project remove the restriction of FPGA target names. If I have 2 cRIOs in one project and the FPGA in those cRIO's is the same then so should the FPGA target name.
Of course, FPGA target names must be unique if they are within the same host.
Improper use of Global Variables in a SCTL causes compiling error 61056.
Currently, this error does not alert the user until a considerable amount of time has been used during compiling.
Please include a check in LabVIEW for inproper use and alert user before compiling.
*Created for service request per customer recommendation.
If I kick off a compile behind my VPN I can't re-connect to the compile when I get back to the office (different IPs?). I know this isn't a typical use case, but when compiles times or queues are long I kind of have to work around the compiler's schedule (and occasionally work from home).
Presently, the Xilinx Compile Tools do not appear in the MAX technical report or NI License Manager. As a result, to determine the version, users must go to Add/Remove Programs in the control panel to determine which versions they have installed. It would be great for troubleshooting if the Xilinx Version could be implemented into the MAX technical report.
In addition, the Compile Worker states that the version of Xilinx used is 12.4, regardless of whether you are using 12.4 or 12.4 SP1. It would be useful for the compile worker to note which version it is using. Specifically, often the compilation chooses the compile tools based on what it was compiled with previously. When upgrading to 12.4 SP1, the user may think the compiler automatically uses the new compile tools and has no visual cue to verify the compile tools version used.
i would suggest some Improvements to the Timing Violations Window.
With kind regards