LabVIEW FPGA Idea Exchange

Post an idea

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.

NI has released an exciting new product with the High-Speed Serial board which is essentially a Kintex 7 with GTX transeivers exposed.

https://www.ni.com/en-us/shop/model/pxie-6591.html

https://www.ni.com/en-us/shop/model/pxie-6592.html

Some applications we are working on would benefit greatly from having some way to expose the GTP / GTX / GTH transceivers ont he various NI FPGA boards to enable high speed serial transmissions on a wider product palette. Even the Virtex 5 supprts up to 16 GTP transceivers. Having even 8 of these available for Aurora communication would be a complete game changer as we could move over to optical links between individual devices.

In order to be able to make proper use of this, NI needs to offer GTX / GTH / GTP options for many of their boards. Imagine the power which could be unlocked by itnerfacing 8x Zynq 7010 boards with a single Kintex 7, each Zynq performing some aspect of pre-processing (Analog control, switching, some aspects of control) before sending results back to the Kintex 7..... For those of us working in Scientific areas, the prospects of a system like this is truly mouth-watering.

When I use a FPGA Read/Write control to set a state from Windows to the FPGA target, I would like to be able to search for all the places where that is done. If I do a search-Text for the FPGA Read/Write control variable names used to set the state, they are not found. The work-around suggestion from NI was "to include the text that you are looking for with each instance of the control, one way to accomplish this could be to label the wires going into or out of each terminal with the name of the control." This would work, but it would be better in a future LabVIEW version to have the search function be able to find the variable names.

Improvements for Continuous Integration

Proper unit testing is a key component of large LVFPGA project success. As the number of modules grows, so does the number of units tests increase. We are working on automatic continuous integration methods that will continue to monitor the accuracy of all modules and assemblies throughout the project life cycle. IP Integration node and NI's wrapper around Xilinx IP makes this task more difficult. When our continuous integration machine refreshes the source code from the repository it has to regenerate these nodes in order to compile. The "Regenerate IP Integration Node Support Files..." tool does not always properly update all IP. It seems like the NI wrappers around Xilinx IP are most problematic. The only way a computer can properly update its version of the node is to open the VI and click through the Xilinx IP generation pages to get it to update.

As a rule we do not commit build products into our source code repository. One option would be to submit all the support files generated when first creating the IP integration node so that others users might not have to update. This can become messy and quickly unwielding. The problem arrises when changes to the IP integration node cause more or fewer support files to be generated. This then requires deleting some files from the repository and adding others which is tedious and leads to errors. One compromise would be if the IP integration created one single compact file that contains all the information needed (expect the input vhd, etc. files) that could be committed to the repository. Even better would be to roll this information into the VI itself. Neither of these might be ideal if the support file contents take up a lot of disk space.

Regardless there needs to be a better solution to allow for automated continuous integration testing.

View All (4)

Include co-simulation with ISim

Hello,

i would suggest some Improvements to the Timing Violations Window.

Highlight the Whole Path with all Element and Wires in the Blockdiagramm when i click on Path in the Timing Violations Window.

Highlight the Element on the Blockdiagramm which i clicked in the Timing Violations Window.

Give the Problem Window of the Timing Violations Window the ability to adjust its size i often have to scroll. (Can be seen in the Timing Violation Window above)

With kind regards

westgate

Compiles Started over a VPN

dedicated FPGA compile server

LabVIEW NXG had the ability to create a resource file. Though I cannot find the help reference for this I will describe the functionality below:

Right now the Target Scoped FIFO, P2P, DMA-FIFO, Memory, Handshake Items, Registers, Clocks, etc are all stored as part of LabVIEW Project (lvproj) file.

If want to port to a new project file or target I have to copy/paste. This is not a big deal and works well. However if I update one project's configuration I have to re-copy/paste. From a configuration management perspective I cannot ensure the configurations are always the same. With larger, multi-FPGA projects this becomes critical.

It would be great to have a file that holds all of these resources to allow for easier portability and configuration management.

View All (1)

When we try to compile timing critical FPGA application, if might be failed because of timing violation.

But if it missed only a few nanoseconds, recompiling might resolve the error as below.

Resolving Timing Violations on the FPGA

If your failed compilation misses the required throughput time by only a few nanoseconds, try rebuilding your bitfile. Each build of a bitfile does not always produce identical results on the FPGA, so rebuilding sometimes resolves minor timing violations.

In most case, compilation might require much time and it's difficult to take quick action after they found the aborted compilation result.

It would be great there is an option which allow automated recompile like below.

Of course the compilation completed, it wouldn't try recompile. Only failed, try to compile again.

** -------------------------------------------------------------------- **

Enable Auto Recompile [ * ] Number of Retry [ 4 ]

** -------------------------------------------------------------------- **

I've searched but can't see anything similar - please add a method for setting the timeout for FPGA nodes. This includes the 'Open FPGA reference' and FPGA IO nodes.

If you disconnect a cRIO FPGA (e.g. NI 9148) from the network, it takes 20-30s for the IO node or Open FPGA reference to execute. This is really bad for the user experience as if they try to exit their application in this time it may take half a minute for the application to exit. It also means you may have to wait that length of time to realise that your FPGA has disconnected under most use cases (you can obviously have an external watchdog loop to check that the node is executing in a timely manner)

Please allow me to configure the timeouts for these nodes similar to the TCP/UDP or VISA nodes. They are very similar in how they operate to the FPGA nodes (i.e. a hardware device driver which is susceptible to disconnects!) so I don't understand why these have been omitted.

I wouldn't mind having to set the timeout as part of opening the FPGA reference and then internally have it use the same timeout for other IO nodes as follows:

View All (4)

Link Wire label to Data format

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.

FPGA Graph handling

I've developed a small test utility for testing FPGA code on my windows machine before proper FPGA testing and have noticed something I think could be improved.

If I have a graph or any other indicator with DBL default data type within a conditional disable, the compiler still throws an error regarding an unknown state (DBL). Although the terminal is in the diagram disable, the object seems to remain on the FP (but also in the code being sent to the FPGA compiler).

Can we actually remove the graph (or other culprit control) in the background before starting the actual compile so that I don't need to drop and re-connect every time I want to switch execution systems?

Shane.

Enable Auto Indexing for LabVIEW FPGA

Problem:

Auto-Indexing of LabVIEW is extended to LabVIEW FPGA, only with one small caveat. You can easily auto-index into a loop, but not out of it. You will understand this better if you've already worked with LV FPGA.

In the FPGA paradigm, we enforce compile time resource determinism, by making sure all our arrays are of a fixed pre-determined size. In auto-indexing out of a loop, we may not know what the size of the array is, and hence it breaks the VI with the error "Arrays must be of fixed size". Try to write the following code in LV FPGA, for a better picture:

Solution:

The current workaround is that we have a fixed size Array which we then use in and out of the loop, replacing its

elements, as shown below.

However, an easier and much much more intuitive solution for users would be to just right click the auto-indexed tunnel and set the dimension size.

This definitely means that the number of data flowing out of the loop could be more than our fixed size. We handle that case by providing the user with the "In case of overflow" option.

This would ease our effort in coding LV FPGA as much as it would would improve intuitive coding. Vote for this idea if you think it would make your life a tad bit easier.

Single-Board RIO with MGT exposed

Intermediate file generation in parallel

Please give us FXP-based enums

When instantiating case structures, the bit width of the selector has an influence on the efficiency of the code being produced. Of course various compiler optimisations will (may?) do a lot of this lifting for us if we actually wire in an FXP (which LabVIEW again tries to coerce to I32, but that's another battle) but I'd like to have the ability to create, use and convert to and from enums with variable bit-widths. Of course the only parameter of importance for this is the width of the FXP, the integer bits become essentially irrelevant.

I currently have to do a lot of U8 Enum FXP conversions in order to be able to force my case structures to adapt to a given width when supplying an enum to control some code. Readability would benefit greatly if the enum itself could "simply" be an FXT to begin with.

FIFO read that doesn't use 100% CPU

View All (1)

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.

Sincerly,

Jens Eriksen

View All (4)

LabVIEW FPGA Idea Exchange

Allows locking of parts of the block diagram to minimize compile time

Expose Serial transceivers for FPGA boards

FPGA Read/Write Control name search

Improvements for Continuous Integration

Include co-simulation with ISim

Improvements of Timing Violations Debuging

Compiles Started over a VPN

dedicated FPGA compile server

Add ability to have resource files in LabVIEW FPGA

Enable "Automatically retry the compilation if Timing Violation Error occured" option

Add timeout input to FPGA nodes (Open FPGA reference, IO nodes)

Link Wire label to Data format

Allow Select Node to Invert Select Terminal

FPGA Graph handling

Enable Auto Indexing for LabVIEW FPGA

Single-Board RIO with MGT exposed

Intermediate file generation in parallel

Please give us FXP-based enums

FIFO read that doesn't use 100% CPU

Access to serial and ethernet port in FPGA for cRIO-9068