LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How many control and indicators are too much for an FPGA VI

Solved!
Go to solution

Hi,

 

I have an FPGA VI that reads various style quadrature encoders and calculating their various parameters which leads me to a total of 64 (15 controls and 49 indicators). I do not wish have so many controls and indicator on FPGA for efficiency and aesthetic reasons. Post testing, I am thinking of building an array of similar data types and translate boolean to numbers and then send to RT using a FIFO.

 

But I am wondering if this would make a difference in efficiency or will it be the same? Also, the subject of post, am I hurting FPGA with this many FP objects. I vaguely remember reading that the Read/Control Method on RT side with too many items, consumes a lot of RT resources.

 

 

 

 

0 Kudos
Message 1 of 11
(1,492 Views)
Solution
Accepted by XM43

I would not expect an improvement.  The amount of controls/indicators on an FPGA that compromise on performance is not documented due to all of the variables involved.

 

Grouping into arrays or clusters will add coherence.  That is, when you read/write, they will be from/to the same clock cycle.

 

The FPGA side should be okay.  Sometimes a feedback node can be put after/before the control/indicator on the FPGA to help with timing compile issues.


Certified LabVIEW Architect, Certified Professional Instructor
ALE Consultants

Introduction to LabVIEW FPGA for RF, Radar, and Electronic Warfare Applications
Message 2 of 11
(1,479 Views)

Thank you Terry, I know you are well versed in FPGA so I will take your response as solution to this post.

0 Kudos
Message 3 of 11
(1,464 Views)

An FPGA does not have an UI. Can you explain what you are doing in more detail?

0 Kudos
Message 4 of 11
(1,431 Views)

@altenbach wrote:

An FPGA does not have an UI. Can you explain what you are doing in more detail?


The question has to do with https://www.ni.com/docs/en-US/bundle/labview-fpga-module/page/lvfpgaconcepts/pfi_data_transfer.html

 


Certified LabVIEW Architect, Certified Professional Instructor
ALE Consultants

Introduction to LabVIEW FPGA for RF, Radar, and Electronic Warfare Applications
0 Kudos
Message 5 of 11
(1,423 Views)

Hi altenbach,

 

Question was about interactive front panel communication and read/write control function as Terry_ALE mentioned. Does the question make more sense now?

0 Kudos
Message 6 of 11
(1,382 Views)

@altenbach wrote:

An FPGA does not have an UI. Can you explain what you are doing in more detail?


Interactive mode testing on the FPGA. In this case, the FPGA VI does indeed have a UI.

It's a very useful tool in testing FPGA code sometimes.

0 Kudos
Message 7 of 11
(1,350 Views)

@XM43 wrote:

Hi,

 

I have an FPGA VI that reads various style quadrature encoders and calculating their various parameters which leads me to a total of 64 (15 controls and 49 indicators). I do not wish have so many controls and indicator on FPGA for efficiency and aesthetic reasons. Post testing, I am thinking of building an array of similar data types and translate boolean to numbers and then send to RT using a FIFO.

 

But I am wondering if this would make a difference in efficiency or will it be the same? Also, the subject of post, am I hurting FPGA with this many FP objects. I vaguely remember reading that the Read/Control Method on RT side with too many items, consumes a lot of RT resources.

 


There are some additional issues which may or may not be of interest:

 

AFAIK, the actual implementation of reading / writing the registers instantiated for the FP controls (internally, we don't actually see these directly) are in the default board clock domain. Reading or writing the FP controls in another clock domain will incur some buffering, typically 2-3 times the bit width and leads to the "registers" actually being implemented as "handshake" items instead.

 

Not a lot we can do to change this, but the resource cost of the FP controls can end up being higher than expected from the raw register count. It can end up being more efficient to group smaller controls into clusters to reduce the handshake overhead. 32x individual Booleans with clock domain crossing cost more fabric (~150) than a single 32-bit number (~36) due to the 4-wire handshake registers required for the clock domain crossing.

Message 8 of 11
(1,343 Views)

Thank you Intaris! What you said is somewhere along the lines of what I remembered reading but forgot where I had read it. I do rarely read/controls in loops with different clock cycle so I will keep your suggestion in mind.

 

I appreciate your input. 🙂

0 Kudos
Message 9 of 11
(1,326 Views)

I also found that once you get a decent number of controls, the selecting of these controls, is a real pain, and is error prone.  That's why I made an idea on the Idea Exchange to have some kind of better solution.

 

Do note that I linked to a post where a grouping through naming does exist and is undocumented.

 

https://forums.ni.com/t5/LabVIEW/Group-FPGA-Controls-With-Dot-Naming/m-p/2772208#M816334

 

Message 10 of 11
(1,247 Views)