LabVIEW FPGA Idea Exchange

Post an idea

I work with malleable VIs a lot on desktop. They can save a lot of boilerplate code. From my understanding, the entire feature has no effect once code is compiled: the VI is converted to an "instance" VI with the proper data types and inlined into the caller. This doesn't seem like it should be problematic to use on an FPGA target.

Here are a few FPGA-specific wins that I think VIM support would deliver:

Array size adaptation
- One can imagine writing a "parallel for loop" VIM that simply expands out N parallel iterations for array sizes 0-N
Fixed point configuration adaptation
- Without VIM, if you write a VI that operates on fixed point numbers, it will auto-coerce to the configuration on the controls of the VI

Hi,

I'd like to request that NI enables the use of Xilinx XPM Macros in Component Level IP (CLIP) and Socketed CLIP and custom user IP:

Xilinx recomments XPM macros for Clock Domain Crossing (CDC) and FIFO / Memory instantiation because they are more easily reconfigured / managed than classical IP and (especially in case of CDCs) auto-generate timing constraints to ease getting a correctly constrained design.

XPM Macros are available for all current Xilinx/AMD devices (7-Series to Versal):

XPM Macros in 7-Series Libraries:

https://docs.amd.com/r/2021.1-English/ug953-vivado-7series-libraries/Xilinx-Parameterized-Macros

XPM Macros in UltraScale Libraries:

https://docs.amd.com/r/en-US/ug974-vivado-ultrascale-libraries/Xilinx-Parameterized-Macros

XPM Macros in Versal (Premium/AI) Libraries:

https://docs.amd.com/r/en-US/ug1344-versal-architecture-libraries/Xilinx-Parameterized-Macros

https://docs.amd.com/r/en-US/ug1485-versal-architecture-premium-series-libraries/Xilinx-Parameterized-Macros

https://docs.amd.com/r/en-US/ug1353-versal-architecture-ai-libraries/Xilinx-Parameterized-Macros

Unfortunately, XPM macros are only available in SystemVerilog at lowest level, although VHDL instantiation templates do exist (see documentation above).

AMD/Xilinx seems to have no plans to add pure VHDL XPM Macros:

https://support.xilinx.com/s/question/0D52E00006hpeAySAI/no-vhdl-simulation-models-for-xpms-?language=en_US

Excerpt:

graces (AMD) on 2017-12-07
There's no plan to support VHDL model for XPM in future releases.

graces (AMD) on 2017-12-14

The Xilinx direction for any new development is in Verilog. It can be overridden with business justification though.

If you have a strong demand, I'd suggest that you open a Service Request with Technical Support and get a CR filed. The SR will be linked to the CR. If quite a few SRs are linked to the CR, the chance to get it implemented will be larger.

Since NI does not document that the FPGA module does not play nicely with CLIP that uses XPM macros, I had to find out what is needed to get them to work:

My preliminary result is that I can get a bit file if I only change/patch the call of xelab that the FPGA module performs from

xelab.bat -m64 xil_defaultlib.conf12B308D38326465793B06F85282B8708 -L xil_defaultlib -L unisim -L unimacro -L xilinxcorelib -L secureip -snapshot my_clip_top_level_entity -dll -prj clipsyn.prj

xelab.bat -m64 xil_defaultlib.conf12B308D38326465793B06F85282B8708 -L xil_defaultlib -L unisim -L unimacro -L xilinxcorelib -L secureip -L xpm -snapshot my_clip_top_level_entity xil_defaultlib.glbl -dll -prj clipsyn.prj

and add the line

verilog xil_defaultlib "C:\NIFPGA\programs\Vivado2021_1\data\verilog\src\glbl.v"

to clipsyn.prj.

I'm using Labview 2022Q3 with the 2022Q3 FPGA module, targeting a sbRIO-9629's Artix 7 with the bundled Vivado 2021.1

So it seems all that is needed to enable the use of XPM macros in (socketed) CLIP is a configuration option that performs a simple extension of the elaboration command arguments and file list.

If NI decides not to support XPM macros for whatever reason, this should be documented very prominently in the CLIP sections of the user manuals. Also, NI should consider providing their own macros with the same functionality in this case, at least for CDCs.

Using a netlist or user IP to wrap XPM CDC macros does not work, since the design constraints are added by tcl files (partially only as exceptions), that are not retained in the netlist or IP, see

https://support.xilinx.com/s/question/0D54U00008aHc9ESAS/handleretainexport-xpm-cdc-macro-timing-constraints-for-ooc-design-exported-to-a-netlist-that-is-then-used-and-implemented-with-another-design?language=en_US

So there is currently no workaround to use a design that depends on them.

Thanks for considering this.

View All (7)

Visually detecting the presence of CDC (Clock Domain Crossing) in LV code is only semi-intuitive. It is required to check the set clock of the SCTL and / or follow the wire to the clock constant / control in order to understand in which clock domain the code is running.

I suggest having the option to automatically colour the background of the SCTL according to the clock being used.

Obviously, this won't work well over VI borders, but at least the option to have it vivible on the same diagram is already a nice step towards better visibility of this really important part of LabVIEW FPGA programming.

An option to actually couple a colour with any given clock constant / control for SCTLs would be an addition I personally would very much appreciate.

Yes, these colours are probably a bit extreme, but given the fact that I'm dealing with so many individual processes, it is preferable to having to constantly follow all the wires or investigate all of the SCTL settings.

View All (1)

It would be nice to have control of clock.-independent assignments of signals from I/O nodes (without synchronising registers) without having to specifically having to use a clock for the connection.

Image says it all.

We have tried using a static assignment on the top-level diagram, without using a SCTL but it appears that does not work. The example links within a single CLIP, but the idea is aimed at actually doing some connections between multiple different CLIPs without the need for a specific VHDL wrapper for each individual configuration.

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)

View All (1)

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.

View All (2)

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.

View All (6)

View All (1)

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.

Shane.

The error "You must recompile the VI for the selected target" appears for reasons that, to me, are often obscure or even inexplicable. Recompiling is, as we know, painful. It would be good if the error message included the reason(s) for refusing the existing bitfile, since then I may be able to work out how to stop it happening.

I understand the message comes because LabVIEW decides there are "dirty dots" associated with the bitfile, what I would like the error message to tell me is which dots are dirty and why.

View All (1)

View All (2)

With availability of fast FlexRIO cards (such as NI 5761) and FPGA framegrabbers (NI 1483, PXIe-1435, NI PCIe-1433 ) data rates of 1GB/s are becoming commonplace. However, the FPGA Module is limited to communication only with 32-bit LabVIEW. Since, typically you want to store more than 2 seconds of data in RAM,you would like to use 64-bit LabVIEW as your host application. Unfortunately, this isn't possible yet.

While, I can imagine that a full blown 64-bit FPGA Module add on would be pretty difficult to build (and especially test), I believe there is a solid middle ground at this point. I can imagine, coding and compiling the FPGA in the normal 32-bit LabVIEW environment, and then just using a 64-bit host application to Read/Write front panel controls and to read/write the DMA buffers from the FPGA. I don't know the details, but this communication protocols could be very low hanging fruit if it's just a simple matter of recompiling a few key pieces for 64-bit operation.

Since the data rates passing to and from FPGAs will continue to climb, as well as the prevalence of 64-bit OS, a 64-bit version of FPGA Module is needed in the new feature pipeline. This should also be kept in mind as other new FPGA Module features and tools are created, as planning for 64-bit compatability now will make the eventual transition to 64-bit much, much easier down the road.

View All (8)

Number to Boolean Array and Boolean Array to Number along with array manipulation functions (index, replace, reverse) are commonly used methods in FPGA for doing bit manipulation on arrays of integers inside SCTLs. Not having access to these functions is prohibitive and results in having to write code like this:

This becomes very unwieldy when dealing with arrays of 20+ elements. If Number to Boolean Array and Boolean Array to Number are truly no-op elements, then they (along with basic array manipulation nodes) should be added to the list of supported nodes inside for loops inside SCTLs.

I just manually transferred a fairly large LabVIEW FPGA project from one target to another (7965R to 7966R). It would be nice to be able to click on the RIO target in the project and have an option to "Migrate to New FPGA Target" in the context menu. The menu would open a new dialog where you could select the new RIO target and then it is automatically added to the project and populated the VIs, FIFOs, derived clocks, memory blocks, etc. from the original target. The user can choose whether or not to delete the original RIO target.

This would also make it very easy for users to transfer sample code from the LabVIEW Example Finder to the correct FPGA target (insead of having the folder labeled "Move These Files").

View All (4)

Single cycle timed loops are a huge performance enhancer in LV FPGA. We learn to use these very prolifically in and around our code to save precious FPGA space, yet the BD representation of the SCTL is the standard Timed Loop structure, with both the Left and Right "ears" visible as well as the conditional terminal.

I propose that the SCTL be given it's own representation on the block diagram, one without the "ears" and without the conditional terminal (by definition it only runs once). This will promote much cleaner looking FPGA code and more readable diagrams.

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

LabVIEW FPGA Idea Exchange

Support malleable VIs in FPGA targets

Enable usage of Xilinx XPM macros in Component Level IP (CLIP) and Socketed CLIP

Option to colour-code SCTL backgrounds according to Clock selections

Concurrent assignments on the LV top-level diagram

Smaller (and cheaper) sbRIO based on Xilinx Zynq

Show some important resource data on FPGA items (Block RAM, FIFO etc.)

Multi-core Compiling

Please add FIND ALL functionality for Memory, Register, and FIFO items

Add JTAG access to NI FPGA hardware

Create single FPGA I/O node instead of multiple

FPGA resource utilisation visualisation

Tell us why an FPGA needs to be recompiled

Allow Type Cast in FPGA

64 bit FPGA tick-counter

FPGA module for 64-bit LabVIEW

For loops inside SCTL should support Number to Boolean Array and Boolean Array to Number

Auto-Migrate to New RIO Target

Make Bitfile Paths Relative, Not Absolute

Simplify the display of Single Cycle Timed Loops in LV FPGA

Allow Cluster and Array Transfer Types for DMA Streams