Application Acceleration With FPGAs
Programmable Acceleration Cards (PACs), DCP, FPGA AI Suite, Software Stack, and Reference Designs

Local memory banking error

SBioo
Beginner
1,075 Views

I'm trying to apply explicit banking on one of my kernel's local memories, but unfortunately I'll receive a weird LLVM error. Here is the local memory definition, with the banking applied:

 

__local lane_data __attribute__((numbanks(2),bankwidth(64))) win_buffer[2][16]

The lane_data data structure is specified as:

 

typedef struct { DPTYPE data[VEC_SIZE]; } lane_data;

DPTYPE is char and VEC_SIZE is 4. This is the error I get:

 

aocl-opt: /build/swbuild/SJ/nightly/18.1/222/l64/p4/acl/llvm/lib/IR/Instructions.cpp:2565: static llvm::CastInst* llvm::CastInst::Create(llvm::Instruction::CastOps, llvm::Value*, llvm::Type*, const llvm::Twine&, llvm::Instruction*): Assertion `castIsValid(op, S, Ty) && "Invalid cast!"' failed. /home/tools/altera/18.1-pro/hld/llvm/bin/../lib/libLLVM-6.0.so(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x2a)[0x7f3c6224671a] /home/tools/altera/18.1-pro/hld/llvm/bin/../lib/libLLVM-6.0.so(_ZN4llvm3sys17RunSignalHandlersEv+0x3e)[0x7f3c6224445e] /home/tools/altera/18.1-pro/hld/llvm/bin/../lib/libLLVM-6.0.so(+0xb0b804)[0x7f3c62244804] /lib64/libpthread.so.0(+0x39d680f7e0)[0x7f3c6152b7e0] /lib64/libc.so.6(gsignal+0x35)[0x7f3c6099e4f5] /lib64/libc.so.6(abort+0x175)[0x7f3c6099fcd5] /lib64/libc.so.6(+0x39d642b66e)[0x7f3c6099766e] /lib64/libc.so.6(__assert_perror_fail+0x0)[0x7f3c60997730] /home/tools/altera/18.1-pro/hld/llvm/bin/../lib/libLLVM-6.0.so(_ZN4llvm8CastInst6CreateENS_11Instruction7CastOpsEPNS_5ValueEPNS_4TypeERKNS_5TwineEPS1_+0x27f)[0x7f3c6233a38f] /home/tools/altera/18.1-pro/hld/llvm/bin/../lib/libLLVM-6.0.so(+0x1d6791c)[0x7f3c634a091c] /home/tools/altera/18.1-pro/hld/llvm/bin/../lib/libLLVM-6.0.so(+0x1d6bfe1)[0x7f3c634a4fe1] /home/tools/altera/18.1-pro/hld/llvm/bin/../lib/libLLVM-6.0.so(_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE+0x2d8)[0x7f3c6235a6b8] /home/tools/altera/18.1-pro/hld/linux64/bin/../../llvm/bin/aocl-opt(main+0x236b)[0x556abe6e721b] /lib64/libc.so.6(__libc_start_main+0x100)[0x7f3c6098ad20] /home/tools/altera/18.1-pro/hld/linux64/bin/../../llvm/bin/aocl-opt(+0x27fad)[0x556abe6e7fad] Stack dump: 0. Program arguments: /home/tools/altera/18.1-pro/hld/linux64/bin/../../llvm/bin/aocl-opt -march=fpga -O3 -board /home/tools/altera/18.1-pro/hld/board/nalla_pcie/hardware/p385a_sch_ax115/board_spec.xml -libfile /home/user/sbiookag/PipeCNN/project/device/RTL/rtl_lib.aoclib -dbg-info-enabled --soft-elementary-math=false -pass-remarks-output=pass-remarks.yaml conv_pipe_test.fpga.bc -o conv_pipe_test.kwgid.bc 1. Running pass 'Fixup for user specified Memory Attributes' on module 'conv_pipe_test.fpga.bc'. Error: Optimizer FAILED. Refer to conv_pipe_test/conv_pipe_test.log for details.

Anyone has a clue what is going on here? Could it be my local memory data type?

0 Kudos
1 Solution
HRZ
Valued Contributor III
543 Views

This is a compiler crash due to some bug in the compiler; such issues cannot be directly addressed by the programmer. I recommend using the latest version of Quartus (v19.1) if you have a compatible BSP to see if the issue still occurs. If it does, the issue should be passed on to Intel engineers (I guess the forum moderators can do that). Since the fix will likely take a while to be implemented, your only choice in the meantime is likely to modify your code line by line to see which line triggers the crash and then try to come up with an alternative implementation that produces the same kernel behavior without including that line so that the compiler crash is avoided.

View solution in original post

0 Kudos
2 Replies
HRZ
Valued Contributor III
544 Views

This is a compiler crash due to some bug in the compiler; such issues cannot be directly addressed by the programmer. I recommend using the latest version of Quartus (v19.1) if you have a compatible BSP to see if the issue still occurs. If it does, the issue should be passed on to Intel engineers (I guess the forum moderators can do that). Since the fix will likely take a while to be implemented, your only choice in the meantime is likely to modify your code line by line to see which line triggers the crash and then try to come up with an alternative implementation that produces the same kernel behavior without including that line so that the compiler crash is avoided.

0 Kudos
SBioo
Beginner
543 Views

Thanks much for the help. I'll definitely try the new version.

0 Kudos
Reply