LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

iSim Target Results in HDLCompiler Errors

LabVIEW 2011 w/FPGA Module, Xilinx 12.4, targeting PXIe-7965R board. I'm attempting to build a project with proprietary component level-IP (i.e. existing VHDL) to iSim for some debugging.

 

Fact 1: Project when not targeting real HW builds fine and runs as expected on the real board except for a minor problem.


Fact 2: When targeting iSim HDLCompiler fails. LabView reports the the overused internal error code -61499 which can have many causes. No, the existing knowledge base articles do not apply. Fuse log shows the HDLCompile errors.

 

Error -61499 occurred at niFpgaSimulate_FinalizeForISim.vi<-niFpgaSimulate_InitializeDirectories.vi<-niFpgaSimulate_Worker.vi<-niFpgaGenerateCode_Worker.vi

 

ERROR:HDLCompiler:410 - "../niFpga/../niFpga/NiFpgaAG_00000017_TimedLoopDiagram.vhd" Line 223: Expression has 1 elements ; expected 48

 

When examing the officially non-existent generated VHDL it appears LabVIEW is getting confused with the IP node outputs. Signals are declared correctly per original IP.

signal s_IP_bksl_ip_data_out_174 : std_logic_vector(47 downto 0);

signal s_IP_bksl_disc_out_1647 : std_logic_vector(0 downto 0);

 

However they are used with incorrect functions - s_IP_bksl_disc_out_1647 is not 48 bits wide.

s_IP_bksl_disc_out_1647_unflattened <= to_tUnsFxp48_48(s_IP_bksl_disc_out_1647);
s_IP_bksl_ip_data_out_174_unflattened <= to_tUnsFxp4_4(s_IP_bksl_ip_data_out_174)

 

LabView when using outputs from IP seems to be hazardly treating and swapping outputs around without respect to signal type, size, etc. This only affects iSim for me. Would have expected

s_IP_bksl_ip_data_out_174_unflattened <= to_tUnsFxp48_48(s_IP_bksl_ip_data_out_174)

 

This seems like a VHDL generator problem in the FPGA module.

 

 

0 Kudos
Message 1 of 2
(2,351 Views)

For those that wondering (probably very few) I found a workaround. Moving my 48 bit wide CLIP output to the top of the FPGA I/O node on the block diagram fixes the problem. It appears this a bug dealing with order of a CLIP output in a node and how the VHDL is generated.

 

Correction to fact 1 is generated VHDL works fine and builds to real HW.

0 Kudos
Message 2 of 2
(2,281 Views)