LabVIEW FPGA Idea Exchange

Post an idea

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.

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.

View All (1)

Currently, in LabVIEW you can right click a VI's icon at the top right of the front panel to find all instances including where the VI is referenced in a static reference node. Also, when you use have a "Open FPGA VI Reference" in "build specification" or "VI" mode, you can double click the node to open the referenced block diagram. Once the FPGA front panel is open, there's no easy way to get back up to the caller. It would be cool if we could extend the right-click-find-all functionality so that when you right clicked a top level FPGA VI, it would search where that VI was referenced in any "Open FPGA VI Reference" nodes. Currently, when you right click and search, it just says no instances found.

Addtional "Interactive" FPGA mode

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.

View All (3)

Intermediate file generation in parallel

Please give us FXP-based enums

When instantiating case structures, the bit width of the selector has an influence on the efficiency of the code being produced. Of course various compiler optimisations will (may?) do a lot of this lifting for us if we actually wire in an FXP (which LabVIEW again tries to coerce to I32, but that's another battle) but I'd like to have the ability to create, use and convert to and from enums with variable bit-widths. Of course the only parameter of importance for this is the width of the FXP, the integer bits become essentially irrelevant.

I currently have to do a lot of U8 Enum FXP conversions in order to be able to force my case structures to adapt to a given width when supplying an enum to control some code. Readability would benefit greatly if the enum itself could "simply" be an FXT to begin with.

Derived clock instantiation

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.

DMA Channel instantiation

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 first, why can't we define a DMA channel in the code? When parsing the code before compiling, the presence of a DMA channel can be autodetected and added to the interface for the Bitfile.

To try to decouple my code from static DMAs, I actually have started defining my core FPGA VIs as accepting FIFOs with Write functions (For DMAs to host) or Read functions (for writing to FPGA) required. I can then, without having to change my project, wrap this FPGA VI in another VI which can then input wither a DMA channel (which unfortunately must be defined in the project) or a standard FIFO which cen then be used for debugging.

Please allow for the instantiation of DMA channels in code.

When I use a FPGA Read/Write control to set a state from Windows to the FPGA target, I would like to be able to search for all the places where that is done. If I do a search-Text for the FPGA Read/Write control variable names used to set the state, they are not found. The work-around suggestion from NI was "to include the text that you are looking for with each instance of the control, one way to accomplish this could be to label the wires going into or out of each terminal with the name of the control." This would work, but it would be better in a future LabVIEW version to have the search function be able to find the variable names.

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.

Relative Paths for Xilinx IP

When using the Xilinx IP nodes in LabVIEW FPGA it becomes very difficult to support source code control and branching. The biggest issue is the fact that the "Folder for Support Files" entry is absolute. So when we need to branch the code to isolate new feature development from the main trunk the relative path is now wrong. Please make this and all other paths relative to support a more robust development environment.

This is the current situation when dealing with register creation on FPGA targets:

This is what I would like:

I am currently creating a group of classes to abstract out inter-loop communication and the ONLY thing changing between classes (aside from variations between Ragister vs FIFO vs Global and so on) is the datatype. Being able to link the Register creation to a data input (the data value of the class itself for example) would save a lot of work in such operations. If it were also possible to do the same for the Register stored within the class private data then implementing different classes int his way would be really easy.

Even without classes, the ability to autoadapt the type of registers / FIFOs in this way would be a real step towards re-usable code on FPGA.

Improvements for Continuous Integration

Proper unit testing is a key component of large LVFPGA project success. As the number of modules grows, so does the number of units tests increase. We are working on automatic continuous integration methods that will continue to monitor the accuracy of all modules and assemblies throughout the project life cycle. IP Integration node and NI's wrapper around Xilinx IP makes this task more difficult. When our continuous integration machine refreshes the source code from the repository it has to regenerate these nodes in order to compile. The "Regenerate IP Integration Node Support Files..." tool does not always properly update all IP. It seems like the NI wrappers around Xilinx IP are most problematic. The only way a computer can properly update its version of the node is to open the VI and click through the Xilinx IP generation pages to get it to update.

As a rule we do not commit build products into our source code repository. One option would be to submit all the support files generated when first creating the IP integration node so that others users might not have to update. This can become messy and quickly unwielding. The problem arrises when changes to the IP integration node cause more or fewer support files to be generated. This then requires deleting some files from the repository and adding others which is tedious and leads to errors. One compromise would be if the IP integration created one single compact file that contains all the information needed (expect the input vhd, etc. files) that could be committed to the repository. Even better would be to roll this information into the VI itself. Neither of these might be ideal if the support file contents take up a lot of disk space.

Regardless there needs to be a better solution to allow for automated continuous integration testing.

View All (4)

Better FPGA FP Control Selection

When there are many controls on the front panel of the FPGA, selecting the control from a Read/Write Control node in the host can become a pain. It is one very large list of controls on the front panel of the FPGA. This list has no scrollbar, no browse, or search feature, and no obvious way of grouping controls.

Here is one example of a front panel, and a video showing how long it takes to scroll through the list of contorls.

And here is the video of me scrolling through the controls: http://screencast.com/t/PLzptTwq58aw

There is plenty of room for improvement. Here are just a few ways I think NI could make this better.

Browse and Search

When using a Property Node, or Invoke Node, the very top option is to "Browse..." From here a list of all properties, or methods can be seen in a resizeable window. Here you can also search, and sort alphabetically. The Read/Write Control node could have similar functionality making selection of controls easier.

Front Panel Selection From FPGA

There could be an option for creating a node by selecting the controls on the front panel of the FPGA. A solution that may work today, is to select the controls, then invoke a custom QuickDrop command that creates the node and puts it in the clipboard so it can be pasted in the host VI. If this were to become an option, I'd hope there is a way to combine two nodes into one, by concatenating the controls of one onto the other.

Front Panel Selection From Host

Lets say you already have the Read/Write Control node on the host. There could be an option by right clicking that would open a new window, showing a static image of the front panel of the FPGA, which the user could then click on. This would be great because the developer probably already knows the control they want based on the front panel location. I don't know how possible this is because you could load a bit file which won't have any front panel information.

Easier Grouping of Controls

Right now there is a way to group controls of an FPGA. This feature is never talked about, and doesn't work on dynamic bit files. Here is a discussion where I describe the steps to make controls grouped on the host. Still this isn't supported on all FPGA setups, and you have to conform to a specific naming convention. Why can't controls that are grouped on the front panel, just be grouped in the host?

This idea exchange is really for any kind of improvement to the FPGA control selection.

LabVIEW FPGA Idea Exchange

Selecting between two I/O refnums not allowed

Conditional Disable options for Front Panels of FPGA VIs

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

Extend right click find all instances functionality to finding where the FPGA VI is opened

Addtional "Interactive" FPGA mode

Display max clock rate that can be achieved during development itself

Remove Stacked Sequence Structure from the FPGA palette

Make FPGA Registers searchable and Quick dropable

Intermediate file generation in parallel

Please give us FXP-based enums

Derived clock instantiation

DMA Channel instantiation

FPGA Read/Write Control name search

Easy and small FPGA Simulation helpers

FPGA global variables accesible through Desktop Execution Node

Relative Paths for Xilinx IP

Ability to define datatype of Registers / FIFOs from code (without needing the configuration dialog)

Improvements for Continuous Integration

Better FPGA FP Control Selection