Array implicit casting between FPGA and RT

[hsw9797]

Above picture is in RT VI and Speaker is IRQ that is data sending to FPGA 

data type of element of Speaker is FXP 24-4 word length and int word length respectly.

i made array using four zero and one data that is converted to FXP 24-4 and four zero is also 24-4.

but there is  implicit casting point. 

i also tried comparing between constant of Speaker and Array i made. but i didn't find any difference.

Thank you

[raphschru]

Hi hsw9797,

The difference is subtle, but the data types are indeed different: PC and RT use variable-sized arrays by default, while FPGAs exclusively use fixed-size arrays. So while the array you build is of type "1-D array", the FPGA control is of type "1-D fixed-size array [5]", hence the coercion dot. Regardless of the size of the input array, it will be converted to a 5-element array when fed into the FPGA node (by adding zeros or removing excess elements if needed).

In case the coercion dot is bothering, you have 2 solutions:

1. Simply insert a "Coerce to type" in between your array and the FPGA node, with a type constant directly created from the FPGA write terminal. However it will not tell you if the size is different from 5:

2. More complicated but enforces strict array size to the developer: check the hidden property "autopreallocate arrays and strings" in the VI properties and add a type assertion that will break the VI in case the array is not exactly of the right type:

See the example attached.

[hsw9797]

Thank you for your reply. 

but i'am using Labview 2017... i didn't find same thing... how can i do same work at Labview 2017? Thank you

[N_743]

Sorry to jump in the middle but since it is related, would the coercion dot affect performance in this case?

I have an inherited code from some NI alliance partners and they did not resolve these coercion dots for arrays going to FPGA. So far there has been no known issue, thus wondering if it matters much to resolve them. (just in this case).

[raphschru · Accepted solution]

I've tried with LV2016, apparently the "Coerce to Type" function was not accessible through the quick drop back then.

This is the same for "Assert Structural Type Match" since malleable VIs were added in LV2018.

So in LV2017 to make the coercion dot disappear, choose solution 2, but without the assert structural type match.

Also as N_743 asked about memory, be aware that if a cercion dot causes a buffer allocation, replacing it with an explicit conversion (like with "Coerce to Type") won't change anything, you are just shifting the buffer allocation.

By checking "autopreallocate arrays and strings", you immediately build a fixed-size array, removing the need the convert and reallocate it later.

I've also converted the example to LV2016 for solution 2: