I found that a masked vse32.v with nonzero vstart leaves active elements unchanged on Ara. The same testcase works as expected on Spike. Both runs use VLEN = 4096.
The testcase is:
vsetivli x0, 4, e32, m1
la t0, src_data
vle32.v v8, (t0)
vid.v v1
vand.vi v2, v1, 1
vmsne.vi v0, v2, 0
li t0, 1
csrw vstart, t0
la t1, dst_data
vse32.v v8, (t1), v0.t
with:
src_data = {0x11111111, 0x22222222, 0x33333333, 0x44444444}
dst_data = {0xaaaaaaaa, 0xbbbbbbbb, 0xcccccccc, 0xdddddddd}
vstart = 1
v0.t active only for odd elements
So the expected architectural behavior is:
- element
0 is skipped because vstart = 1
- element
1 is active and should be stored
- element
2 is masked off and should remain unchanged
- element
3 is active and should be stored
Spike reports:
mem 0x0000000080021200 0xaaaaaaaa
mem 0x0000000080021204 0x22222222
mem 0x0000000080021208 0xcccccccc
mem 0x000000008002120c 0x44444444
mem 0x0000000080021210 0x0000000000000000 # vstart
mem 0x0000000080021218 0x0000000000000000 # exit code
Ara completes the testcase and exits successfully, but the destination data is
wrong:
mem 0x0000000080021200 0xffffffffaaaaaaaa
mem 0x0000000080021204 0xffffffffbbbbbbbb
mem 0x0000000080021208 0xffffffffcccccccc
mem 0x000000008002120c 0xffffffffdddddddd
mem 0x0000000080021210 0x0000000000000000 # vstart
mem 0x0000000080021218 0x0000000000000000 # exit code
So Ara leaves all four destination elements at their old values. In particular, elements 1 and 3 should have been updated to 0x22222222 and 0x44444444, but they remain 0xbbbbbbbb and 0xdddddddd.
riscv64-unknown-elf-gcc -nostdlib -static \
-march=rv64imfdcv_zicsr_zifencei_zfh \
-mabi=lp64d \
-T /home/user/common.ld \
-o /home/user/masked_store_vstart_lane_misalignment.elf \
/home/user/masked_store_vstart_lane_misalignment.S
/home/user/riscv-isa-sim/install/bin/spike \
-p1 \
--isa=RV64IMAFDCV_ZICSR_ZIFENCEI_ZFH_ZVL4096B \
--log-commits \
/home/user/masked_store_vstart_lane_misalignment.elf \
> masked_store_vstart_lane_misalignment.spike.log 2>&1
/home/user/ara/hardware/build-rvfi9/verilator/Vara_tb_verilator \
-l ram,/home/user/masked_store_vstart_lane_misalignment.elf,elf \
> masked_store_vstart_lane_misalignment.ara.log 2>&1
program.zip
I found that a masked
vse32.vwith nonzerovstartleaves active elements unchanged on Ara. The same testcase works as expected on Spike. Both runs useVLEN = 4096.The testcase is:
with:
src_data = {0x11111111, 0x22222222, 0x33333333, 0x44444444}dst_data = {0xaaaaaaaa, 0xbbbbbbbb, 0xcccccccc, 0xdddddddd}vstart = 1v0.tactive only for odd elementsSo the expected architectural behavior is:
0is skipped becausevstart = 11is active and should be stored2is masked off and should remain unchanged3is active and should be storedSpike reports:
Ara completes the testcase and exits successfully, but the destination data is
wrong:
So Ara leaves all four destination elements at their old values. In particular, elements
1and3should have been updated to0x22222222and0x44444444, but they remain0xbbbbbbbband0xdddddddd.program.zip