UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Observer alexkroh
Observer
391 Views
Registered: ‎04-25-2015

HW/SW cosimulation on Zynq fails for -m32

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.

Any advice?

0 Kudos
4 Replies
Explorer
Explorer
359 Views
Registered: ‎07-18-2018

Re: HW/SW cosimulation on Zynq fails for -m32

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?

 

0 Kudos
Observer alexkroh
Observer
350 Views
Registered: ‎04-25-2015

Re: HW/SW cosimulation on Zynq fails for -m32

Hi evant_nq,

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.

0 Kudos
Explorer
Explorer
320 Views
Registered: ‎07-18-2018

Re: HW/SW cosimulation on Zynq fails for -m32

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.

 

0 Kudos
Observer alexkroh
Observer
313 Views
Registered: ‎04-25-2015

Re: HW/SW cosimulation on Zynq fails for -m32

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 ;)

0 Kudos