From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW FPGA Idea Exchange

Post an idea

The project I'm currently working on involves a USRP 2954R with a small amount of FPGA programming (with the code running at 200MSPs). I ,of course, started editing the USRP FPGA Streaming example code to achieve this.

The Receiver code on the FPGA was edited to take the samples at 200MSPs (without the usual decimation), and perform a complex multiplication on it using a high throughput math palette. Post this I decimate my samples (Using the same decimator VI used in the Streaming example code) on a different loop in the Main FPGA VI.

Unfortunately I keep receiving a timing error on compilation which, upon investigation, shows a large number of non-diagram components eating away at the loop time. What I don't understand is why a complex multiplication followed by a decimation would require that much time to execute.

I've tried using the pipeline feature in the Complex Multiplication and also various compilation styles that optimize timing but I'm not able to cross 150MHz clock rate.

I also checked the knowledge NI page that talks about Non-Diagram components but pretty much most of the issues according to the page is about a long critical path, which in my case is not relevant because I literally perform only 2 operations in the concerned loop along with the necessary pipelining operations.

I've included the image of the timing violation along with the VIs. Could anyone please let me know what's going on or if I'm doing something wrong?

PS: The compiler I'm using is Vivado 2019.1.1

PS 2 : I haven't started working on the host yet

Download All

Both resource and timing reports can be hard to read.

Timing shows clocks that may not appear as SCTLs.

Resources show items which are not easy to trace back the resources on the FPGA itself.

This varies based on the target being compiled, for say 7976 (Kintex-7), 5785 (Ultrascale), and x410 (RFSoC).

There could be a knowledgebase article on "How to understanding LabVIEW FPGA compile results"

I know that for more detailed compile results we have exported to Vivado but for new users this can be very intimidating and a big distraction.

View All (1)

I'm bringing back to life this long-lost idea: https://forums.ni.com/t5/LabVIEW-FPGA-Idea-Exchange/pre-and-post-build-options/idi-p/2364676

as I think there are lots of situations where pre/post build actions could be useful for FPGA.

For example, as suggested here: https://forums.ni.com/t5/LabVIEW/Populate-FPGA-array-with-values/m-p/4145330#M1195362

I have a large array of coefficients that I want to load from a file, then populate an array constant with it. I have a script to do it, now I would like to automatically run it before compiling the bitfile. For context, I want it to be a constant because controls take more resources and do not allow constant folding optimization.

I already had another situation where I made a tool to auto-generate code in case structures based on some specifications given by the developer. If however the developer forgets to run it before compiling, the FPGA VI won't work properly as necessary code has not been generated.

More generally, I think scripting for FPGA is way underrated. As FPGA code is quite often tedious and redundant to create (because optimization is priorized over readability, and because of the lack of type genericity), scripting has a great potential here. Allowing to run pre/post build actions for FPGA bitfiles would surely take FPGA scripting to the next level !

View All (2)

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 ]

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

Perhaps there's already a good way to do this, but some structures/nodes are allowed in a Single-Cycle Timed Loop but their behaviour is significantly changed, perhaps breaking your VI.

It would be good to be able to mark VIs in some way as unsuitable for use within a SCTL.

An example is the flat sequence structure - you can place this in a SCTL and it can pass intermediate file generation, but the behaviour is as if there was no sequence structure.

Assuming that it isn't always superfluous, this probably indicates invalid behaviour but is not necessarily obvious to detect (e.g. with broken compilation or intermediate files).

Some specific node that could be placed on a block diagram and indicate that a VI cannot be placed inside a SCTL would be useful.

Something like a Divide can be used for this, but not trivially easily - you need to actually use the output of the Divide or else the dead-code elimination allows the intermediate files to be happily generated. It took me quite a few goes to get a failure even with SGL precision divide in a SCTL... wiring to a structure or an indicator is not enough, it must be something that actually uses the value.

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.

View All (5)

When debugging, I find it useful to have Graphs on my FPs. Mostly for running in simulation mode but sometimes I want to verify that the compiled code behaves the same way.

I currently have to replace all of my Graphs (fed with fixed size arrays) with Arrays since I can't define the FP element to be a fixed size, unlike arrays. This makes debugging a bit more of a pain than it needs to be.

Is it possible to gbet the option to define a Graph as being a fixed size so that this replacement step is unneccessary?

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)

Hello,

Recently, Last year, i've had a bad experience, when i tried to compile my old FPGA applications with Windows 10.

=> The FPGA ISE XILINX compiler is no more compatible with Windows 10.

Will something be done ? I got no clear answer from NI support ...It should be a XILINX problem !

The issue is that some products on the NI web site, are sold without clear information about the incompatibility with Win 10 !

Please, add a "clear highlighted Warning" on the product page in order to inform about the problem : On FPGA boards and on CRIO targets ...

Thanks for help.

View All (1)

Arising from similar requirements as I have posted many moons ago: HERE.... I naively thought putting a terminal in a disable structure would remove it from the FPGA compile. It doesn't.

Years later, I have developed a nice debug interface for my FPGA code which is becoming more and more modular as I refactor it. I have many sub-modules with their own debug interfaces which can be turned on or off from the top-level VI via LVOOP method injection.

The problem is that I can't really compile my entire FPGA VI with ALL debug paths enabled as this just won't fit (It will sometimes compile, but most often not and our FPGA code base is still growing). And this is before I even think about making my debug information more detailed. I would like to be able to easily switch certain aspects of the debug interface on and off as testing requirements change. On the debug interface level I can do this easily by simply not reading the data from the objects being used for the data transfer or simply passing in abstract methods which don't actually do anything and get optimised away. But I'm left with a load of FP controls which are still eating up resources on the FPGA target. I don't want to delete the controls because that leads me to X copies of ever-so-slightly out-of-sync versions of my test VI which quickly becomes a maintenance nightmare. Instead, I want to be able to "easily" reconfigure my test front-panel to only compile the stuff I'm currently actually interested in.

Part of what I would like is the ability to actually define areas of the FP which are enabled, disabled or enabled (and preferably also based on whether simulation is active or not - hence conditional disables for FP). This way, when compiling, the FP elements will actually disappear and full resource savings can be made (as Xilinx is clever enough to optimise away any pointless code LV may stillhave instantiated in VHDL). In addition, the ability to define certain controls as being enabled only when in simulation mode can allow us to have SGL graphs and so on present when needed during debugging.

So, would having conditional disable options for the FP (where controls are shown as greyed out when not available) be of interest to anyone? If this would be an FPGA only thing, I wouldn't shed and tears.

Am I the only one who would use this? hmm. Maybe.

I don't like static resource definitions FIFOs, Block RAMs or DMAs in my projects. I prefer to have the code declare such entities as they are required because this makes scalability much easier to achieve.

For FIFOs, BlockRAM and so this is no problem, but there are two things we currently cannot instantiate in code:

DMA Channels

Derived clocks

To deal with the seond option: Why is it currently not possible to create a derived clock in code. The ability to automatically have one piece of code accept a single clock reference and let one loop run at a multiple of the speed is something I've wanted to be able to do in the past but it is currently impossible in LabVIEW.

Please let us configure / define derived clocks in LV code.

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

Non-diagram Component timing error on NI-USRP FPGA Compile

LabVIEW FPGA Compile Report can be unclear

"Update Firmware" button functionality is not described on NI documentation

Add pre/post build actions for FPGA

FPGA compile automation tools

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

Provide a no-op method to forbid compilation in a SCTL

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

Unsupported nodes inside for loop within SCTL should result in a broken VI

Stop disconnecting typedefs in Register Items, Memory Items, FIFOs, and Handshake Items

Colour coding for Estimated and Final timings

Do Not Compile Sequence Structures Inside Single-Cycle Timed Loops

Fixed size Graphs for Debugging (similar to fixed size Arrays)

Tell us why an FPGA needs to be recompiled

LabVIEW FPGA ... limited only by Windows 10 !!!

Get rid of coercion dot when using a smaller integer for index

Conditional Disable options for Front Panels of FPGA VIs

Display max clock rate that can be achieved during development itself

Intermediate file generation in parallel

Derived clock instantiation