Closed 0rd1narY1 closed 4 days ago
Thanks a lot! I am refactoring the MASKU
to solve the many bugs it has triggered.
If you want, can you try the base branch of this PR and let me know if the bug is still there?
Okay, I have tried. The test should actually be:
VSET(8, e8, m1);
VLOAD_8(v3, 0x94, 0, 0, 0, 0, 0, 0, 0);
VLOAD_8(v0, 0xC3, 0, 0, 0, 0, 0, 0, 0);
VCLEAR(v2);
asm volatile("vmsbf.m v2, v3, v0.t");
VSET(1, e8, m1); // Different here
VCMP_U8(17, v2, 0x43); // Different here
Since you are comparing only the first 8 bits for this operation (the last ones are prescribed as tail-agnostic by the specs).
This test passes with the new mask unit. I have added the test to the test suite, thank you! ;)
Feel free to re-open the issue if something is not clear.
Hi! I tried simulating VMSBF, VMSIF and VMSOF instructions with self-added testcases consistent with the examples in the RVV1.0 spec. Then I met errors in the RTL simulation. However, I passed the simulations using Spike.
The example in the RVV1.0 spec
where v3 contents are masked by v0, and then the result is written in v2.
Testcase
The testcase is the same as what is in the manual. The expected result is 01000011.
Simulations
Spike simulation passed successfully.
But RTL simulation got wrong result.
It shows that RTL simulation got a result of 0x3 instead of 0x43.
Possible RTL Design Bug
I think there may be a bug in MaskUnit Design. Here is the code in masku.sv, line 501-515:
We first get the result 'alu_result_vm' using the operand 'alu_operand_b_seq' which isn't masked and then mask the result to get 'alu_result_vm_m'. But actually we should mask the operand first and then get the result, according to the manual. In this wrong case, we first get result 0 0 0 0 0 0 1 1, and then mask it to get the final result 0 0 0 0 0 0 1 1(0x3)(where mask vector is 1 1 0 0 0 0 1 1).