LabVIEW FPGA Idea Exchange

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)

It would be nice if this code:

Case Structure version

could be replaced by this code:

Select version

but doing so gives an edit-time error specifying that "Select: Possiblity of Dynamic Refnum not supported for current target".

Is there a fundamental reason this can't be allowed? The behaviour is presumably the same in each case, and the references are from the same place in both cases. In the case structure, the exact same references that are passed to the Select node are used, with the same True/False choice.

It's not a huge issue, but it would be a nice usability/readability improvement.

In labview it is not allowed to exit SCTL running in an external clock domain. Labview claims it could lead to instability of code due to glitches etc on the external clock.

I propose to leave the option open to the programmer to take that risk, which is not always there. It can lead to better understandable code.

For example I have code where I read data from an NI5752 ADC module and store in in block RAM (32 ADc channels, 32 block RAMs). Reading from that ADC implies acquiring the data in the external ADC clock domain. So, also the writing to memory is in that clock domain.

I needed to implement a function to reset the memory as well. That means writing to that memory. That has to be done in an SCTL in the same external clock domain.

However, this reset function (subVI) can no be inserted in the normal "enable chain" of the main program, since the SCTL can not be terminated and the memory reset subVI never terminates.

Now I had to make an ugly trick to get this done. In the main program I create a dead branch doing the reset. That subVI never stops, but after the reset has been done it send a signal via a FIFO to the "wait reset" subVI in the main enable chain. the wait reset is running in the default clock domain and can exit the wait loop after the reset signal has been received.

However, this trick is not easy to understand from the program. It would have been easier if the reset function (external clocked loop) could have exited by itself and be inserted in the main enable chain. That would have been more logical..

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.

Xilinx supports BRAM primitives (FIFO and normal BRAM) with certain varying width read and write ports. For some applications, the ability to write 2x 16 bit values to a FIFO in one loop and read 1x 16 bit value from the FIFO at double clock rate in another loop can be very useful.

As it stands, the IPCore for such BRAM primitives, although present in LabVIEW FPGA, cannot be used without a CLIP (essentially making this aspect of the IPCore useless).

It would be cool if LV would expose the ability to have differing read and write port widths for BRAM.

View All (1)

View All (2)

When parsing message packets in my FPGA code I'm often using a custom packing method with multiple individual datasets being packed into a single U64 (for example) for transport.

With the introduction of Malleable VIs, I would love to be able to create my own packing and unpacking Malleable VIs but don't yet see how. Problem is that the "Boolean array to Number" does not allow attaching a datatype like the "To FXP" does. I would like to marry these two functions into a "Boolean array to FXP" node where I can wire in my input datatype and have the output datatype automatically maintained in a malleable VI.

The error cluster has a string to identify where the error occurred, "source". In a FPGA code the string is only accepted (no broken run arrow) inside an error cluster. I guess this is implemented in this way to maintain code compatibility when you move code to another kind of target. The problem is that doesn't matter what you write in these strings when you are in a FPGA environment, it's ignored.

Some people use the same error code to show a kind of error changing only the source to identify where. I got a software, written by somebody else, that used error code 5000 in all user defined errors, changing only the "source" string. That give me no clue where the error was happening.

Since in a FPGA target only the "code" is useful i a error cluster, I propose two solutions:

1) A warning when a string in a error cluster is not empty (compilation time);

2) The FPGA compiler converts the ASCII chars in "source" string of the error cluster in a fixed size array of bytes [U8]. This array will be converted into a string in a target that can handle it. This is very common when you read a error cluster indicator in a FPGA VI from a RT VI. This solution will have a little overhead but it maintains 100% compatibility.

I like the second solution a bit more. A limited number of characters should be allowed order to save memory. One solution to that is to have a configurable option to determine how many chars is the maximum allowed.

View All (1)

I love using enums because they can often make discrete options much clearer. Example:

enum clarity.PNG

But, at least as of 2017, the below code is going to use fewer resources and propagate faster because LabVIEW is going to use an 8 bit register above instead of the two bits below.

My solution is to allow smaller integer representations of enums (I'd use a U2 in the above case).

Ideally the user wouldn't even have to specify the integer size, it could just calculate the minimum at edit time and show the user what it is.

VBAT input voltage in VBAT Requirements of sbRIO-9651(SOM) should support less Voltage.

SPECIFICATIONS NI sbRIO-9651

http://www.ni.com/pdf/manuals/376962b.pdf

VBAT is for keeping the time on RTC.

Minimum of VBAT input voltage in specification is 2.875V.

In general, the button cell is used to keep time like a Mother board of PC.

For example, CR type Lithium button cell has Nomal voltage 3V and End-point voltage 2.0V.

In this case, if we follow the specification, we can not use this CR type lithium button cell . Many users would like to use this CR type button cell for RTC. So, if we can chang the specification of Minimum VBAT voltage from 2.875V to less 2.0V, it is easy to use in many cases.

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

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

NI USB-78xxR use 325T FPGA

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

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

Selecting between two I/O refnums not allowed

Externally clocked Timed loops : Allow exit

Conditional Disable options for Front Panels of FPGA VIs

BRAM Primitives with different Read / Write data widths

Scan Interface for R-Series Devices

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

LabVIEW FPGA properties Custom Control Data Type dialog boxes need to show the path and name for the last configured .ctl

Wait until more than one IRQ has occured

Boolean array to FXP

The text in the "source" component in a error cluster is useless in a FPGA VI

Allow smaller integer representations of enums

VBAT Requirements of sbRIO-9651(SOM)