LabVIEW FPGA Idea Exchange

Post an idea

In correlation with another general idea I have posted, I have come to the conclusion that it would be nice to run an analysis of the Xilinx log in order to give feedback over which code has been constant folded by the Xilinx compiler.

Other aspects such as specific resource utilisation would be really cool also (SRL32 vs Regsiters for Feedback nodes). This would obviously be a post-bitfile operation but could at least give some direct feedback as to what the Xilinx compiler has modified in the code (Dead code elimination, constant folding etc.).

View All (6)

While attempting to debug NI1483 issues, I found it necessary to make modifications to the NI1483 CLIP. In LabView 2014 and earlier, it's not possible to maintain your own IO Module CLIP directory. One must maintain all IO Modules within the IO module search path (<National Instruments>\Shared\FlexRIO\IO Modules folder ). This can be done by copying an existing IO module to a new path within the <National Instruments>\Shared\FlexRIO\IO Modules folder, then editing the *.tbc file to rename the "model" key. The main issues with this approach are the potential lack of administrator permissions and the difficulty of maintaining source control in a non-project related system directory.

The suggestion is thus:

1. Give the user an option to select the path of the IO module under the IO module Properties General Category (When Enable IO Module is selected).

That's it!

I find myself again and again having to memorise bit field index and other things in order to be able to debug FPGA code efficiently. What I would really like to be able to do is to create an XControl with a compatible datatype (Say U64) and have this display and accept input in the form of human-readable information.

The data being transported is simply a U64 and the FPGA code doesn't need to know anything about the XControl itself. Just allow a host visualisation based on an XControl to ease things a bit.

I've already started using LVOOP on FPGA and I think this could be another big improvement in the debugging experience. Having an input XControl (or a set of XControls) for certain LVOOP modules on the FPGA just gets me all excited.

I would like to see some form of simple locking mechanism for VIs that are targeted to an FPGA.

The use case would be where you have compiled a VI for your FPGA target and are currently in the process of debugging/testing it. While running interactively and opening and closing VIs, you accidentally move something on a block diagram without realizing it. The next time you hit the run button LV shows you the "Generating Intermediate Files" dialog and you have now ventured down the one way street to a full FPGA recompile.

I know that source code control or setting all files to read only would also work, but when debugging a project, it is cumbersome to continually check all files in and out, or to continually change the directory attributes.

Just a simple lock/unlock button on the toolbar to keep from shooting myself in the foot while debugging.

....posted as I sit here waiting on a 4 hour FPGA compile for just this reason.

Malleable FPGA VIs import into the Desktop Execution Node with the same datatype as the FPGA VI's "malleable terminal". The Desktop Execution Node does not mutate the input type to match the "malleable terminal" of the FPGA VI. As a result, host VI test benches cannot iterate Type Specialization Structure cases in the malleable FPGA VI.

The "anything" input to this Assert Structural Type Match node is an I16, which breaks this case against an I16, which is the "malleable terminal" of this VI.

The Desktop Execution Node only sees the I16, and coerces other datatypes.

IMO the compiled Type Specialization Structure case is a critical unit test, which depends on the data type of the control wired to the "malleable terminal", so this is a critical limitation of the Desktop Execution Node.

I think the intended use-case for the DEN is to hook into an FPGA VI that's in a loop, and if so, the inputs to the malleable VI are selected by the calling VI. So, maybe this isn't a limitation of the DEN itself, but of the DEN workflow.

Thanks for your consideration,

Steve K

View All (1)

when you try to use serial NI 9870/71 with crio controllers it will lead you directly to access them from FPGA mode, however you will find it difficult or not allowed to use its connection with MODBUS device so it will need be accessed by scan mode by installing the specified software on your crio to enable scan mode for these devices , may be we need clear declaration in serial NI 9870/71 datasheet to show that its possible to connect them in scan mode as it guide us only to FPGA and what are the best practices to it

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)

When debugging FPGA code, I still like creating debug code right there in the FPGA code with FP debug indicators. After some simulation I can then compile (the exact same code) and test with hardware.

The IDE, however, makes my life really hard. In the background, each VI has a default build spec or bitfile associated with it. When a tiny tiny change occurs in the source code (some of which seem overly sensitive BTW) the interactive mode will not start.

It would be nice if we had the option, assuming that the FP controls are identical, that we can start an interactive mode where the existing bitfile is used with the same FP of the VI source. A visual indicator that the bitfile MAY NOT be identical with the code would by a good idea. Sometimes changes are trivial, sometimes when fixing a bug, we might want to double-check old behaviour for a moment before starting a compile process. The ability to maintain the option to execute the last compiled code seems like it would be a nice addition.

And yes, we could make a RT app which interacts with the FP elements but since debugging code changes often (including FP elements), this is a problematic maintenance issue.

Hello,

I simulate small FPGA code parts from time to time, and use these while doing it.

There are 2 helpers.

1) Simulation time estimate and progress: Module_SimulationProgress_Caller + Module_SimulationProgress_Popup

Here the idea is to just add the caller VI and it will call and display progress.

It has some "autotune" funtion to not call popup to often, but still update once in a while. It tries to hit around 0.5-1.5 sec in update.

This will minimize time spend on popup after some iterations. It also makes it possible to stop the main sim VI.

The estimator only works if your code is fairly static.

2) Data collector while running: Module_FGV_DataCapture.vi

Here the idea is to collect data (in fast buffer) while simulating and use it to display while simulating.

It has 5 buffers that can have different number of elements in them, but all have same length.

Then in a "slow" loop I update graphs once every second, then i can abort if i see something wrong.

This is to avoid having graph plotting in highspeed loop or using graph after simulation is run.

3?) Maybe i will add a plot VI that can take data in from the buffer, just to clean up simulation VI, and make it generic.

Can i get some feedback if it is good or not? Any other sugestions are wellcome!

Or how you do your small FPGA simulations?

Thanks.

This has been a huge frustration in my development. There is no way to debug a Flex RIO + NI1483 FPGA design other than to tweak, compile, and test with actual hardware. NI should provide a VHDL behavioral simuation of all of their modules so that full end-to-end simulation can be performed using advanced simulators such as ModelSim. This would facilitate a much more robust FPGA development cycle for their customers who have these types of tools available.

For the NI1483, a VHDL simulation combined with a VHDL Camera Link behavioral model would be even better. But the CameraLink model could be developed by the customers as it (At least) is a standard or can be gleened from camera manufacturer documentation.

Hi,

I find Conditional Disable Symbols in FPGA code very useful especially in a R&D environment where needs and code change back and forth rapidly. However, I also find it hard to keep track of all these changes. I propose to add support for reading FPGA Conditional Disable Symbols from Host to enable VIs like "Is_FPGA_Function_A_Enabled.vi" that would allow for the Host program to know the state (hardware revision of sorts) of the FPGA bitfile and adapt.

I'll give an example to illustrate this proposal.

Function A is implemented in FPGA bitfile v1. Function B is implemented in Host and is based on multiple calls to Function A. Your boss now wants Function B implemented in FPGA for performance reasons with means to disable the code if required. For this you define a Conditional Disable Symbol in the FPGA project "FPGA_WITH_FUNC_B" and write FPGA code for FPGA bitfile v2. Switching between v1 and v2 is easy enough from the project manager, but for the Host side there's no way of knowing whether Function B is implemented directly in the FPGA or should be "emulated" via Function A as before. If you could do a check like "if FPGA_WITH_FUNC_B == TRUE" you could easily make the Host aware of this.

Regards,

solarsd

View All (1)

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

Configure Memory / FIFOs from Outside FPGA Target Scope

More detailed Xilinx log feedback

Optimized Error-Case with error-code separated cases (see LabVIEW Idea Exchange)

Array to number coercion dot when sign extending

FPGA global variables accesible through Desktop Execution Node

Allow project hosted IO module CLIP

XControls on the FP for interactive debugging

Simple code lock for FPGA targeted VIs

Support Malleable FPGA VIs With the Desktop Execution Node

Ability to save sampling probes

Support for Integrated Logic Analyzer (or similar) in LabVIEW FPGA

Simulation Mode for CLIP

NI 9870/9871 should be used in scan mode while connecting devices with MODBUS

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

Addtional "Interactive" FPGA mode

Easy and small FPGA Simulation helpers

FlexRIO Breakout Extender

Provide VHDL behavioral models of NI standard Flex RIO interface modules

Access FPGA conditional disable symbols from Host VI