Per this document, ap_hs is supported with hls::stream, however we fail to get ack and vld signals on the input and output ports and end up with the following warning:

WARNING: [HLS 207-5530] Unsupported interface port data type in '#pragma HLS interface ap_hs'

Is this expected? ap_hs on hls::streams worked before vitis.

Should there be ap_hs in the StreamMode bool here:

Here's some HLS to reproduce the issue:

#include "hls_stream.h"
#include "ap_int.h"

void user_fifo(
		  hls::stream<ap_uint<32> > & Input_1,
		  hls::stream<ap_uint<32> > & Output_1
		)
{
#pragma HLS INTERFACE ap_hs port=Input_1
#pragma HLS INTERFACE ap_hs port=Output_1
		int i;
		int tmp[2048];
		for (i=0; i<2048; i++)
		{
			tmp[i] = Input_1.read();
		}
		for (i=0; i<2048; i++)
		{
			Output_1.write(tmp[i]);
		}
}

I want to add externel liberaris in HLS, I see you use externel liberaris. I want to know how to do it, I have searched it, however I don't get solutions. Thanks for answering me!!!

Hi,

I am observing unexpected behavior when passing an LLVM IR to Vitis. The synthesis process arrives to the end with no errors, but in the reports everything is zero (0 cycles, 0 DSP, etc). So I traced back in the log to the first pass that is applied to the custom LLVM input, and found this:

INFO: [HLS 200-1022] Running custom LLVM hook 'HLS_HOOKS::opt'
//// get_config commands
INFO-FLOW: Doing LTO.
Execute       ap_eval exec -ignorestderr /opt/Xilinx/Vitis_HLS/2021.1/lnx64/tools/clang-3.9-csynth/bin/clang 
//// rest of the options
-o proj/solution1/.autopilot/db/a.g.lto.bc

Then I disassembled a.g.lto.bc, and it looks like all the input code has disappeared (it was >1800 lines in the LLVM IR):

; ModuleID = 'a.g.lto.bc'
source_filename = "a.g.lto.bc"
target datalayout = "e-m:e-i64:64-i128:128-i256:256-i512:512-i1024:1024-i2048:2048-i4096:4096-n8:16:32:64-S128-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024"
target triple = "fpga64-xilinx-none"

@0 = private unnamed_addr constant [8 x i8] c"ap_auto\00"
@1 = private unnamed_addr constant [1 x i8] zeroinitializer
@2 = private unnamed_addr constant [15 x i8] c"atax_16_kernel\00"

define void @atax_16_kernel(i32* noalias nocapture %arg_2, i32* noalias nocapture %arg_3, i32* noalias %arg_4, i32* noalias nocapture %arg_5) {
bb_0:
  call void (...) @_ssdm_op_SpecTopModule([15 x i8]* @2)
  call void (...) @_ssdm_op_SpecBitsMap(i32* %arg_2), !map !2
  call void (...) @_ssdm_op_SpecInterface(i32* %arg_2, [8 x i8]* @0, i32 0, i32 0, [1 x i8]* @1, i32 0, i32 0, [1 x i8]* @1, [1 x i8]* @1, [1 x i8]* @1, i32 0, i32 0, i32 0, i32 0, [1 x i8]* @1, [1 x i8]* @1)
  call void (...) @_ssdm_op_SpecBitsMap(i32* %arg_3), !map !2
  call void (...) @_ssdm_op_SpecInterface(i32* %arg_3, [8 x i8]* @0, i32 0, i32 0, [1 x i8]* @1, i32 0, i32 0, [1 x i8]* @1, [1 x i8]* @1, [1 x i8]* @1, i32 0, i32 0, i32 0, i32 0, [1 x i8]* @1, [1 x i8]* @1)
  call void (...) @_ssdm_op_SpecBitsMap(i32* %arg_4), !map !2
  call void (...) @_ssdm_op_SpecInterface(i32* %arg_4, [8 x i8]* @0, i32 0, i32 0, [1 x i8]* @1, i32 0, i32 0, [1 x i8]* @1, [1 x i8]* @1, [1 x i8]* @1, i32 0, i32 0, i32 0, i32 0, [1 x i8]* @1, [1 x i8]* @1)
  call void (...) @_ssdm_op_SpecBitsMap(i32* %arg_5), !map !2
  call void (...) @_ssdm_op_SpecInterface(i32* %arg_5, [8 x i8]* @0, i32 0, i32 0, [1 x i8]* @1, i32 0, i32 0, [1 x i8]* @1, [1 x i8]* @1, [1 x i8]* @1, i32 0, i32 0, i32 0, i32 0, [1 x i8]* @1, [1 x i8]* @1)
  store i32 0, i32* %arg_3, align 4
  store i32 0, i32* %arg_2, align 4
  ret void
}

declare void @_ssdm_op_SpecBitsMap(...)

declare void @_ssdm_op_SpecInterface(...)

declare void @_ssdm_op_SpecTopModule(...)

!blackbox_cfg = !{!0}
!llvm.module.flags = !{!1}

!0 = !{}
!1 = !{i32 7, !"reflow.full.lowering", i32 1}
!2 = !{!0}

I am attaching all the code needed to reproduce the issue in atax_issue.zip. I have no clues as to what is happening here, any help is appreciated.

I am thinking of working on a tool that generate a custom HLS front-end which generates HLS-friendly LLVM-bitcode, and leverage plugins + vitis_hls backend for optimization passes and RTL generation.

How can I pass the generated bit files into the HLS compilation flow?

Hi,

I notice even if clang -O0 is selected and no LLVM_CUSTOM_OPT passes are used, Xilinx Vitis applies multiple optimizations when converting the user input llvm IR into a.g.ld.6.user.bc. Can you guide in detail how to turn off all optimizations to note the rtl synthesis of just the input llvm IR (without performance optimizations enforced)?

When I use !stream.full() method as the loop execution condition for a while loop filling this stream, the loop runs infinitely. The code is compiled with g++ as a simple software simulation. Also, it won't end in the Vitis HLS software simulation.
The simple testbench I use is the follows, which never ends:
testbench.cpp:

#include <iostream>
#include "functions.h"

int main(){
    printf("Begin Test Stream Fill");
    hls::stream<int, 16> stm;
    stream_fill(stm);
    printf("Stream Fill Complete\n");

    return 0;
}

functions.h:

#ifndef FUNCTIONS_H
#define FUNCTIONS_H

#include <hls_stream.h>

void stream_fill(hls::stream<int, 16> &stm);

#endif

functions.cpp:

#include "functions.h"

void stream_fill(hls::stream<int, 16>& stm) {
	stm.write(0);
	stm.write(1);

	int i = 2;
	while (!stm.full()) {
		stm.write(i++);
	}
}

Can we use this front-end indenpendently? Such as using the clang tool in the build/bin folder to generate the LLVM IR. With this appraoch I always get an error saying:

/somewhere/HLS/hls-build/bin/clang++: error while loading shared libraries: libsqlite3.28.0.so: cannot open shared object file: No such file or directory

Even if I specify the library directory using -L/somewhere/HLS/ext/sqlite-3.28.0/lib/lnx64/ the error is still there.

Hello,

I am trying to pass llvm bc files to the Vitis front end, but I get an "error: Invalid record".
The only kind of .bc codes I got to work is the LLVM_CUSTOM_OUTPUT file, which set as LLVM_CUSTOM_INPUT file.
However, even if I only use llvm-dis-7 and and then llvm-as-7 to just convert it to LLVM IR and back to .bc formata, the input is not anymore accepted and I get the invalid record error.

As I can't find any documentation regarding this and the error log does not give me more than this one line, I suppose it is a bug or it's something I can't find.

I reduced everything and I am just using the cpp code from the custom llvm example from this repository.
Below you can see my TCL script.

# Open a project and remove any existing data
open_project -reset proj

# Add kernel and testbench
add_files hls_example.cpp
add_files -tb hls_example.cpp

# Tell the top
set_top example

# Open a solution and remove any existing data
open_solution -reset solution1

# Set the target device
set_part "virtex7"

# Create a virtual clock for the current solution
create_clock -period "300MHz"

### The following variables must be set before csynth_design

#set ::LLVM_CUSTOM_OPT [pwd]/../../llvm/hls-build/bin/opt
set ::LLVM_CUSTOM_INPUT [pwd]/test_out1.bc
#set ::LLVM_CUSTOM_OUTPUT [pwd]/test_out1.bc

# This example assumes that the local opt binary has some customized behavior (no custom passes called here)
# Do not use global namespace (::) for variables used in LVM_CUSTOM_CMD
set ::LLVM_CUSTOM_CMD {$LLVM_CUSTOM_OPT $LLVM_CUSTOM_INPUT -o $LLVM_CUSTOM_OUTPUT}

# Compile and runs pre-synthesis C simulation using the provided C test bench
#csim_design

# Synthesize to RTL
csynth_design

# Execute post-synthesis co-simulation of the synthesized RTL with the original C/C++-based test bench
#cosim_design

I am running Vitis 2020.2 on Ubuntu 18.04.
I also tried to work with llvm 9 or other, but the issue remains and I think it should work with llvm 7.

I woulld appreciate any help a lot. Thank you very much!

Hi, we are seeing that when we use a custom pass, there are some optimizations done to the LLVM IR after the custom pass is run. Is there a way in which we can turn off these optimizations so that the LLVM IR that is used for HLS is the direct output of our custom pass? Thanks.

Hi,

I tried a simple experiment to override the opt flow. My only modification to the provided tcl script is the following line

set ::LLVM_CUSTOM_CMD {cp test.bc $LLVM_CUSTOM_OUTPUT}

where test.bc is the LLVM IR I obtained by compiling the input C file with the clang version in Xilinx/Vitis_HLS/2021.1/lnx64/tools/clang-3.9-csynth. So in my mind this substitutes the (compiled) input code with the same (compiled) input code, minus passes/options that Vitis HLS had applied before the custom command.

When I run the script it looks like some Verilog code is generated, but then I get this error:

Problem generating csynth RTL: Missing FE IO mapping file: /.../proj/solution1/.autopilot/db/top-io-fe.xml
    while executing
"source run_hls.tcl"
    invoked from within
"hls::main run_hls.tcl"
    ("uplevel" body line 1)
    invoked from within
"uplevel 1 hls::main {*}$newargs"
    (procedure "hls_proc" line 16)
    invoked from within
"hls_proc [info nameofexecutable] $argv"

I looked into the .autopilot/db logs, and I could not find any reason why my custom command could have prevented the generation of the missing XML file. As I said, I simply substituted the LLVM IR to be synthesized, and I do get a synthesized Verilog file in solution1/syn/verilog, so it looks like I did not disrupt the actual HLS process.

Any ideas?

trmm.ll.zip

When I try to synthesize the attached LLVM IR, Vitis fails with the following error:

ERROR: [SYNCHK 200-43] in function 'trmm_2_kernel': use or assignment of a non-static pointer 'indvars' (this pointer may refer to different memory locations).
ERROR: [SYNCHK 200-41] in function 'trmm_2_kernel': unsupported pointer reinterpretation from type 'i32*' to type '[4 x i32]*' on variable 'indvars'.
INFO: [SYNCHK 200-10] 2 error(s), 0 warning(s).
Command         transform done; error code: 1; 
ERROR: [HLS 200-70] Synthesizability check failed.

There is no 'indvars' in the input IR, so I don't know how to proceed to solve this problem. My setup is the same as in #7 (Vitis HLS 2021.1 and custom compilation flow).

Hi,
I am working on a project with the Xilinx's LLVM frontend. At this point I was testing the generation of LLVM IR with HLS streams. It turns out the compilation with Xilinx's clang fails. The error message says:
clang-7.0: /home/nx08/nx08/s2081362-2/HPE/HLS/hls-llvm-project/clang/lib/CodeGen/CGCall.cpp:2561: void clang::CodeGen::CodeGenFunction::EmitFunctionProlog(const clang::CodeGen::CGFunctionInfo&, llvm::Function*, const clang::CodeGen::FunctionArgList&): Assertion `NumIRArgs == 1 && "AST argument and LLVM IR arg is not one to one mapping, can not handle it "' failed.

I am getting this error even with the minimal example:

#include <hls_stream.h>

void kernel() {
      hls::stream<int> inStream1;
}

This only happens when I enable the option -fhls (which I take it is necessary, as otherwise HLS pragmas are ignored).

The compile command used was:
/home/nx08/nx08/s2081362-2/HPE/HLS/hls-build/bin/clang stream.cpp -c -emit-llvm -I/home/nx08/shared/fpga/xilinx/2021.2/Vitis_HLS/2021.2/include/ -fhls

Is there a documentation describing the specifics of the HLS frontend and how to build on it ?