LabVIEW FPGA Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

Similar to the overflow-status-functionality (which I missused in the picture below) it would be useful to make it possible to include handshaking bit(s) in the signal as well. It is true that this could be implemented using a cluster. However the additional cluster-level will imply a multiplication of type definitions; moreover a built in handshaking-bit-functionality could be included directly in the high-speed math functions an registers, so that a seperate 'output valid' terminal would not be necessary.

HandShaking.png

In real time engineering usualy the clock rate is a parameter which is needed in calculations. Therefore it would be useful to be able to access that rate as integer (or float). It is clear, especially in fpga-programming that the clock (and its rate) is not a variable, that can be chosen by the application user. This idea is rather about code development in order to avoid bugs. In the current situation I am forced to define a seperate constant copying the clock rate; in the course of later code changes I risk to forget to change that constant, when changing the clock.

For the same reason it would be useful to be able to access a clock refernce of an fpga-vi (an with it its rate) form the calling vi.

 

 

FPGAClock.png

Sometimes I just want to compile a lot of Bitfiles (Be it for a release or a debugging test case) and I have to right click each and every Build spec and choose "Build".  then wait about 10 seconds and do the same again for the next build spec.

 

How about being able to select multiple build specs and then select "Build Selection" and have time to go for lunch while the PC queues up all the compilations?

 

I don't use a compile farm and everything is done locally but at least the queuing could be automated.

 

Shane.

When working with CLIP-generated clocks we need to have good UCF files for proper compilation control (Something we now have after WEEKS of debugging Smiley Mad).

 

At the moment the ucf files MUST be in Users\Public\Documents\National Instruments\FlexRIO\IOModules for the code to work even though all other CLIP-relevant files can be located anywhere.

 

Please let us use the ucf file located int he same directory as the CLIP we're using otherwise we'll end up with cross-linking nightmares between users who don't have the right version in their local folder.

 

Shane

The "FPGA I/O Properties" that can be set for an I/O point under an FPGA target consist of just the name for the I/O point.

On the other hand, the "Shared Variable Properties" that can be set for a similar I/O point under a cRIO chassis are much more extensive and include a description field.

I'd like to see a similar description field included/available for the FPGA I/O points. As it is information that is maintained as part of the "project", the reduced functionality normally associated with an FPGA should not be an issue.

 

As long as I'm wishing, it would also be nice to be able to export/import names/descriptions/properties from something akin to the "Multiple Variable Editor" for both "FPGA I/O Properties" and "Shared Variable Properties" and if an I/O module is moved from the FPGA level to the cRIO level or vice versa, allow us to transfer or import the relevant properties from one level to the other.

 

I like rearranging my BD items manually and FPGA items behave weird.

 

If I shift a normal Property node left or right, the "latch point" of the wire is shown below.  For some reason FPGA nodes latch differently and leads to some ugly wiring.

 

FPGA property node latch point.png

 

It's only cosmetic, but please change it....

 

Shane.

In my old post I was suggesting that the default data type should be changed to FXP (Default data type Fixed Point (FXP)). Since in LV2012 the Single Precision (SGL) is supported in FPGA, this should be the standard data type, not Double Precision (DBL).

I just manually transferred a fairly large LabVIEW FPGA project from one target to another (7965R to 7966R).  It would be nice to be able to click on the RIO target in the project and have an option to "Migrate to New FPGA Target" in the context menu.  The menu would open a new dialog where you could select the new RIO target and then it is automatically added to the project and populated the VIs, FIFOs, derived clocks, memory blocks, etc. from the original target.  The user can choose whether or not to delete the original RIO target.

 

This would also make it very easy for users to transfer sample code from the LabVIEW Example Finder to the correct FPGA target (insead of having the folder labeled "Move These Files").

The loop timer express VI is very useful to time a loop to an exact rate, however... if you want to be sure the loop is meeting the rate requested... you also have to put in tic count VIs like this:

 

loop counter fpga.png

 

Since the loop timer express VI already is calculating how long it needs to wait in order to achieve the desired loop time, I would prefer it if at least output a bool that indicated it failed to achieve the timing required.

 

failed timing.png

 

It would be best if it output the actual tics it waited in like I16 form so it could go negative (indicating the # of tics it failed to achieve timing by.

 

counts waited.png

Presently, the Xilinx Compile Tools do not appear in the MAX technical report or NI License Manager. As a result, to determine the version, users must go to Add/Remove Programs in the control panel to determine which versions they have installed. It would be great for troubleshooting if the Xilinx Version could be implemented into the MAX technical report. 

 

In addition, the Compile Worker states that the version of Xilinx used is 12.4, regardless of whether you are using 12.4 or 12.4 SP1. It would be useful for the compile worker to note which version it is using. Specifically, often the compilation chooses the compile tools based on what it was compiled with previously. When upgrading to 12.4 SP1, the user may think the compiler automatically uses the new compile tools and has no visual cue to verify the compile tools version used. 

I have been working with FPGA for quite a while, and realized that manually opening and editing DMA, Target Scoped, P2P, VI scoped Memories, and project scoped memories can be very tedious and time consuming.  Wouldn't it be great if there was a way to edit FPGA FIFOs and Memories from a single place.  This notion gave birth to the FPGA FIFO Editor and FPGA Memory Editor.  These editors would give the ability to see, create, remove, and edit FIFOs or Memories for that specific project (list both project and VI scoped items).  Furthermore, their could be some additional logic built into the Editor that would alert the user when they have tried to configure something incorrectly (for instance an R Series target only has 3 DMA FIFOs, alert the user when they have configured more than that).

 

Listed below is  a mock-up of the FPGA FIFO Editor.

 

FIFO Editor.png

In a FPGA code, when you click in a function (Math, Array or Comparison) to create the first constant, control or indicator, like in an Add function, it's created as a Double (DBL) type, which is not suitable for this target. In this case, it will be better if the data are created as a Fixed Point (FXP). In other cases, like in Array functions, an Integer (I32) may be a better option. One thing is for sure: Should not be a Double!

Typical Xilinx IP core icon like FFT and DDS looks like this - in expanded mode:

Typical Xilinx IP icons in expanded view

The connector labels are very hard to read. I guess everybody agrees on that this could be improved. And it is not that there is a "standard" narrow width to obey, for instance FIFO is wider than the Xilinx IP icons.

Thanks for considering this.

On PC and RT targets, when you right click on a specific property in a property node, you can directly open the help for that property:

 

normal property node.png

 

 

However, on an FPGA target, you can't open the Help for a specific property or method by right clicking:

 

fpganode.png

 

What happens if you click on 'Help'? It takes you to a page that explains the purpose of a property node. Rarely if ever is that what I actually want. Instead, I want to know about 'Linearization Coefficient 1.' My only option is to open up the Help and search for that specific property, which may or may not be easy to find.

 

My suggestion is to add a direct link to the help for every FPGA property and method in the right click menu.

Problem:

Auto-Indexing of LabVIEW is extended to LabVIEW FPGA, only with one small caveat. You can easily auto-index into a loop, but not out of it. You will understand this better if you've already worked with LV FPGA.

In the FPGA paradigm, we enforce compile time resource determinism, by making sure all our arrays are of a fixed pre-determined size. In auto-indexing out of a loop, we may not know what the size of the array is, and hence it breaks the VI with the error "Arrays must be of fixed size". Try to write the following code in LV FPGA, for a better picture:

Auto-Indexing LV FPGA

 

Solution:

The current workaround is that we have a fixed size Array which we then use in and out of the loop, replacing its

elements, as shown below.

 

2.PNG

 

However, an easier and much much more intuitive solution for users would be to just right click the auto-indexed tunnel and set the dimension size.

Auto-Index Pop 

 

This definitely means that the number of data flowing out of the loop could be more than our fixed size. We handle that case by providing the user with the "In case of overflow" option.

4.PNG

 

 

This would ease our effort in coding LV FPGA as much as it would would improve intuitive coding. Vote for this idea if you think it would make your life a tad bit easier.

For some application, I find myself configuring memory blocks for the storage of custom controls which I am maintaining with a type def.  Type definitions normally have the advantage that changing them will update them everywhere they are used.

 

Unfortunately, when I change a type def control for which a memory block has been configured, the memory block does not update this, and my code breaks.  It appears that the memory block disconnects the control from its type def when configured.  It would be nice if the memory block was reconfigured - as this is what I would expect to happen with a type def control.

Working on the FPGA, I use fixed-point precision numbers quite often.  I have grown tired of selecting the FXP representation from the right-click contextual menu (block diagram or front panel), only to then right click again to navigate to the "size" tab to select the configuration.

 

The default configuration is very rarely what I need it to be -- there should be a faster way to change this.

Hi,

 

I realise that parallel for loops don't work on FPGA because they are designed to create multiple threads which FPGAs don't have.

 

However lets take the scenario that I have 8 channels of data to process (scale, filter etc.) but do not have time to do this sequentially due to high loop rates.  Could parallel for loops be a way of doing loop unfolding on FPGA rather than forcing me to have 8 parallel paths of identical code?


Cheers,

LabVIEW FPGA gives users the ability to prototype FPGA code before they even have the hardware. This is incredibly useful. However, this requires you to manually add your controller, chassis, fpga, and C series modules. The process of adding C Series modules could be improved. Currently, you only have the option to add one module at a time. This isn't too difficult if you only have a few modules. However, if you have a full chassis of modules and a few ethercat expansion chassis, this process can be extremely time consuming. It would be nice if you could add multiple modules at the same time like you can with compactDAQ.

 

 

Current

 

Current method of adding C Series Modules. It takes a long time to add each module individually.

 

 

Proposed

 

Current method of adding cdaq modules. You can add all of your modules from one screen.

When setting up a custom VI to use as a simulation test bench, you are currently limited to setting a constant path. If you move your VI, send it to another user, change the name, or otherwise change the path of the custom VI, you must enter the FPGA target settings and modify the path. That is, if you moved the project below from user1's desktop to user2's desktop, you would have to enter the properties and change the location. This makes code sharing somewhat tedious.

psugg.png

Using a relative path or a project item would make this feature easier to use.