记录Vitis-HLS、AIE开发过程中遇到的问题和解决方案。
一、环境
1.1 VSCode
在使用VSCode的Remote-SSH插件连接到Server时,使用SSH密钥登录,需将remote端的.ssh/和.ssh/authroized_keys文件夹权限设置为700和600,否则会出现无法连接的问题。
1.2 Vitis HLS
使用以下pragma
捆绑 函数实参到 单个 MAXI端口时,单个接口可同时读写,但仅限于单一位置。如果需要多个位置的读写,需要使用多个接口(此时可提升吞吐量和带宽)。
1
2
|
#pragma HLS INTERFACE m_axi port=in0 offset=slave bundle=<string>
#pragma HLS INTERFACE s_axilite port=in0
|
二、HLS 问题
2.1 顶层ap_uint<>* 输入数据存在0值
host输入数据的int类型到PL的ap_uint,带符号数转换出错。
解决方案
2.2 loop调度次序问题
如下代码中,首次进入loop时,从波形观察到反常:第一,0x5发送完成后,紧接着发送了0x15,SEND_MUL_INNER_LOOP直接被跳过了;第二,在一个SEND_MUL_MID_LOOP结束后,理应发送当前loop的0x15以及下一个loop的0x5,然而波形上呈现的是0x5、0x15。
可以猜测,HLS工具将0x15的write操作移动到了SEND_MUL_INNER_LOOP的最开始,从而造成了上述的两种现象。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
SEND_MUL_OUTER_LOOP:
for (int n = 0; n < r_A_nnz; n++)
{
d_int_t val_a = vec_va_row_strm.read();
d_int_t nnz_rb = nnz_B_strm.read();
d_uint_t nnz_rb_aligned = (nnz_rb + VEC_SIZE - 1) / VEC_SIZE;
PKT_TYPE_64 pkt_header = genPkt(header, 0, 0xf, 0);
PKT_TYPE_64 pkt_val_a = genPkt(header, val_a, -1, 1);
PKT_TYPE_64 pkt_nnz_rb = genPkt(header, nnz_rb_aligned, -1, 1);
out_tuple.write(pkt_val_a); // no.4
out_tuple_ack.write((ap_uint<8>)(1 << 2 | 0b01)); // 0x5
out_val.write(pkt_nnz_rb);
out_val_ack.write((ap_uint<8>)(1 << 2 | 0b01));
SEND_MUL_MID_LOOP:
for (int i = 0; i < nnz_rb_aligned; i++)
{
out_tuple.write(pkt_header);
out_val.write(pkt_header);
SEND_MUL_INNER_LOOP:
int j;
for (j = 0; j < VEC_SIZE / 2; j++)
{
#pragma HLS dataflow
bypassPkt(vec_hash_row_strm, out_tuple, j == LAST_IDX);
bypassPkt(vec_vb_row_strm, out_val, j == LAST_IDX);
}
if(j==4){
out_tuple_ack.write((ap_uint<8>)((VEC_SIZE / 2 + 1) << 2 | 0b01)); // 0x15
out_val_ack.write((ap_uint<8>)((VEC_SIZE / 2 + 1) << 2 | 0b01));
}
}
} // end loop
out_tuple_ack.write((ap_uint<8>)0b11); // 0x3
out_val_ack.write((ap_uint<8>)0b11);
|
解决方案
- ❌ 使用
_ssdm_op_Wait()
等待for结束,保证顺序正确
- ❌ 将 PLIO_Accessor 中的 while-loop 改成 for-loop
- ❌ 将 sender 的 loop-boundary 设为
VEC_SIZE/2 + 1
- ❌ 将 PLIO_Accessor 中的 if-else condition 改为 if-if condition,并用使用
_ssdm_op_Wait()
控制 if 语句的串行执行顺序
- ❌
SEND_MUL_INNER_LOOP
内部的dataflow是不是应该不包含 if
或 ==
等条件判断?尝试直接展开for循环
- ❌ 对内层循环进行
loop_flatten
- ✔️ 手动展开最内层循环(规避dataflow的for循环内存在有条件执行的任务):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
SEND_MUL_MID_LOOP:
for (int i = 0; i < nnz_rb_aligned; i++)
{
out_tuple.write(pkt_header);
out_val.write(pkt_header);
BYPASS_PKT_0:
sendPkt(vec_hash_row_strm, vec_vb_row_strm, out_tuple, out_val, 0);
BYPASS_PKT_1:
sendPkt(vec_hash_row_strm, vec_vb_row_strm, out_tuple, out_val, 0);
BYPASS_PKT_2:
sendPkt(vec_hash_row_strm, vec_vb_row_strm, out_tuple, out_val, 0);
BYPASS_PKT_3:
sendPkt(vec_hash_row_strm, vec_vb_row_strm, out_tuple, out_val, 1);
out_tuple_ack.write((ap_uint<8>)((VEC_SIZE / 2 + 1) << 2 | 0b01)); // 0x15
out_val_ack.write((ap_uint<8>)((VEC_SIZE / 2 + 1) << 2 | 0b01));
} // end loop
|
2.3 DATAFLOW pragma 的使用
在起初看UG1399文档时,以为Scope内加 DATAFLOW
pragma 即可让工具对 Scope 内部的代码实现硬件并行化,在实际操作中遇到诸多问题,可以将其 DATAFLOW
的使用条件总结为:
- 只能应用于循环内部或函数内部
- 所应用的Scope内不能存在有条件执行任务(如
if
、==
等)
- 被
DATAFLOW
修饰的Scope内部任务,对相同资源不能存在多生产者或多消费者
- (以及 UG1399 中所述的 4 种情形)
2.4 function 下不同的slave端口接受到的信号一样
多次修改rcvPkt函数后发现,当ipc-receiver收到某一个sender的0x3结束信号后,所有ipc-receiver都offline了,故猜测是否所有rcvPkt都复用了相同的RTL硬件,从而不同sender间无法并行,进而导致ipc-receiver的外层loop被stall。
解决方案
- 取消复用row_process function
- 将其模板化,从而例化到独立的RTL硬件
- 将参数ROW_IDX作为常量实参传入,使用 pragma
FUNCTION_INSTANTIATE
使其例化到不同的独立RTL硬件
- 使用
func
2.3 BRAM 未按pragma分区
accu_ori
和 accu_rcv
均为16256的数组。使用 #pragma HLS ARRAY_PARTITION variable=accu_ori complete N=1
对这两个数组进行分区,从而实现它们在第一维度的并行读写。
然而在综合后发现,accu_ori
数组被正确地分为了16块长度为25632bit的BRAM,而 accu_rcv
数组却被分成了128块长度为32*32bit的BRAM,这显然与预期不符。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
|
* Memory:
+----------------------+-------------------------------------+---------+---+----+-----+------+-----+------+-------------+
| Memory | Module | BRAM_18K| FF| LUT| URAM| Words| Bits| Banks| W*Bits*Banks|
+----------------------+-------------------------------------+---------+---+----+-----+------+-----+------+-------------+
|accu_ori_U |accu_ori_RAM_T2P_BRAM_0R0W | 1| 0| 0| 0| 256| 32| 1| 8192|
|accu_ori_1_U |accu_ori_RAM_T2P_BRAM_0R0W | 1| 0| 0| 0| 256| 32| 1| 8192|
|accu_ori_2_U |accu_ori_RAM_T2P_BRAM_0R0W | 1| 0| 0| 0| 256| 32| 1| 8192|
|accu_ori_3_U |accu_ori_RAM_T2P_BRAM_0R0W | 1| 0| 0| 0| 256| 32| 1| 8192|
|accu_ori_4_U |accu_ori_RAM_T2P_BRAM_0R0W | 1| 0| 0| 0| 256| 32| 1| 8192|
|accu_ori_5_U |accu_ori_RAM_T2P_BRAM_0R0W | 1| 0| 0| 0| 256| 32| 1| 8192|
|accu_ori_6_U |accu_ori_RAM_T2P_BRAM_0R0W | 1| 0| 0| 0| 256| 32| 1| 8192|
|accu_ori_7_U |accu_ori_RAM_T2P_BRAM_0R0W | 1| 0| 0| 0| 256| 32| 1| 8192|
|accu_ori_8_U |accu_ori_RAM_T2P_BRAM_0R0W | 1| 0| 0| 0| 256| 32| 1| 8192|
|accu_ori_9_U |accu_ori_RAM_T2P_BRAM_0R0W | 1| 0| 0| 0| 256| 32| 1| 8192|
|accu_ori_10_U |accu_ori_RAM_T2P_BRAM_0R0W | 1| 0| 0| 0| 256| 32| 1| 8192|
|accu_ori_11_U |accu_ori_RAM_T2P_BRAM_0R0W | 1| 0| 0| 0| 256| 32| 1| 8192|
|accu_ori_12_U |accu_ori_RAM_T2P_BRAM_0R0W | 1| 0| 0| 0| 256| 32| 1| 8192|
|accu_ori_13_U |accu_ori_RAM_T2P_BRAM_0R0W | 1| 0| 0| 0| 256| 32| 1| 8192|
|accu_ori_14_U |accu_ori_RAM_T2P_BRAM_0R0W | 1| 0| 0| 0| 256| 32| 1| 8192|
|accu_ori_15_U |accu_ori_RAM_T2P_BRAM_0R0W | 1| 0| 0| 0| 256| 32| 1| 8192|
|accu_rcv_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_1_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_2_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_3_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_4_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_5_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_6_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_7_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_8_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_9_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_10_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_11_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_12_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_13_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_14_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_15_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_16_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_17_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_18_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_19_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_20_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_21_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_22_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_23_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_24_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_25_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_26_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_27_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_28_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_29_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_30_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_31_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_32_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_33_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_34_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_35_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_36_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_37_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|accu_rcv_38_U |accu_rcv_RAM_T2P_BRAM_1R1W | 1| 0| 0| 0| 32| 32| 1| 1024|
|... |... | ...|...| ...| ...| ...| ...| ...| ...|
+----------------------+-------------------------------------+---------+---+----+-----+------+-----+------+-------------+
|
解决方案
通过Vivado一系列观察后发现,是由于调用了 accu_rcv
的函数中对其读写进行了pipeline操作(手动加了 #pragma HLS pipeline
),工具为了降低 II
,自动将分区调整至128块,从而导致了上述问题。
因此,只需移除对分区错误的存储器相关pipeline编译指示。
三、AIE 问题
3.1 hw_emu 无法使用darts
hw_emu 仿真期间,Vivado会随机crash(qumu内部),qumu内执行exe之前,tcl输出日志中已出现下述报错:
1
2
3
4
|
WRN : -2 : me[::.vitis_design_wrapper_sim_wrapper.vitis_design_wrapper_i.vitis_design_i.ai_engine_0.inst.aie_logical.aie_xtlm.math_engine.array.tile_25_3.cm.proc.iss] : Disassemble command used: darts -c /xxxx/src/Work/aie/25_2/Release/25_2 me -o /xxxx/src/Work/aie/25_2/Release/25_2.cmic2_140523469783056 -D__tct_tgt__=230622 +F : checkers_Disassemble_Elf32File
ERR : 21 : me[::.vitis_design_wrapper_sim_wrapper.vitis_design_wrapper_i.vitis_design_i.ai_engine_0.inst.aie_logical.aie_xtlm.math_engine.array.tile_25_3.cm.proc.iss] : Disassembling of ASIPElf_file failed: '/xxxx/src/Work/aie/25_2/Release/25_2' : checkers_Disassemble_Elf32File
ERR : 21 : me[::.vitis_design_wrapper_sim_wrapper.vitis_design_wrapper_i.vitis_design_i.ai_engine_0.inst.aie_logical.aie_xtlm.math_engine.array.tile_25_3.cm.proc.iss] : Call to 'run_darts' failed : checkers_Disassemble_Elf32File
ERR : 21 : me[::.vitis_design_wrapper_sim_wrapper.vitis_design_wrapper_i.vitis_design_i.ai_engine_0.inst.aie_logical.aie_xtlm.math_engine.array.tile_25_3.cm.proc.iss] : Call to checkers_Disassemble_Elf32File ended with errors : loadprogram (elf)
|
当仿真执行到某一阶段后(正常仿真),Vivado会crash,无法继续仿真与重启,报错如下:
simulation.log
1
2
3
|
FATAL_ERROR: File /wrk/wall1/workspaces/wall859/sub/REL/2023.2/src/products/simmodels/systemc/protected/aie_cluster_msm/aie_cluster_v1_0_0/sc/msm_math_engine.cpp, line 510: in SystemC process .vitis_design_wrapper_sim_wrapper.vitis_design_wrapper_i.vitis_design_i.ai_engine_0.inst.aie_logical.aie_xtlm.math_engine.trigger_msm: Please check SystemC code.
Please refer to "xsim.dir/vitis_design_wrapper_sim_wrapper_behav/" for further details.
Time: 130730400 ps Iteration: 1 Process: xsim.dir/vitis_design_wrapper_sim_wrapper_behav/xsim.type
|
xsimcrash.log
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
Printing stacktrace...
[0] /xxxx/xilinx_2023.2/Vivado/2023.2/data/simmodels/xsim/2023.2/lnx64/9.3.0/systemc/protected/aie_cluster_v1_0_0/../aie_cluster_msm_v1_0_0/libaie_cluster_msm_v1_0_0_dbg.so(Tcl_GetBooleanFromObj+0x63) [0x7f6c1f717ef3]
[1] /xxxx/xilinx_2023.2/Vivado/2023.2/data/simmodels/xsim/2023.2/lnx64/9.3.0/systemc/protected/aie_cluster_v1_0_0/../aie_cluster_msm_v1_0_0/libaie_cluster_msm_v1_0_0_dbg.so(checkers_tui_client_server_worker(Checkers_uicore*, int*)+0x1a7) [0x7f6c1f4f1897]
[2] /xxxx/xilinx_2023.2/Vivado/2023.2/data/simmodels/xsim/2023.2/lnx64/9.3.0/systemc/protected/aie_cluster_v1_0_0/../aie_cluster_msm_v1_0_0/libaie_cluster_msm_v1_0_0_dbg.so(chktui_thread_tcl_serializer_client_server(Checkers_uicore*, int*)+0x36) [0x7f6c1f4fdde6]
[3] /xxxx/xilinx_2023.2/Vivado/2023.2/data/simmodels/xsim/2023.2/lnx64/9.3.0/systemc/protected/aie_cluster_v1_0_0/../aie_cluster_msm_v1_0_0/libaie_cluster_msm_v1_0_0_dbg.so(checkers_tui_client_server(Checkers_uicore*)+0xdf) [0x7f6c1f4f1c0f]
[4] /xxxx/xilinx_2023.2/Vivado/2023.2/data/simmodels/xsim/2023.2/lnx64/9.3.0/systemc/protected/aie_cluster_v1_0_0/../aie_cluster_msm_v1_0_0/libaie_cluster_msm_v1_0_0_dbg.so(+0x1189095) [0x7f6c1eeac095]
[5] /xxxx/xilinx_2023.2/Vivado/2023.2/data/simmodels/xsim/2023.2/lnx64/9.3.0/systemc/protected/aie_cluster_v1_0_0/../aie_cluster_msm_v1_0_0/libaie_cluster_msm_v1_0_0_dbg.so(checkers_hosted_clib(Checkers_core*, Checkers_hosted_clib_get_funcs const&, Checkers_hosted_clib_put_funcs const&, Checkers_hosted_clib_get_funcs const&, Checkers_hosted_clib_put_funcs const&, Checkers_hosted_clib_interf_funcs const&, bool)+0x8e92) [0x7f6c1eeb6562]
[6] /xxxx/xilinx_2023.2/Vivado/2023.2/data/simmodels/xsim/2023.2/lnx64/9.3.0/systemc/protected/aie_cluster_v1_0_0/../aie_cluster_msm_v1_0_0/libaie_cluster_msm_v1_0_0_dbg.so(me_uicore::hosted_clib(bool)+0x3e) [0x7f6c1e82a6de]
[7] /xxxx/xilinx_2023.2/Vivado/2023.2/data/simmodels/xsim/2023.2/lnx64/9.3.0/systemc/protected/aie_cluster_v1_0_0/../aie_cluster_msm_v1_0_0/libaie_cluster_msm_v1_0_0_dbg.so(chkapi_check_breakpoint_on_pc(Checkers_uicore*, unsigned long long, bool&, int&)+0x49d) [0x7f6c1f48be0d]
[8] /xxxx/xilinx_2023.2/Vivado/2023.2/data/simmodels/xsim/2023.2/lnx64/9.3.0/systemc/protected/aie_cluster_v1_0_0/../aie_cluster_msm_v1_0_0/libaie_cluster_msm_v1_0_0_dbg.so(chkapi_l_breakpoint_check(Checkers_uicore*, unsigned long long, bool&)+0x16) [0x7f6c1f4317b6]
[9] /xxxx/xilinx_2023.2/Vivado/2023.2/data/simmodels/xsim/2023.2/lnx64/9.3.0/systemc/protected/aie_cluster_v1_0_0/../aie_cluster_msm_v1_0_0/libaie_cluster_msm_v1_0_0_dbg.so(me_uicore::checkBreakpoints(unsigned long long, bool&)+0x27) [0x7f6c1e82a917]
[10] /xxxx/xilinx_2023.2/Vivado/2023.2/data/simmodels/xsim/2023.2/lnx64/9.3.0/systemc/protected/aie_cluster_v1_0_0/../aie_cluster_msm_v1_0_0/libaie_cluster_msm_v1_0_0_dbg.so(me_uicore::callbacks(bool&)+0x606) [0x7f6c1e82af36]
[11] /xxxx/xilinx_2023.2/Vivado/2023.2/data/simmodels/xsim/2023.2/lnx64/9.3.0/systemc/protected/aie_cluster_v1_0_0/../aie_cluster_msm_v1_0_0/libaie_cluster_msm_v1_0_0_dbg.so(me_uicore::slave_post_simulate()+0x32) [0x7f6c1e82b482]
[12] /xxxx/xilinx_2023.2/Vivado/2023.2/data/simmodels/xsim/2023.2/lnx64/9.3.0/systemc/protected/aie_cluster_v1_0_0/../aie_cluster_msm_v1_0_0/libaie_cluster_msm_v1_0_0_dbg.so(chkapi_l_program_post_step_slave(Checkers_uicore*)+0x60) [0x7f6c1f44f570]
[13] /xxxx/xilinx_2023.2/Vivado/2023.2/data/simmodels/xsim/2023.2/lnx64/9.3.0/systemc/protected/aie_cluster_v1_0_0/../aie_cluster_msm_v1_0_0/libaie_cluster_msm_v1_0_0_dbg.so(me_sc::update()+0xfc) [0x7f6c1e8197ac]
[14] /xxxx/xilinx_2023.2/Vivado/2023.2/data/simmodels/xsim/2023.2/lnx64/9.3.0/systemc/protected/aie_cluster_v1_0_0/../aie_cluster_msm_v1_0_0/libaie_cluster_msm_v1_0_0_dbg.so(+0xa27553) [0x7f6c1e74a553]
[15] /xxxx/xilinx_2023.2/Vivado/2023.2/data/simmodels/xsim/2023.2/lnx64/9.3.0/systemc/protected/aie_cluster_v1_0_0/../aie_cluster_msm_v1_0_0/libaie_cluster_msm_v1_0_0_dbg.so(msm_core::msm_proc_handles_per_clk_domain_per_module::execute()+0x4c) [0x7f6c1e807d5c]
[16] /xxxx/xilinx_2023.2/Vivado/2023.2/data/simmodels/xsim/2023.2/lnx64/9.3.0/systemc/protected/aie_cluster_v1_0_0/../aie_cluster_msm_v1_0_0/libaie_cluster_msm_v1_0_0_dbg.so(msm_core::job_executor::execute_process()+0x20) [0x7f6c1e80dbb0]
[17] /xxxx/xilinx_2023.2/Vivado/2023.2/data/simmodels/xsim/2023.2/lnx64/9.3.0/systemc/protected/aie_cluster_v1_0_0/../aie_cluster_msm_v1_0_0/libaie_cluster_msm_v1_0_0_dbg.so(msm_core::job_executor::executer_thread()+0x328) [0x7f6c1e80e438]
[18] /xxxx/xilinx_2023.2/Vivado/2023.2/lib/lnx64.o/../../tps/lnx64/gcc-9.3.0/bin/../lib64/libstdc++.so.6(+0xce3c0) [0x7f6c2b5ce3c0]
[19] /lib64/libpthread.so.0(+0x7be0) [0x7f6c2ad51be0]
[20] /lib64/libc.so.6(clone+0x3f) [0x7f6c2b9ce3bf]
Done
|
解决方案
HW_EMU_FLAGS 移除转发端口 forward_port,此时VIVADO不会崩溃,但上述ERRORs仍然存在。💢 why?
AMD 社区员工回复:重启机器或重装Vitis环境、考虑系统硬件资源是否足够(RAM)
3.2 AIESIM 仿真出现 TclStackFree
错误
问题描述
AIE 工程可以正常编译,但在进行 aiesim 时,启动内核后会输出以下报错:
1
2
3
4
5
6
7
8
9
|
Initializing graph xxxGraph...
Resetting cores of graph xxxGraph...
Configuring DMAs of graph xxxGraph...
Configuring PL-Interface for graph xxxGraph...
Set 1 iterations for the core(s) of graph xxxGraph
Enabling core(s) of graph xxxGraph
Waiting for core(s) of graph xxxGraph to finish execution ...
TclStackFree: incorrect freePtr (0x744b890 != 0x744b8f0). Call out of sequence?
/home/shikai/myhome/tools/xilinx/Vitis/2024.1/aietools/bin/rdiArgs.sh: line 387: 199020 Aborted "$RDI_PROG" "$@"
|
解决方案
- 将工程导入 Vitis GUI,使用 IDE 进行编译,未报错