LabVIEW FPGA Idea Exchange

As somewhat an opposite request to this idea

https://forums.ni.com/t5/LabVIEW-FPGA-Idea-Exchange/Ability-to-define-datatype-of-Registers-FIFOs-from-code-without/idi-p/3123936

I would like to show some pertinent information to the configuration of certain primitives in FPGA code.

The ability to turn this display on and off just like a label would be very welcome indeed. I'd always have it visible.

I just spent two days tracking down a bug which ended up being an under-dimensioned Block RAM instantiation (and how BRAM indexing works, just throwing bits away instead of coercing the read/write index), something whose configuration is completely hidden from view. Why can't we have some visible elements to show the size of a Block RAM and the Datatype (FXP would do for any given FXP type). Same goes for FIFOs, whether a FIFO is 16 elements or 8192 elements deep is a very important piece of information. And of course I mean only the primitives which instantiate the resources, not FP references for these items, even though the datatype of these would also be a very welcome addition.

With even simple examples we experience errors when trying to run Instruction Framework based LabVIEW FPGA VIs.

This is a blocker for our using Instruction Framework.

MGT interfacing to the 7915 is provided: https://forums.ni.com/t5/Examples-and-IP-for-Software/Aurora-64b-66b-Streaming-Example-for-the-PXIe-7915-Ultrascale/ta-p/3952187

It is not provided for other cards such as the 5785.  Is the interfacing the same?  Could examples for this be provided?

Working with the NI 5785 our team had a hard time understanding how to use TClk without all of the extra (e.g. streaming) code that comes with the example.

Through support we were eventually put in touch with R&D and they told us how to initiate TClk by setting some of the FPGA controls.  This was helpful but not intuitive.

TClk helps support beamforming applications shown in the NI Marketing but without this usability it is very difficult (impossible) to develop applications promised.

TClk also has other lower level features such as the delay correction.  No info is posted on this either but it is a property we can read.

When not using Instruction Framework to interface from the Host to LabVIEW FPGA the FPGA VI reference register items cannot be ordered by the user

They appear in a random order (order of creation) and it is not easy to find and select them.

I am referring to this function: https://zone.ni.com/reference/en-XX/help/371599P-01/lvfpgahost/readwrite_control/

The rvi folder has automation tools for FPGA compiles.  These are not very well documented.  There are no examples on using these.

Could additional info and examples be provided?

This is useful for projects where automated building helps continuous integration with tools such as Jenkins or Bamboo.

One of the benefits of the Instruction Framework is that one could develop several modules each using Instruction Framework.  The modules can then be integrated and the Instruction Framework modules can be assembled using Collections.

This information is not clear and the provided tutorial does not provide information on this use case.

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.

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  ]

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