Vector FIR RTL

[rp15]

Looking at MeshMultiCgraRTL_test.py, the CGRA RTL is different between test_fir_vector_global_reduce and test_fir_scalar, since the former redefines some variables in its elif test_name == 'test_fir_vector_global_reduce': clause.

I tried adding a new function to translate the Vector FIR test into SV, but I was getting failures. The first one seemed to be a simple PyMTL "or" vs "|" for RTL purposes.

The second one is an issue with vector indexing. I found a fix that lets the code translate to SV, but I am not sure if the new version's functionality matches that of the old one. (Missing s.temp_result[i] @= TempDataType(0).)

This low:high indexing is not overlapping in Python due to the upper bound being exclusive, right?

Also, we might want to use //= instead of connect, but, IIUC, they are interchangeable.

[rp15]

Looking at MeshMultiCgraRTL_test.py, the CGRA RTL is different between test_fir_vector_global_reduce and test_fir_scalar, since the former redefines some variables in its elif test_name == 'test_fir_vector_global_reduce': clause.

I tried adding a new function to translate the Vector FIR test into SV, but I was getting failures. The first one seemed to be a simple PyMTL "or" vs "|" for RTL purposes.

The second one is an issue with vector indexing. I found a fix that lets the code translate to SV, but I am not sure if the new version's functionality matches that of the old one. (Missing s.temp_result[i] @= TempDataType(0).)

This low:high indexing is not overlapping in Python due to the upper bound being exclusive, right?

Also, we might want to use //= instead of connect, but, IIUC, they are interchangeable.

This is the generated SV for the changes:

or vs | (reduce_add and reduce_mul are similar):
13201 // PyMTL Lambda Block Source
13202 // At /home/ajokai/cgra/VectorCGRAfork0/fu/vector/VectorAllReduceRTL.py:80
13203 // s.reduce_mul.in_[i] //= lambda: (s.temp_result[i]
13204 // if (s.recv_opt.msg.operation == OPT_VEC_REDUCE_MUL) |
13205 // (s.recv_opt.msg.operation == OPT_VEC_REDUCE_MUL_BASE) |
13206 // (s.recv_opt.msg.operation == OPT_VEC_REDUCE_MUL_GLOBAL) |
13207 // (s.recv_opt.msg.operation == OPT_VEC_REDUCE_MUL_BASE_GLOBAL) else 0)
13208
13209 always_comb begin : lambda__s_dut_cgra_0__tile_0__element_fu_13__reduce_mul_in__2
13210 reduce_mul__in_[2'd2] = ( ( ( ( recv_opt__msg.operation == 7'( _const__OPT_VEC_REDUCE_MUL ) ) | ( recv_opt
13210 _msg.operation == 7'( __const__OPT_VEC_REDUCE_MUL_BASE ) ) ) | ( recv_opt__msg.operation == 7'( __const__OPT_VEC
13210 _REDUCE_MUL_GLOBAL ) ) ) | ( recv_opt__msg.operation == 7'( __const__OPT_VEC_REDUCE_MUL_BASE_GLOBAL ) ) ) ? temp
13210 _result[2'( _const__i_at__lambda__s_dut_cgra_0__tile_0__element_fu_13__reduce_mul_in__2 )] : 64'd0;
13211 end

Indexing issue:
13480 assign temp_result[0][15:0] = recv_in__msg[0].payload[15:0];
13481 assign temp_result[1][15:0] = recv_in__msg[0].payload[31:16];
13482 assign temp_result[2][15:0] = recv_in__msg[0].payload[47:32];
13483 assign temp_result[3][15:0] = recv_in__msg[0].payload[63:48];

[tancheng]

Looking at MeshMultiCgraRTL_test.py, the CGRA RTL is different between test_fir_vector_global_reduce and test_fir_scalar, since the former redefines some variables in its elif test_name == 'test_fir_vector_global_reduce': clause.

I tried adding a new function to translate the Vector FIR test into SV, but I was getting failures. The first one seemed to be a simple PyMTL "or" vs "|" for RTL purposes.

The second one is an issue with vector indexing. I found a fix that lets the code translate to SV, but I am not sure if the new version's functionality matches that of the old one. (Missing s.temp_result[i] @= TempDataType(0).)

This low:high indexing is not overlapping in Python due to the upper bound being exclusive, right?

Also, we might want to use //= instead of connect, but, IIUC, they are interchangeable.

Thanks for the fix.

This low:high indexing is not overlapping in Python due to the upper bound being exclusive, right?

I believe your generated SV code verify this?

Also, we might want to use //= instead of connect, but, IIUC, they are interchangeable.

Can you try s.temp_result[i][0:sub_bw] //= s.recv_in[0].msg.payload[low:high], or it doesn't work? (They should be interchangeable.)

[rp15]

Looking at MeshMultiCgraRTL_test.py, the CGRA RTL is different between test_fir_vector_global_reduce and test_fir_scalar, since the former redefines some variables in its elif test_name == 'test_fir_vector_global_reduce': clause.
I tried adding a new function to translate the Vector FIR test into SV, but I was getting failures. The first one seemed to be a simple PyMTL "or" vs "|" for RTL purposes.
The second one is an issue with vector indexing. I found a fix that lets the code translate to SV, but I am not sure if the new version's functionality matches that of the old one. (Missing s.temp_result[i] @= TempDataType(0).)
This low:high indexing is not overlapping in Python due to the upper bound being exclusive, right?
Also, we might want to use //= instead of connect, but, IIUC, they are interchangeable.

Thanks for the fix.

This low:high indexing is not overlapping in Python due to the upper bound being exclusive, right?

I believe your generated SV code verify this?

Also, we might want to use //= instead of connect, but, IIUC, they are interchangeable.

Can you try s.temp_result[i][0:sub_bw] //= s.recv_in[0].msg.payload[low:high], or it doesn't work? (They should be interchangeable.)

Same hw. ^^