cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Anonymous
Not applicable
8,659 Views

SDSoC with NEON intrinsics

Jump to solution

I am trying to compile a code with neon intrinsics. I have include arm_neon.h header and using the following compiler options:

-mcpu=cortex-a9 -mfpu=neon -mfloat-abi=softfp

 

However, I get a number of errors regarding types in arm_neon.h file. For instance:

/opt/applics/xilinx-sdsoc-2015.4/SDSoC/2015.4/SDK/2015.4/gnu/arm/lin/lib/gcc/arm-xilinx-linux-gnueabi/4.9.2/include/arm_neon.h:40:9: error: unknown type name '__builtin_neon_qi'

 

What am I missing to use NEON in SDSoC?

1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
15,094 Views
Registered: ‎08-02-2011

Yeah, NEON support in SDSoC is a bit messy right now because of how it's handled by the various compilers called by SDSoC.

 

If your hardware accelerators (or their callers) contain NEON intrinsics, protect them with __SDSCC__ and __SDSVHLS__ macros as described by UG1027.

 

For source files that don't contain hardware accelerators but do use NEON intrinsics, you can either compile them directly using the GNU toolchain and link the objects with sds++ or you can add the sdscc/sds++ command line options -mno-lint and -mdev-no-llvm for these source files. These commands prevent clang-based compiler from being invoked since we know they're not required (i.e. no accelerators). For the latter solution if you're using the GUI, you can apply them on a per-file bases by right-clicking the source file, select 'Properties' and go to the 'Settings' dialog under 'C/C++ Build Settings' -> 'Settings'

www.xilinx.com

View solution in original post

14 Replies
Highlighted
Xilinx Employee
Xilinx Employee
15,095 Views
Registered: ‎08-02-2011

Yeah, NEON support in SDSoC is a bit messy right now because of how it's handled by the various compilers called by SDSoC.

 

If your hardware accelerators (or their callers) contain NEON intrinsics, protect them with __SDSCC__ and __SDSVHLS__ macros as described by UG1027.

 

For source files that don't contain hardware accelerators but do use NEON intrinsics, you can either compile them directly using the GNU toolchain and link the objects with sds++ or you can add the sdscc/sds++ command line options -mno-lint and -mdev-no-llvm for these source files. These commands prevent clang-based compiler from being invoked since we know they're not required (i.e. no accelerators). For the latter solution if you're using the GUI, you can apply them on a per-file bases by right-clicking the source file, select 'Properties' and go to the 'Settings' dialog under 'C/C++ Build Settings' -> 'Settings'

www.xilinx.com

View solution in original post

Highlighted
Anonymous
Not applicable
8,638 Views

Thanks a lot. I separated the neon functions into a separate file and in the properties of this file with neon functions I added -mno-lint and -mdev-no-llvm, as you suggested, and it worked.

 

0 Kudos
Highlighted
Anonymous
Not applicable
8,334 Views

Today I moved to SDSoC 2016.1.  My neon functions are in separate files and there is no neon code in the accelerator. I tried both of your suggestions (separate compilation as well as ) and they worked with SDSoC 2015.4. I was hoping it might be fixed in 2016.1, but to my surprise none of the option is working. Here are the messages when compiling externally:

 

/opt/applics/xilinx-sdsoc-2016.1/SDSoC/2016.1/SDK/2016.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/arm-linux-gnueabihf-g++ -Wall -O3 -I"." -c -fmessage-length=0 -MT"neon_functions.o" -Wno-unused-label -std=c++11 -mcpu=cortex-a9 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -MMD -MP -MF"neon_functions.d" -MT"neon_functions.d" -o "neon_functions.o" "neon_functions.cpp"
In file included from /opt/applics/xilinx-sdsoc-2016.1/SDSoC/2016.1/SDK/2016.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/arm-linux-gnueabihf/libc/usr/include/features.h:402:0,
                 from /opt/applics/xilinx-sdsoc-2016.1/SDSoC/2016.1/SDK/2016.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/arm-linux-gnueabihf/libc/usr/include/stdint.h:25,
                 from /opt/applics/xilinx-sdsoc-2016.1/SDSoC/2016.1/SDK/2016.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/lib/gcc/arm-linux-gnueabihf/4.9.2/include/stdint.h:9,
                 from /opt/applics/xilinx-sdsoc-2016.1/SDSoC/2016.1/SDK/2016.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/lib/gcc/arm-linux-gnueabihf/4.9.2/include/arm_neon.h:38,
                 from neon_functions.cpp:1:
/opt/applics/xilinx-sdsoc-2016.1/SDSoC/2016.1/SDK/2016.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/arm-linux-gnueabihf/libc/usr/include/gnu/stubs.h:7:29: fatal error: gnu/stubs-soft.h: No such file or directory
 # include <gnu/stubs-soft.h>
                             ^
compilation terminated.

 

I see similar error related to stubs even with the first option.

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
8,320 Views
Registered: ‎06-29-2015

Hi,

 

Im assuming that you created a new workspace, new project, and just copied your source files into this new project (in 2016.1). Is this correct?

 

Hopefully you didnt just open the same project/workspace that you created in 2015.4 with the new 2016.1. This will definately not work.

 

Sam

0 Kudos
Highlighted
Anonymous
Not applicable
8,318 Views
I think that might be the reason. I am using the same workspace but created a new project and imported files. I will try it with new workspace and creating this project in the new workspace.
0 Kudos
Highlighted
Anonymous
Not applicable
8,298 Views

Hi there,

 

Here are the steps I performed:

created a new workspace for 2016.1

created a new project in it

imported the source files

My neon functions are in separate files, so added the following flags (as can also be seen from the log below):

-mcpu=cortex-a9 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -mno-lint -mdev-no-llvm

But still no luck. Get the following error same as before.

 

 


Building file: ../src/neon_functions.cpp
Invoking: SDS++ Compiler
sds++ -Wall -O3 -I"../src" -c -fmessage-length=0 -MT"src/neon_functions.o" -Wno-unused-label -mcpu=cortex-a9 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -mno-lint -mdev-no-llvm -MMD -MP -MF"src/neon_functions.d" -MT"src/neon_functions.d" -o "src/neon_functions.o" "../src/neon_functions.cpp" -sds-pf zed
INFO: [SDSoC 0-0] Not running LLVM due to the -mdev-no-llvm switch
INFO: [SDSoC 0-0] Compiling /shares/bulk/iashraf/zedboardWork/sdsocWorkspace2016_1/cannySW/src/neon_functions.cpp
                 from /opt/applics/xilinx-sdsoc-2016.1/SDSoC/2016.1/SDK/2016.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/arm-linux-gnueabihf/libc/usr/include/stdint.h:25,
                 from /opt/applics/xilinx-sdsoc-2016.1/SDSoC/2016.1/SDK/2016.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/lib/gcc/arm-linux-gnueabihf/4.9.2/include/stdint.h:9,
                 from /opt/applics/xilinx-sdsoc-2016.1/SDSoC/2016.1/SDK/2016.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/lib/gcc/arm-linux-gnueabihf/4.9.2/include/arm_neon.h:38,
                 from /shares/bulk/iashraf/zedboardWork/sdsocWorkspace2016_1/cannySW/src/neon_functions.cpp:1:
/opt/applics/xilinx-sdsoc-2016.1/SDSoC/2016.1/SDK/2016.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/arm-linux-gnueabihf/libc/usr/include/gnu/stubs.h:7:29: fatal error: gnu/stubs-soft.h: No such file or directory
 # include <gnu/stubs-soft.h>
                             ^
compilation terminated.
ERROR: [SDSoC 0-0] Exiting sds++ : Error when calling 'arm-linux-gnueabihf-g++ -c -I../src -Wall -O3 -fmessage-length=0 -Wno-unused-label -mcpu=cortex-a9 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -ffast-math -MMD -MP -D __SDSCC__ -MT/shares/bulk/iashraf/zedboardWork/sdsocWorkspace2016_1/cannySW/SDRelease/src/neon_functions.o -MF/shares/bulk/iashraf/zedboardWork/sdsocWorkspace2016_1/cannySW/SDRelease/src/neon_functions.d -MT/shares/bulk/iashraf/zedboardWork/sdsocWorkspace2016_1/cannySW/SDRelease/src/neon_functions.d     -I /opt/applics/xilinx-sdsoc-2016.1/SDSoC/2016.1/aarch32-linux/include  -I /opt/applics/xilinx-sdsoc-2016.1/SDSoC/2016.1/Vivado_HLS/2016.1/include /shares/bulk/iashraf/zedboardWork/sdsocWorkspace2016_1/cannySW/src/neon_functions.cpp -o src/neon_functions.o'
sds++ log file saved as /shares/bulk/iashraf/zedboardWork/sdsocWorkspace2016_1/cannySW/SDRelease/_sds/reports/sds_neon_functions.log

make: *** [src/neon_functions.o] Error 1


 

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
8,279 Views
Registered: ‎11-25-2009

There appears to not be a soft ABI file

SDK/2016.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/arm-linux-gnueabihf/libc/usr/include/gnu/stubs-soft.h

 

However there is a hard ABI file

SDK/2016.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/arm-linux-gnueabihf/libc/usr/include/gnu/stubs-hard.h

 

Have you tried removing the -mfloat-abi=softfp switch from you command line?

 

Also, take a look at the 2016.1 release notes for SDSoC. Page 3 has some information about the ARM toolchain changes. You may need to make adjustments to other compiler switches.

http://www.xilinx.com/support/documentation/sw_manuals/xilinx2016_1/ug1185-sdsoc-release-notes.pdf

 

 

Highlighted
Anonymous
Not applicable
8,265 Views

Hi jece,

 

Indeed that solves the problem.

0 Kudos
Highlighted
Anonymous
Not applicable
8,189 Views

Back again. According to the SDSoC user guide, Performance Estimation should work with any of the build configuration. But if I select this option in 2016.1, I get a lot of errors with neon, like:

INFO: [SDSoC 0-0] Starting performance estimation. This may take a few minutes
/opt/applics/xilinx-sdsoc-2016.1/SDSoC/2016.1/SDK/2016.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/lib/gcc/arm-linux-gnueabihf/4.9.2/include/arm_neon.h:40:9: error: unknown type name '__builtin_neon_qi'
typedef __builtin_neon_qi int8x8_t      __attribute__ ((__vector_size__ (8)));
        ^

The same project builds fine when I dont select performance estimation.

0 Kudos
Highlighted
Observer
Observer
5,895 Views
Registered: ‎05-26-2016

Can you provide your design?

0 Kudos
Highlighted
Anonymous
Not applicable
5,879 Views

Basically any project with neon code. An example attached.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
5,875 Views
Registered: ‎06-29-2015

Hi,

 

As mentioned earlier in this thread, you need to take special care of the code containing neon intrinsics. Just as you pulled the code out into a separate file so that VivadoHLS wouldnt parse the code, you need to compile that file containing neon intrinsics separately from the code you run through sdscc/++ when doing performance estimation. 

 

Performance estimation works by instrumenting your code in various places to gather performance data. This means sdscc/++ must parse your code (in and around the hardware function) to add this instrumentation. Just like VHLS doesnt like neon intrinsics (so you moved it to another file, to avoid that problem), you need to compile the code containing neon intrinsics with the regular arm gcc/g++ compiler separately and link it in manually. This will prevent the source code from being parsed by the sdscc/++ when looking for places to instrument.

 

Obviously this is not an ideal solution, hopefully this will be improved in the future. But at least you can still use performance estimation now if you pre-compile it and link it in manually.


Sam

Highlighted
Anonymous
Not applicable
5,865 Views
Yes, separate compilation of neon code is annoying but works.
0 Kudos
Highlighted
Participant
Participant
480 Views
Registered: ‎09-20-2018

Hello,

I'm sorry that I could not find 'Settings' dialog under 'C/C++ Build Settings' -> 'Settings' for single source file .I want to set compile options for single file  when I use arm_neon header file under SDSoC 2019.1 GUI.

Thanks!

0 Kudos