We need a way to simply reinterpret the bits in our FPGAs. I currently have a situation where I need to change my SGL values into U32 for the sake of sending data up to the host. Currently, the only way is to make an IP node. That is just silly. We should be able to use the Type Cast simply for the purpose of reinterpreting the bits.
How amazing yould it be to have the ability to visualise resource usage on a FPGA target using a similar view to that shown above (courtesy of Windirstat)
I only recently shaved a significant portion off my FPGA usage by finding out that I had a massively oversized FIFO in my code for almost a year without noticing. I feel that this kind of visualisation (with mouse over showing what is actually occupying the space) with differentiation between Registers, LUTs, BRAM, DSPs and so on would greatly aid those of us trying to squeeze as much as possible out of our FPGA designs.
I think providing this information based on the "estimated resource utilisation" i.e. before Xilinx optimises stuff away would be OK. I'm not sure if the final resource utilisation can be mapped as accurately in this way.
It would also be nice to see CLIP utilisation and NI-internal utilisation at a glance as this is apparently hugely different between targets.
It is time-consuming that we have to compile all LabVIEW FPGA code even if there is tiny little change on FPGA code.
I understand there is sampling probe, Desktop execution node and simulation tools to reduce such time.
Our customer in Japan, would like to use incremental compile function also on LabVIEW.(Please see below)
I agree his opinion.
What do you think?
Application Engineer at National Instruments Japan.
Xilinx log window should use a fixed-width font.
Which of these two string indicators with identical content is easier to read?
The LabVIEW FPGA module has supported static dispatch of LabVIEW Class types since 2009. This essentially means all class wires must be analyzable and statically determinable at compile-time to a single type of class. However, this class can be a derived class of the original wire type which means, for instance, invoking a dynamic dispatch method can be supported since the compiler knows exactly which function will always be called.
This is not sufficient for many applications. Implementations that require message passing or other more event oriented programming models tend to use enums and flattened bit vectors to pass different pieces of data around on the same wire. All of this packing and unpacking can automatically be handled by the compiler if we can use run-time dynamic dispatch to describe the application.
We call for the LabVIEW FPGA module to add support for true run-time dynamic dispatch to take care of this tedious, annoying, and down-right boring job of figuring out how to pack and unpack bits everywhere. Whose with me?
Vision is available under LabVIEW 64 bit and this makes sense since vision can generate very large amounts of data. I think now is the time to bring FPGA over to LabVIEW 64 bit as well. With FPGA systems you can also generate very large data sets. Also with cards like the PCIE 1473R, you have a VISION requiring card that generates lots of data, but it requires FPGA, so you can only use it in LabVIEW 32 bit. This is not a good thing. It has been 5 years since LabVIEW 64 bit has been released it is time to finish moving the addons over to 64 bit.
User Lorn has found a brilliant tip for *DRASTICALLY* speeding up FPGA compile times under Windows for PCs with the turbo boost feature. What's more, it's extremely simple to implement.
Please let's see this in future versions of LabVIEW as standard.
When you are using same code on different boards, it would be a big help if you could set the "FPGA VI Reference" indicator as "Adapt to source". When I use dirrerent DMA on different target, then the wire break every time I change target:
My FGV for the FPGA reference looks like:
When accessing a FPGA control / indicator from the HOST, a ~property node is used, and the developer has to pick the right control / indicator from a list
When there's lots of items on the list, it can be a pain to scan the list for the right one.
At the moment they are listed in order they were created on the FPGA.
Could they instead be listed in alphabetical order? Or give the developer the choice?
I have recently started placing wire labels in my code to keep track of datatypes of wires flowing around my code. This is very useful to understand what is going on on the FPGA since not all grey wires (FXP) are equal and slight mismatches can mean big trouble in the code.
As such I tend to label wires like "Phase FXP+25,0" and so on.
What I'd love to be able to do is to place a formatter in a Wire Label to be able to keep such labels up to date because at the moment it's probably more error prone than anything else due to some wires and labels not being synced any more due to code changes or bugfixes.
If I can set a wire label to "Phase %s" or similar to place the ACTUAL datatype in the label this would be amazing.
Well it seems that persistent/non-volatile memory is not available on FPGA targets for scenarios involving cycling power.
Apparently, the recommended approach is to transfer the data to the host and store it to disk.
This is a bit problematic in that the choice is either to write data to disk at a high rate or to accept that the most recent data might not be reloaded on restart. For instance, an operator might expect to know exactly how many revolutions a shaft has undergone after power cycles to the FPGA target. A guaranttee that this information is as up to date as possible probably can't be met (maybe even under transferring data to disk at a high rate).
So I'd like to request this.
Many data streams contain information for multiple channels or multiple samples. Today one must pack this data into larger integer types or interleave the data manually into multiple writes to the DMA FIFO API. It would be much simpler if the DMA natively support cluster and array data types. The local FIFO, Memory, and Register APIs already support this; extend it to DMA.
A smaller (and cheaper) sbRIO based on the Xilinx Zynq chip. Target size is SO-DIMM form factor (68 x 30 mm (half the area of a credit card), 200 pins). Such a board would be OEM friendly and can be plugged into a product (rather than the current sbRIO offerings that requires the product to be developed around the sbRIO rather than the sbRIO fitting into your product). Also, a Base Board that is (only) used during development. Below is what the proposed sbRIO and Base Board would roughly look like (courtesy of Enclustra FPGA Solutions)
I got following feedback from a LV FPGA user:
When developing a FPGA application in LabVIEW, after submiting a FPGA code compilation - usually quite a lengthy process - if you modify the code either on the Front Panel or Block Diagram while compiling is in progress, this results in a Compilation Error at the end.
And this occurs regardless the modification be only a mere cosmetic change, without any implication in the code that is being compiled.
This is quite frustrating when you realize that the compilation has failed (maybe after half an hour waiting) just because you unconsciously clicked and resized some control or node.
In such a situation, when LabVIEW detects a code change while the FPGA compilation is running, it should warn the user with a message box; if the user confirms the code change, the current compilation can be inmediately aborted or let it continue (at user option); on the other hand, if the user cancels the modification, nothing happens and the compilation continues to a successful (hopefully) end.
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.
The FPGA compilation results should be copied to a file in the folder with the bitfile. This is needed to track the history of compilation results, especially useful when using source code control. Right now they get overwritten with each recompile.
Adding a Post-build action VI to the FPGA build spec, would also enable something like this.
On the cRIO-9068, the third serial port and the second Ethernet adapter is actually mounted on the FPGA, resources are consumed to redirect to realtime. Currently there are no access to this resource on the FPGA for developers, only from the Realtime.
I would like some I/O Nodes for interacting with these devices on the FPGA. NI could put up some examples how they could be used.
Today the resources are invisible to the developer, except for the additional long compile time and resources used (about 7%).
I attached pictures of the FPGA design and the resources consumed for a blank vi.
I'm currently looking for a way to read out the FPGA version number from the FPGA.
All I found was a way to parse the *.lvbitx, but that's not what I want.
Are there any plans to store the version number in a FPGA register to be read out at runtime?
Idea: New NI FPGA module with:
Something like Papilio Pro.
Reason: As ATE manufacture sometimes we need small FPGA to do something inside ATE or ITA (interface test adaptor). To use sbRIO/myRIO is to big (complexity,price). Because we use TestStand and LabVIEW out knowledge of VHDL is small.
We could learn VHDL but after that we could stop to use LabVIEW FPGA! :-)