FPGA Compile error - Actual of formal out port cout cannot be an expression

Question

Details:
ERROR:HDLCompiler:192 - "C:\NIFPGA\jobs\BPO5kq2_O6tyN2U\OC4_Sine_Cosine_LUT_Constant_Amplitude_dash_optimised_vi_c.vhd" Line 1408: Actual of formal out port cout cannot be an expression
ERROR:HDLCompiler:854 - "C:\NIFPGA\jobs\BPO5kq2_O6tyN2U\OC4_Sine_Cosine_LUT_Constant_Amplitude_dash_optimised_vi_c.vhd" Line 69: Unit <vhdl_labview> ignored due to previous errors.
VHDL file C:\NIFPGA\jobs\BPO5kq2_O6tyN2U\OC4_Sine_Cosine_LUT_Constant_Amplitude_dash_optimised_vi_c.vhd ignored due to errors
-->
The compilation gets to the "Estimated device utilisation" stage but then stops shortly after with a compilation error.
The Line in question (1408) relates to the output of a "Reinterpret FXP" node with the text
cOut => (others => '0'),
in the port map portion of the code.  This corresponds to the output of the FXP reinterpret node being directly connected to an indicator in a sub VI whose output is then input directly to a high thoughput multiply node.  The code is part of a sinus cosinus LUT I have programmed.  It used to compile no problem but I think I know where the problem is.  In one instance I only utilise the Sinus output of the algorithm and theoretically, Xilinx can optimise away the Cosinus part.  I have two instances of this VI in my code and looking at the one NOT generating errors, the output is associated with a Cosinus indicator.
cOut => s_Cosine_2434,
It would seem that the pathway is essentially optimised away but the Xilinx compiler has a problem with the indicator being present on the sub-VI but the idnicator not being utilised anywhere.  As such, the cOut gets set to an invalid value.  I assume the immediate proximity of the FXP Reinterpret to the output of the sub-VI is an important aspect of this problem.
I think I know enough now to fix this problem (manually remove the path by duplicating the sub-vi) but this is perhaps a useful feedback for future bugfixes in the FPGA module.  This isn't the first time this kind of incorrect code removal has given me problems but it's the first time I've been able to clearly locate the problem.
Shane
Say hello to my little friend.
RFC 2323 FHE-Compliant
Solved!
Go to Solution.

Answer 1

I am currently attempting a compile after changing some things.
Just a side question.  Is this particular to the Reinterpret node or are other "pink nodes" also affected by this?  If I don't connect the output of a high throughput add, will it result in the same behaviour?
PS OK, it seems to be compiling now.  I managed to juggle around the nodes a bit in my sub-VI to make sure the "reinterpret" is not the last node before the indicator.  It seems to be compiling now.  A question which is in my head at this time is: Does the "reinterpret" node prevent anything before it from being optimised away by the Xilinx compiler?  Are there other nodes which cannot be removed, even if the outputs are not being used?  This would immediately seem to suggest to me that such nodes need to be as close to the source as possible in order to reduce the amount of code which cannot be removed as "dead code" during the Xilinx compile process.
Say hello to my little friend.
RFC 2323 FHE-Compliant