Better FPGA FP Control Selection

[Hooovahh]

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.

[thoult]

To which I'd add that any method that avoids using clusters is preferred.

As I understand, using a cluster to do something similar can result in a lock, as well as performance hits on FPGA (utilisation) and host (flattening requirements).

The dot naming is a good start, and has proven useful so far, but since coming across your original post and forwarding it to as many FPGA users as I can, I've never seen anyone else use it or talk about it, so a level of documentation would be ideal.

[Hooovahh]

Yes just to clear something up.  A member of LabVIEW R&D who was part of the FPGA group, once told me that having arrays and clusters which cumilitivly take up more than 32 bits is very expensive in terms of gates on the FPGA.  So in other words having a cluster which contains 2 U16s is fine, but a cluster with 2 U16s and a boolean would take up much more space than having three separate controls on the front panel.  So my point is that organizing controls into clusters is not a good solution.  BTW this same engineer is the one that showed me the dot notation grouping trick years ago.

[nanocyte]

Maybe I should spin out a new idea but one thing to consider is that maybe there should be an option for the cluster/array that indicates if you need the whole indicator to be updated synchronously or if it's OK if it's OK if different elements of the cluster update at different times. I believe that would give you the performance of loose elements with the grouping of clusters.

[nturley]

---

---

---

arrays and clusters which cumilitivly take up more than 32 bits is very expensive in terms of gates on the FPGA

Not only does it use more FPGA space, it also prevents the driver from memory mapping it to usermode, so access latency is quite a bit higher. On Zynq, I've seen about a 5x increase. It might be less on faster CPUs.

---

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

Have you tried advanced session resources? I'm curious if those are better or worse for what you are trying to do.

[Hooovahh]

Recently someone from NI was asking about this feature request.  I originally posted a video demonstrating the challenges with an FPGA with lots of controls but the video got lost with flash.  So here it is again on Youtube.  I no longer have the ability to edit this idea that was posted so long ago, but if I could I would use this think.

https://www.youtube.com/watch?v=0AfgAmEtXf8

This was from a real project at the time.  Scrolling through all of the controls on the host took several seconds.  And this had to be done every time a property node needed to read or write to a control.  This was also very error prone since the control names needed to not be too long but needed to be distinct which usually resulted in many controls looking very similar.

[Terry_ALE]

---

@Hooovahh wrote:

Recently someone from NI was asking about this feature request.  I originally posted a video demonstrating the challenges with an FPGA with lots of controls but the video got lost with flash.  So here it is again on Youtube.  I no longer have the ability to edit this idea that was posted so long ago, but if I could I would use this think.

https://www.youtube.com/watch?v=0AfgAmEtXf8

This was from a real project at the time.  Scrolling through all of the controls on the host took several seconds.  And this had to be done every time a property node needed to read or write to a control.  This was also very error prone since the control names needed to not be too long but needed to be distinct which usually resulted in many controls looking very similar.

I agree with the idea request.

The above could benefit from grouping of controls into clusters but also Instruction Framework https://forums.ni.com/t5/NI-Labs-Toolkits/Instruction-Framework-Tutorial/ta-p/3533500