I'm currently looking for a way to read out the FPGA version number from the FPGA.
All I found was a way to parse the *.lvbitx, but that's not what I want.
Are there any plans to store the version number in a FPGA register to be read out at runtime?
The FPGA compilation results should be copied to a file in the folder with the bitfile. This is needed to track the history of compilation results, especially useful when using source code control. Right now they get overwritten with each recompile.
Adding a Post-build action VI to the FPGA build spec, would also enable something like this.
It would be nice if the sbRIO targets supported the DMA Acquire Write Region (and Acquire Read Region, although maybe that's already supported - I only tried Write Region since that's what I need for my application). Failing that, perhaps the documentation could mention that those methods are not supported on all targets?
We have a "group" of occurrences. We can't identity individual occurrencs easily because you can't store them in an array (where we would use indexes to identify). When using a cluster they all get the same name (labels aren't used!) which is bug-prone. The only workaround is to create a control cluster, and that's not a clean solution.
As far as I can tell, method and property nodes don't support some of the inputs I need. For example, I'd like to create a subVI to configure the terminal mode of my 9205 inputs. The idea is to decouple the node from the specific resource.
Old Way in LabVIEW 2012
Hi, since there an be a queue for compiling FPGA code, it seems natural to me to also be able to make a queue for generating intermediate files.
I'm working with 10 build specs. for compilation per project and generating intermediate files for my design takes aprox. 3-4 minutes. This means that I need to sit by my computer for half an hour just waiting and clicking build on every build specification. Sometimes I work with FPGA VI which need to build intermediate files for something like 7-10 minutes, so this is a pain.
It would be great if there was a way of just highlighting all build specifications for compilation with shift and just creating the intermediate files for them automatically one by one.
Can this be done?
Idea: New NI FPGA module with:
Something like Papilio Pro.
Reason: As ATE manufacture sometimes we need small FPGA to do something inside ATE or ITA (interface test adaptor). To use sbRIO/myRIO is to big (complexity,price). Because we use TestStand and LabVIEW out knowledge of VHDL is small.
We could learn VHDL but after that we could stop to use LabVIEW FPGA! :-)
I'd like the Select node to provide an Invert bubble on the Select Terminal, similar to how the Compound Arithmetic node allows the developer to invert any input. I don't like crossing wires.
Select Node with crossed wires in 2012: Select Node without crossed wires in future release (optional invert shown):
Keep your Invert node comments to yourself
Currently, LabVIEW does not have the functionality to save the settings of the modules (e.g. cRIO module channel names) so it can be imported into another target. The only option is to copy and paste. This functionality would speed things up significantly when moving from one target (e.g. cRIO-9074) to another (e.g. cRIO-9076) with the same modules or most of the same modules.
I would like to access class attributes of my FPGA class hierarchy with property nodes. I prefer the property node API over VIs for data member access because it allows you to grab properties from across the hierarchy in a single node. This leads to a (much) cleaner block diagram and expedites development. For example in the screenshot below, the FXP attributes belong to the NI_9205 class, while the "_OP" attributes belong to the parent. I don't care about the Invoke node API over a subVI, because the wiring work and diagram appearance are about the same IMHO.
As the compilation goes on of the LabVIEW FPGA code to bitfile, there is an intermediary step when a VHDL file (or maybe Verilog?) is generated. This file would be very beneficial if you want to use another FPGA target, that NI supports. I know that this VHDL file cannot be directly used for non supported FPGA, but it would be a very good starting point for the ones that know VHDL language.
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.
We need to have more FPGA Vision example codes. I followed NI introductory articles on image processing using FPGA and they sound great, but was very much disappointed when trying to find usable examples as there are only 5 examples on the IPNet, far fewer than what the intro articles suggest what FPGA can do.
Currently when you build a VI the bit file path is stored as relative (you can see it in the project XML). This means if you change the project location either:
You have to recompile the FPGA to use VI mode or run interactively. It seems the bitfile could be stored as a relative path like all VIs in the projects.
Per NI Applications Engineering, "If you intend to run multiple compiles in parallel on the [Linux] server then yes, you will need the Compile Farm Toolkit running on a Windows machine to handle the parallel workers." I would like NI to support the FPGA Compile Farm Toolkit on Linux, so I don't need a dedicated Windows server to outsource compiles to workers.
In current versions of LabVIEW FPGA, placing a For Loop inside an SCTL will result in code that cannot be compiled; this is because conventially For Loops work iteratively and therefore require multiple clock signals to drive each new iteration.
However, I think a logical implementation of a For Loop within an SCTL would be the generation of multiple parallelised instances of whatever code is inside the For Loop. This would greatly improve readability and flexibility by avoiding the user having to manually create multiple separate instances of the same critical code on the Block Diagram.
This would require the For Loop to execute a known maximum number of times.
I am currently running into this issue where I have some constant data I'm trying to write to some DO lines. I want this data to be a constant array on my block diagram, so I create the array programmatically under the "my computer" target. I then change the indicator that is populated to a constant and move it to the FPGA. When I right click and set the array to be a fixed size, it replaces all my data with 0's. I propose the data should not be cleared if I set my fixed array size to be equal to the size which the array already is.
I am Muhammad Was,
an AE from NIJ.
While choosing FPGA variable, We should have sorted variable list for FPGA Read/Write Control option as we have in shared variable list that is always sorted and from A to Z.
In FPGA Read/Write Control option, variable added lately in FPGA VI, get higher position than old ones in the list.
Its voice of one of our FPGA customer.
Thanks and regards,
Make DRAM on sbRIO expandable on new and legacy sbRIOs. Add USB for connectivity, add more I/O expansion for 0-3, 0-5 and 0- 24 VDC.
sbRIO is pricey even for quantities. 35% profit margin should be fine.
When I build a new bitfile for my project, I sometimes (shock horror) make mistakes and bring the whole house of cards crashing down.
In situations like that, I would love to have the last version of the bitfile available for re-testing. Ideally, I could specify a pre- and post-build option for my compilation where I can define my own automatic re-naming and archiving scheme so that I no longer need to do painful re-compiles for reverting my code.
I am aware that this probably applies to more than FPGA but here the compilationt imes are more prohibitive and I feel the need is larger.