cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
e_ensafi
Explorer
Explorer
476 Views
Registered: ‎08-13-2020

AIE - Compilation Fails With Kernel Template Function Using Asyncronous Windows

The attached graph application does not compile due to a template error, if and only if I use asyncrnoush windows.  If you remove "async" from the input port for kernel1 in gmio_test.cpp, the application compiles just fine.  This is a big problem for us because we rely heavily on templates, and we need to start using asynchronous windows.

Please note that this error only occurs in "hw" target mode.  In "x86sim" mode, it compiles just fine.

Lastly, I should add that we have noticed numerous errors related to templates as aiecompiler does its work, but these have been harmless until now.  This particular error is fatal.

0 Kudos
Reply
9 Replies
florentw
Moderator
Moderator
439 Views
Registered: ‎11-09-2015

HI @e_ensafi 

I can reproduce this issue locally. I will report it to the development team.

If you could report the other issues related to templates I can report them to development (I noticed that both using asynchronous window or not creates error during compilation even if this does not crash with synchronous windows)


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
Reply
e_ensafi
Explorer
Explorer
403 Views
Registered: ‎08-13-2020

@florentw The other issue occurs when aiecompiler enters is executed with --kernel-linting and enters the following stage:

INFO: [aiecompiler 77-404] Executing Cmd: kernel_preprocessor

The above is then followed by errors related to user-supplied kernel template functions s as well as redefinitions from Xilinx header files.

The user kernel errors look like this:

/path/to/user/my_kernel.cpp:LINE:1: error: C++ requires a type specifier for all declarations

my_kernel<ARGS, ...>

^

/path/to/Work/temp/my_graph_kernels.cpp:LINE:1: error: template specialization requires 'template<>'

my_kernel<ARGS, ...>

^                 ~~~~~~~~~~~~~~~~~~~

template<> 

error: no variable template matches specialization; did you mean to use 'my_kernel' as function template instead?

error: expected ';' after top level declarator

my_kernel<ARGS, ...>

The errors related to Xilinx header files look like this:

In file included from /tools/Xilinx/Vitis_HLS/2020.2/include/ap_int.h:55:

In file included from /tools/Xilinx/Vitis_HLS/2020.2/include/ap_common.h:646:

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:1427:18: error: class member cannot be redeclared

  INLINE ValType get_VAL(void) const volatile { return VAL; }

                 ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:1426:18: note: previous definition is here

  INLINE ValType get_VAL(void) const { return VAL; }

                 ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:1466:18: error: class member cannot be redeclared

  INLINE ValType get_pVal(int i) const volatile { return VAL; }

                 ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:1461:18: note: previous definition is here

  INLINE ValType get_pVal(int i) const { return VAL; }

                 ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:1467:20: error: functions that differ only in their return type cannot be overloaded

  INLINE uint64_t* get_pVal() const volatile {

         ~~~~~~~~~ ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:1462:26: note: previous definition is here

  INLINE const uint64_t* get_pVal() const {

               ~~~~~~~~~ ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:1483:29: error: class member cannot be redeclared

  ap_private<_AP_W, _AP_S>& operator=(

                            ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:1476:29: note: previous definition is here

  ap_private<_AP_W, _AP_S>& operator=(const ap_private<_AP_W1, _AP_S1>& RHS) {

                            ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:1496:15: error: functions that differ only in their return type cannot be overloaded

  ap_private& operator=(const ap_private& RHS) {

  ~~~~~~~~~~~ ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:1490:8: note: previous definition is here

  void operator=(const ap_private& RHS) volatile {

  ~~~~ ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:1503:8: error: class member cannot be redeclared

  void operator=(const volatile ap_private& RHS) volatile {

       ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:1490:8: note: previous definition is here

  void operator=(const ap_private& RHS) volatile {

       ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:1509:15: error: functions that differ only in their return type cannot be overloaded

  ap_private& operator=(const volatile ap_private& RHS) {

  ~~~~~~~~~~~ ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:1490:8: note: previous definition is here

  void operator=(const ap_private& RHS) volatile {

  ~~~~ ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:1719:10: error: constructor cannot be redeclared

  INLINE ap_private(const volatile ap_private<_AP_W1, _AP_S1, _AP_OPT>& that)

         ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:1711:10: note: previous definition is here

  INLINE ap_private(const ap_private<_AP_W1, _AP_S1, _AP_OPT>& that)

         ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:3280:19: error: class member cannot be redeclared

  INLINE uint64_t get_VAL(void) const volatile { return pVal[0]; }

                  ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:3279:19: note: previous definition is here

  INLINE uint64_t get_VAL(void) const { return pVal[0]; }

                  ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:3288:20: error: functions that differ only in their return type cannot be overloaded

  INLINE uint64_t* get_pVal() const volatile { return pVal; }

         ~~~~~~~~~ ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:3286:26: note: previous definition is here

  INLINE const uint64_t* get_pVal() const { return pVal; }

               ~~~~~~~~~ ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:3289:19: error: class member cannot be redeclared

  INLINE uint64_t get_pVal(int index) const volatile { return pVal[index]; }

                  ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:3287:19: note: previous definition is here

  INLINE uint64_t get_pVal(int index) const { return pVal[index]; }

                  ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:3394:10: error: constructor cannot be redeclared

  INLINE ap_private(const volatile ap_private<_AP_W1, _AP_S1, false>& that) {

         ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:3387:10: note: previous definition is here

  INLINE ap_private(const ap_private<_AP_W1, _AP_S1, false>& that) {

         ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:3420:10: error: constructor cannot be redeclared

  INLINE ap_private(const volatile ap_private<_AP_W1, _AP_S1, true>& that) {

         ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:3401:10: note: previous definition is here

  INLINE ap_private(const ap_private<_AP_W1, _AP_S1, true>& that) {

         ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:4706:22: error: class member cannot be redeclared

  INLINE ap_private& operator=(const volatile ap_private& RHS) {

                     ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:4701:22: note: previous definition is here

  INLINE ap_private& operator=(const ap_private& RHS) {

                     ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:4712:15: error: functions that differ only in their return type cannot be overloaded

  INLINE void operator=(const ap_private& RHS) volatile {

         ~~~~ ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:4701:22: note: previous definition is here

  INLINE ap_private& operator=(const ap_private& RHS) {

         ~~~~~~~~~~~ ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:4717:15: error: functions that differ only in their return type cannot be overloaded

  INLINE void operator=(const volatile ap_private& RHS) volatile {

         ~~~~ ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:4701:22: note: previous definition is here

  INLINE ap_private& operator=(const ap_private& RHS) {

         ~~~~~~~~~~~ ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:4734:22: error: class member cannot be redeclared

  INLINE ap_private& operator=(const volatile ap_private<_AP_W1, _AP_S1>& RHS) {

                     ^

/tools/Xilinx/Vitis_HLS/2020.2/include/etc/ap_private.h:4724:22: note: previous definition is here

  INLINE ap_private& operator=(const ap_private<_AP_W1, _AP_S1>& RHS) {

                     ^

The above is more of a nuisance than anything else because compilation continues after the aforementioned errors.

Are you sure that you managed to create a compile-time failure using synchronous windows?  If I simply remove "async" from the port connection in gmio_test.h, it compiles all the way through.  However, to make it run without deadlocking, you also need to remove the window_acquire/release lines from kernel1.cpp.  The only failure I have ever encountered is when a kernel using templates has one or more input/output ports designated as "async" in the graph.  

What's a true showstopper is the compilation failure associated with templates and asynchronous windows.  Without major changes to my application, I cannot get rid of templates, so I am stuck.  I really need to try out asynchronous windows to see if my current deadlock situation with streams can be resolved.

0 Kudos
Reply
e_ensafi
Explorer
Explorer
415 Views
Registered: ‎08-13-2020

@florentw Are you sure about synchronous windows casing an error? If you simply remove "async" from gmio_test.h and recompile, aiecompiler completes successfully. Of course, to make it run with deadlocking, you need to remove window_acquire/remove from kernel1.cpp.

The other issues have to do with enabling --kernel-linting.  You will see numerous errors if you add this option to aiecompiler, both from the kernel template functions and from Xilinx include files where multiple redefinitions are reported during the "kernel_processor" stage.  These kernel linting template errors do not cause the compiler to fail, but they look like failures, which more of a nuisance than anything.

0 Kudos
Reply
florentw
Moderator
Moderator
367 Views
Registered: ‎11-09-2015

Hi @e_ensafi 

The error I am mentioning with synchronous window is the one you also mentioned with kernel-linting:

/path/to/user/my_kernel.cpp:LINE:1: error: C++ requires a type specifier for all declarations

my_kernel<ARGS, ...>

^

/path/to/Work/temp/my_graph_kernels.cpp:LINE:1: error: template specialization requires 'template<>'

my_kernel<ARGS, ...>

I can build the application successfully. So I think we are on the same page.

For the errors related to HLS kernels, the kernel-linting option should probably not look into those kernels. So this needs to be an improvement for later (I will do some test and report this to the development team but this might not be high priority)


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
Reply
florentw
Moderator
Moderator
258 Views
Registered: ‎11-09-2015

Hi @e_ensafi 

Were you able to test the patch I sent you? Can you confirm it fixes the issue? 


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
Reply
e_ensafi
Explorer
Explorer
249 Views
Registered: ‎08-13-2020

@florentw I have been busy dealing with a bigger problem, which is the stalling issue. We had to press forward over the last couple of weeks, so we got rid of all templates and used C++ class kernels instead with static const member variables instead of template parameters (not quite the same, but it got the job done).  I will test it soon!

0 Kudos
Reply
e_ensafi
Explorer
Explorer
179 Views
Registered: ‎08-13-2020

@florentw The patch appears to have fixed the problem, but there was one small issue: the executable aieir_be did not have execute permission once unzipped, so I had to perform a chmod a+x on it (and also on the *.so file for good measure, although not strictly necessary).

0 Kudos
Reply
florentw
Moderator
Moderator
135 Views
Registered: ‎11-09-2015

HI @e_ensafi 

Thanks for the feedback. This might depend on the environmnent as I did not have to change the permission rights on my RHEL machine.


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
Reply
e_ensafi
Explorer
Explorer
122 Views
Registered: ‎08-13-2020

@florentw Perhaps, but in most environments unless your filesystem is doing something unconventional, the files will not have execute permission on a Red Hat system (see below) or any Linux system for that matter. Not even umask can force the execute bit, but some remote NAS filesystems running Samba may set execute based on the FAT "archive" permission.

% lsb_release -d

Description: Red Hat Enterprise Linux Server release 7.9 (Maipo)

% unzip -Z AR76155_Vitis_2020_2_rev1.zip 

Archive:  AR76155_Vitis_2020_2_rev1.zip

Zip file size: 5245809 bytes, number of entries: 8

drwx---     2.0 fat        0 b- stor 21-Feb-09 09:29 AietoolsPatch/bin/

drwx---     2.0 fat        0 b- stor 21-Feb-09 08:57 AietoolsPatch/bin/unwrapped/

drwx---     2.0 fat        0 b- stor 21-Feb-09 09:26 AietoolsPatch/bin/unwrapped/lnx64.o/

-rw-a--     2.0 fat  6708888 b- defN 21-Feb-09 08:58 AietoolsPatch/bin/unwrapped/lnx64.o/aieir_be

drwx---     2.0 fat        0 b- stor 21-Feb-09 06:36 AietoolsPatch/lib/

drwx---     2.0 fat        0 b- stor 21-Feb-09 08:41 AietoolsPatch/lib/lnx64.o/

-rw-a--     2.0 fat  7137944 b- defN 21-Feb-09 08:52 AietoolsPatch/lib/lnx64.o/libmeir_backend.so

-rw-a--     2.0 fat     4834 t- defN 21-Feb-11 09:24 Readme.txt

8 files, 13851666 bytes uncompressed, 5244731 bytes compressed:  62.1%

% unzip AR76155_Vitis_2020_2_rev1.zip 

Archive:  AR76155_Vitis_2020_2_rev1.zip

   creating: AietoolsPatch/bin/

   creating: AietoolsPatch/bin/unwrapped/

   creating: AietoolsPatch/bin/unwrapped/lnx64.o/

  inflating: AietoolsPatch/bin/unwrapped/lnx64.o/aieir_be  

   creating: AietoolsPatch/lib/

   creating: AietoolsPatch/lib/lnx64.o/

  inflating: AietoolsPatch/lib/lnx64.o/libmeir_backend.so  

  inflating: Readme.txt              

% ls -l AietoolsPatch/bin/unwrapped/lnx64.o/

total 6584

-rw-r--r-- 1 user staff 6708888 Feb  9 08:58 aieir_be

%