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.
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.
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 ...
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:
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.
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.
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.
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.
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?
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).
When LabVIEW 2009 and prior, after the compilation of FPGA VI, the bitfile was automatically downloaded to EtherCAT. However, from 2010, that process became manual; after the compilation, you need to go under the Build Specification, right click on the bitfile created, and select Download. Regular cRIO does it automatically, and I don't see the point of manually downloading it.
Does anyone know the point of doing this? And if it was not intended, I like auto download a lot better. But at the same time, 2009 and prior, the bitfiles were not shown under the build specification, which bothers me also. So the conclusion is that, I think it will be better to show the bitfile under the Build Speficcation AND download it automatically to EtherCAT.
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.
I'd like to have a dedicated FPGA Compile Server, based on a realy slim OS, e.g. damn small linux oder even PharLab? The OS does not realy matter, as far as it is multi-core capable and it should use as little system resources as possible, to get as much ressources as possible for the compilation process.
Purpose: get max. compilation speed
Recompiling an FPGA VI can be time consuming when debugging a large program. The emulator mode is not useful when the process includes debugging real I/O connections (vs. emulator simulated). I would propose a useful "fix" to the emulator I/O problem. Could the emulation mode have the ability to use all the I/O's as "pass through" connections from the FPGA to the host in order to actually use the I/O's. This would involve a very simple FPGA VI that connects all the I/O's to appropriate indicators or controls. If this pre-compiled VI is downloaded and running on the FPGA during emulation mode, then you could actually debug real I/O connections without compiling your entire VI.
When working with LabVIEW FPGA if so much as the value of a block diagram constant is changed, the entire application must be recompiled.
It seems that there could be a smarter method to deal with recompiling that might allow selected portions of the block diagram to be recompiled without the need to recompile the entire app.
Some of the tradeoffs might be lower FPGA utilization efficency and timing constraints, but allowing minor changes to the FPGA code without the overhead of a complete recompile would certainly make debugging applications much faster.
I am not necessarily proposing an implementation just posting an idea that seems like it would add value to the LV-FPGA development experience.
i would suggest some Improvements to the Timing Violations Window.
With kind regards
FPGA bitfiles should not have any dependency on the project name or target name. What if you change the name of your project? What if you change the name of the target? These dependencies should only correspond to the VI and its location in the project tree and FPGA target. FPGA bitfiles should be in the same directory as the vi but with a different extension.
Change the automatic name and path of FPGA bitfiles from: