Error: Missing FE IO mapping file

[SerenaC94]

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?

[hcneema]

1. with no " set ::LLVM_CUSTOM_CMD " : does the flow work ok ?
2. With the " set ::LLVM_CUSTOM_CMD " Does the csynth finished message get printed ? The message should look something like " Finished Command csynth ". The xml file should be generated if csynth_design finishes ok. If csynth_design doesnt finish ok then there is something in test.bc that is causing an issue and will need to be looked into furthur.

[SerenaC94]

Without the custom command the flow works. With the custom command as above, here are some relevant messages from the log:

INFO: [HLS 200-111] Finished Generating all RTL models: CPU user time: 0.18 seconds. CPU system time: 0.02 seconds. Elapsed time: 0.23 seconds; current allocated memory: 331.102 MB.
INFO-FLOW: Done: create_csynth_xml read xml data time: 0 seconds per iteration
INFO-FLOW: Done: create_csynth_xml bind info time: 0 seconds per iteration
INFO-FLOW: Done: create_csynth_xml config info time: 0 seconds per iteration
INFO-FLOW: Done: create_csynth_xml write xml time: 0 seconds per iteration
INFO-FLOW: DBG:PUTS:       create_csynth_xml wrote csynth_xml=proj/solution1/syn/report/csynth.xml
INFO-FLOW: DBG:PROC: ::AP::DESIGN_DATA::generate_json generate_bd_files='0' generate_xo_files='0' modelList='example_fadd_32ns_32ns_32_11_full_dsp_1
example
' rtl_lang='both' bootstrap_tcl='false' outdir='' outfilename=''
Execute       source proj/solution1/.autopilot/db/global.setting.tcl 
Execute       source proj/solution1/.autopilot/db/global.setting.tcl 
Execute       get_solution -flow_target 
Execute       get_config_export -xo 
Execute       get_config_export -format 
INFO-FLOW: DBG:PUTS:       auto_generate_csynth_design error: Missing FE IO mapping file: proj/solution1/.autopilot/db/top-io-fe.xml

So csynth_design is not finished maybe? The RTL models were definitely generated though.

I do want to know what the problem is in test.bc, otherwise I will never be able to use this flow ;)
The command I used to generate it was:

/opt/Xilinx/Vitis_HLS/2021.1/lnx64/tools/clang-3.9-csynth/bin/clang -fno-limit-debug-info -fhls -flto -fno-exceptions -Wno-error=c++11-narrowing test.c -fno-math-errno -c -emit-llvm -mllvm -disable-llvm-optzns -Werror=implicit-function-declaration -Werror=implicit-hls-streams -Werror=return-type -Wpragmas -Wunused-parameter -std=gnu99 -fgnu89-inline -target fpga64-xilinx-linux-gnu -D__VITIS_HLS__ -DAESL_SYN -D__SYNTHESIS__ -D__HLS_SYN__ -D__DSP48E1__ -g -o test.bc -hls-platform-db-name=/opt/Xilinx/Vitis_HLS/2021.1/common/technology/xilinx/common/platform.db -hls-platform-name=virtex7_medium

[hcneema]

Hello, could you please :

1. confirm that the Xilinx/AMD provided example (which uses LLVM_CUSTOM_CMD) works for you ? To note: one of the provided examples has this kind of usage
2. confirm for your testcase that ./proj/solution1/.autopilot/db/top-io-fe.xml indeed does not exist.

After this we can begin triaging the issue - please prepare the smallest possible testcase (test.c / tcl file/other test files)

[SerenaC94]

The example provided in https://github.com/Xilinx/HLS/tree/main/vitis_hls_examples/override_opt_flow_demo works correctly.

./proj/solution1/.autopilot/db/top-io-fe.xml does not exist.

I am attaching an archive containing the input C code, tcl script, and a README with the command I used to generate the LLVM IR.
bug-report.zip

[yu810226]

Hello @SerenaC94 ,
What you were trying out on the test.bc is probably not the same as the input bc for the LTO command in full flow csynth. You may want to look into if the top function in the kernel file source is corrected marked or not. Else your test.bc might miss the top function attribute, and this would lead to missing top-io-fe.xml error. You could either improve your kernel file source code to mark the top function, or have a pass for adding top function attribute to your top function at llvm level.

Tips to debug this is to look into the autopilot.flow.log in the full flow csynth, and see the difference between your compiled source and the input of "Source preprocessing" command on the kernel. The other way is to compare your generated $LLVM_CUSTOM_OUTPUT and the input of "LTO" command.

If you don't mind sharing, I would like to know more on the intention of this experiment. Is this an exercise on exploring more the open source flow? Or are you trying to achieve other things in mind? Thanks!

[SerenaC94]

Ok thanks for the pointer! I inspected the intermediate IRs generated during csynth, and found "fpga.top.func"="dot_16_kernel" in the top function attributes, I probably need to add at least this, and probably also other attributes, to my LLVM IR.

I am experimenting because I want to know what are the requirements to synthesize an LLVM IR with vitis, in order to use later a frontend that produces LLVM IRs.