LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Sorting FPGA I/O registers from RT target point of view.

hello! I'm working on a FPGA. I have more and more IO registers and when I select them in the RT device, I get this:

 

problemes fpga quantité de variable non classables.png

Registers are put from the oldest ot the newest, and it's a complete mess. finding the good ones represents for me a loss of time during the development.

 

Is there an option/a key to rearrange them as I want, like the clusters ordering options?

 

regards

Pierre FCentum TNS, Grenoble
Certified LabVIEW Associated Developer
0 Kudos
Message 1 of 7
(1,052 Views)

I think the listing is the same as the Tab order on the FPGA's Front Panel.  You can set the Tab Order by going to Edit, Set Tabbing Order.  Note that the default is, in fact, newest to oldest, but once the Front Panel (and Controls/Indicatore) is/are defined, you can make a list of them all, arrange the list in the order you'd like to see it (say, alphabetical, or in the order they appear on the Front Panel after you move them around as you like them, and start setting the Tab order by clicking on #0, #1, #2, ... (#0 means the first in the list, which is called "0" in terms of the Tab Order, #1 means the second, etc.).

 

Bob Schor

0 Kudos
Message 2 of 7
(1,033 Views)

Just to confirm: Yes the tab order of the controls in your FPGA Main front panel is also determining the order of the items in the exported register map that you access with the IO property node.

 

You may also want to think about some strategies to reduce the number of elements on the front panel. If there are closely related controls of the same type you can put them in a fixed size array, if they have different types you can put them in a cluster. However you should avoid combining things that you need to be able to update independently as you would need to implement some extra mechanism to avoid potential race conditions if you only need to set some of the elements sometimes.

 

Also front panel controls are a nice way to access data incidentally, such as control settings or monitor items, but they are accessed asynchronously by the host so you have no way to know if and when it was updated, it simply is there. If you need more synchronized data transfer and//or high speed data throughput you definitely should look into using FIFOs.

Rolf Kalbermatter
My Blog
0 Kudos
Message 3 of 7
(1,019 Views)

Hi! thanks for your replies.

 

-I confirm tabbing order sort them, but not in an optimal way: controls inside tab controls remains unsorted in the list

 

-I didn't know it was possible to use arrays as controls/indicators by using "set size" option. good advice 🙂

 

-what about clusters/arrays front panel indicators regarding memory resources compared to simple controls and indicators? is it worth it? 

 

thanks!

 

 

Pierre FCentum TNS, Grenoble
Certified LabVIEW Associated Developer
0 Kudos
Message 4 of 7
(1,010 Views)

@Pierre_F wrote:

 

-what about clusters/arrays front panel indicators regarding memory resources compared to simple controls and indicators? is it worth it? 


There might be a small FPGA fabric overhead in accessing more complex variable types but most of what you see on the diagram as overhead (unbundle or index array for instance) can be pretty much optimized away by the FPGA compiler. For the FPGA fabric all controls are located in a register map that is accessed by an offset to the individual control. A control inside a cluster or in an array when accessed with a constant offset is still at a register map address that can be determined at compile time and is therefore not different than an individual control. There might be a little extra overhead for synchronization of larger items (the FPGA compiler makes sure that the host can't read or write to a control while it is updated through the FPGA to avoid inconsistent data) but unless you are straining your fabric at near 100% utilization, you are unlikely to notice the slight difference.

Rolf Kalbermatter
My Blog
0 Kudos
Message 5 of 7
(1,003 Views)

@rolfk  a écrit :

but unless you are straining your fabric at near 100% utilization, you are unlikely to notice the slight difference.

Almost! I'm currently at ~ 90% in a Crio-9047😁

Do you think this little difference can become a problem?

Pierre FCentum TNS, Grenoble
Certified LabVIEW Associated Developer
0 Kudos
Message 6 of 7
(998 Views)

It's as in the saying "The proof of the pudding is in the eating". Try it out and see what difference it makes! And don't worry about changes behind the comma. They tell you nothing as the entire compilation for FPGA isn't always completely deterministic. I have frequently small changes in fabric usage and even timing constraints between multiple compilations without having made any material changes to the FPGA VIs. There seems to be a certain variation in layout strategies that is not only triggered by the VI code itself.

Rolf Kalbermatter
My Blog
0 Kudos
Message 7 of 7
(988 Views)