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

[Intaris]

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

[Intaris]

For info. Just sticking a shift register between the FXP reinterpret and the output terminal allows the compilation to continue.  I'd file this one under "bug".

[T-REX$ · Accepted solution]

Hey Shane,

Looks like someone filed a bug report on this one a month or so ago; it's CAR# 475397 if you wanna check for it in the bug fix list for 2014 SP1.

[Intaris]

Oh, cool. Thanks.  Will check.

[Intaris]

Hmm, spoke too soon.  Adding the shift register didn't actually allow the compilation to complete.

[T-REX$]

From what I understand, the problem is that the indicator isn't being used in all cases(I haven't seen your block diagram). How deeply nested is this in your code? The workaround we currently have listed is to "always wire a control to the output of the Reinterpret Node up to the top-level VI in all cases especially when a case structure is followed".

This could be pretty painfull for you depending on where this is happening in your code... but it might not be.

If this is holding you up, and you need something better than that to continue, I can try to find some time to look for additional workarounds.

[Intaris]

There's a pretty easy workaround I can think of.  Just replicate the sub-VI and remove the offending (unused) code from one version.  That's going to be my avenue of attack today.

Thanks for the offer though.  If I don't get the problem sorted early today I'll get back to you on that.

Shane.

[Intaris]

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.

[T-REX$]

Hey Shane,

I can confirm that it's just the FXP Reinterpret Node, at least, as far as we know. It's a bug in the VHDL generation for this node.

[Intaris]

Ok, thanks for the clarification.  At least now I won't be paranoid every time I drop a pink node....