Reverse order of byte array on integer granularity

SystemVerilog
, ,
1

I have a byte array like the following:


 bit [7:0] my_array[N];

Do you know an easy way to reverse to order of elements but on 32-bit granularity?
e.g., I have N = 12


my_array[3] = my_array[11]
my_array[2] = my_array[10]
my_array[1] = my_array[9]
my_array[0] = my_array[8]

my_array[7] = my_array[7]
my_array[6] = my_array[6]
my_array[5] = my_array[5]
my_array[4] = my_array[4]

my_array[11] = my_array[3]
my_array[10] = my_array[2]
my_array[9] = my_array[1]
my_array[8] = my_array[0]

I wonder if that is somehow possible with the streaming operator?

2

In reply to robert.schilling:

Yes, the streaming operator can do this:

    my_array= {<<32{my_array}};
3

In reply to dave_59:

In reply to robert.schilling:
Yes, the streaming operator can do this:

    my_array= {<<32{my_array}};

@Dave. Can you help me understanding this stream function. Trying to understand it’s functionality and how it is making the answer for the requirement?

I created the demo example at eda playground link and got the below output with two way of doing this.
1- as Dave mentioned
2- as per my understanding of the requirement
for(int unsigned idx = 0 ; idx < $size(my_rd_arr)/4; idx++) begin
for(int unsigned jdx = 0; jdx < 4; jdx++) begin
my_rd_arr[(4 * idx) + jdx] = my_arr[($size(my_arr) - ((4 * idx))) - (4 - jdx)];
end
end

Below is the outputs of both:
@Robert, can you provide which one is correct:
UVM_INFO sv_uvm/strem_op.sv(52) @ 0: reporter [TB] my_arr[0] = 30
UVM_INFO sv_uvm/strem_op.sv(52) @ 0: reporter [TB] my_arr[1] = 46
UVM_INFO sv_uvm/strem_op.sv(52) @ 0: reporter [TB] my_arr[2] = 53
UVM_INFO sv_uvm/strem_op.sv(52) @ 0: reporter [TB] my_arr[3] = 42
UVM_INFO sv_uvm/strem_op.sv(52) @ 0: reporter [TB] my_arr[4] = 24
UVM_INFO sv_uvm/strem_op.sv(52) @ 0: reporter [TB] my_arr[5] = 48
UVM_INFO sv_uvm/strem_op.sv(52) @ 0: reporter [TB] my_arr[6] = 43
UVM_INFO sv_uvm/strem_op.sv(52) @ 0: reporter [TB] my_arr[7] = 28
UVM_INFO sv_uvm/strem_op.sv(52) @ 0: reporter [TB] my_arr[8] = 51
UVM_INFO sv_uvm/strem_op.sv(52) @ 0: reporter [TB] my_arr[9] = 45
UVM_INFO sv_uvm/strem_op.sv(52) @ 0: reporter [TB] my_arr[10] = 25
UVM_INFO sv_uvm/strem_op.sv(52) @ 0: reporter [TB] my_arr[11] = 60
UVM_INFO sv_uvm/strem_op.sv(55) @ 0: reporter [TB] dave_rd_arr[0] = 60
UVM_INFO sv_uvm/strem_op.sv(55) @ 0: reporter [TB] dave_rd_arr[1] = 152
UVM_INFO sv_uvm/strem_op.sv(55) @ 0: reporter [TB] dave_rd_arr[2] = 180
UVM_INFO sv_uvm/strem_op.sv(55) @ 0: reporter [TB] dave_rd_arr[3] = 204
UVM_INFO sv_uvm/strem_op.sv(55) @ 0: reporter [TB] dave_rd_arr[4] = 56
UVM_INFO sv_uvm/strem_op.sv(55) @ 0: reporter [TB] dave_rd_arr[5] = 212
UVM_INFO sv_uvm/strem_op.sv(55) @ 0: reporter [TB] dave_rd_arr[6] = 12
UVM_INFO sv_uvm/strem_op.sv(55) @ 0: reporter [TB] dave_rd_arr[7] = 24
UVM_INFO sv_uvm/strem_op.sv(55) @ 0: reporter [TB] dave_rd_arr[8] = 84
UVM_INFO sv_uvm/strem_op.sv(55) @ 0: reporter [TB] dave_rd_arr[9] = 172
UVM_INFO sv_uvm/strem_op.sv(55) @ 0: reporter [TB] dave_rd_arr[10] = 116
UVM_INFO sv_uvm/strem_op.sv(55) @ 0: reporter [TB] dave_rd_arr[11] = 120
UVM_INFO sv_uvm/strem_op.sv(58) @ 0: reporter [TB] my_rd_arr[0] = 51
UVM_INFO sv_uvm/strem_op.sv(58) @ 0: reporter [TB] my_rd_arr[1] = 45
UVM_INFO sv_uvm/strem_op.sv(58) @ 0: reporter [TB] my_rd_arr[2] = 25
UVM_INFO sv_uvm/strem_op.sv(58) @ 0: reporter [TB] my_rd_arr[3] = 60
UVM_INFO sv_uvm/strem_op.sv(58) @ 0: reporter [TB] my_rd_arr[4] = 24
UVM_INFO sv_uvm/strem_op.sv(58) @ 0: reporter [TB] my_rd_arr[5] = 48
UVM_INFO sv_uvm/strem_op.sv(58) @ 0: reporter [TB] my_rd_arr[6] = 43
UVM_INFO sv_uvm/strem_op.sv(58) @ 0: reporter [TB] my_rd_arr[7] = 28
UVM_INFO sv_uvm/strem_op.sv(58) @ 0: reporter [TB] my_rd_arr[8] = 30
UVM_INFO sv_uvm/strem_op.sv(58) @ 0: reporter [TB] my_rd_arr[9] = 46
UVM_INFO sv_uvm/strem_op.sv(58) @ 0: reporter [TB] my_rd_arr[10] = 53
UVM_INFO sv_uvm/strem_op.sv(58) @ 0: reporter [TB] my_rd_arr[11] = 42

4

In reply to nhp:

nhp, you forgot the slice_size of 32 in your example. Once you fix that, the two algorithms match.

The slice_size number that number of bits together when reversing the bits. That gives Robert the granularity requirement. See section 11.4.14.2 Re-ordering of the generic stream in the IEEE 1800-2017 SystemVerilog LRM.