02-03-2019 11:19 PM
I'm trying to set up a co-sim environment to speed up my productivity.
I have co-sim working in my project, but I am building for a 32bit ARM platform and hence need to add -m32 to the CFLAGS. Once I do this, co-sim reports an error:
Build using "/opt/Xilinx/Vivado/2018.3/tps/lnx64/gcc-6.2.0/bin/g++" Compiling apatb_my_top_function.cpp Compiling (apcc) kernel.c_pre.c.tb.c WARNING: /opt/Xilinx/Vivado/2018.3/tps/lnx32/jre9.0.4 does not exist. ERROR: Could not find 32-bit executable. ERROR: /opt/Xilinx/Vivado/2018.3/bin/unwrapped/lnx32.o/apcc does not exist ERROR: -m32 switch is not supported. cosim.tv.mk:72: recipe for target 'obj/kernel.c_pre.c.tb.o' failed
Strangely, both C-sim and synthesis works fine with these flags.
02-04-2019 02:50 PM
Why does the HLS module need to be run with the -m32 flag for HW cosimulation? Is the HLS code intended to be run on the zync cores for validation of the RTL functionality?
It's possible the other stages worked with the flag becuase it was ingored?
02-04-2019 03:30 PM
Hmm.. You are right, it looks like the -m32 flag is ignored for C simulation (tested by reporting sizeof(int/long)). However, it is not ignored for Synthesis (tested by providing ports of type int and long and examining their width).
The fundamental problem is that my kernels don't use fixed sized data types, such as int32 and int64, and I would like to avoid modifying the kernels.
I use -m32 for synthesis to ensure that the size of HW data types match the size of SW data types (SW will eventually run on the 32-bit ARM CPUs).
So I must use -m32 for co-sim to ensure that simulated SW data types match that of the synthesised RTL.
02-05-2019 12:47 PM
Is there a reason you can't use the ap_int<> types to have a speicifc size?
or uint32_t or similar?
I synth'd and quickly simulated with uint32_t and it appeared to have no issue.
02-05-2019 02:12 PM
As a workaround, that is definitely an option.
But I have a number of kernels that span multiple files and functions and I'd like to avoid the effort of finding/replacing all uses of signed/unsigned int/long. There is also the chance that I might miss one and need to invest time in debugging.
I'd also like to avoid modifying the kernel code itself. The kernels are from the CHStone benchmark and the more I modify them, the less they become the CHStone kernels.
Ideally, the SW portion of the project would be emulated for ARM architecture using QEMU... But one problem at a time ;)