LabVIEW
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:
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
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.
@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.
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.
