Help debugging dot product about vicuna HOT 3 CLOSED

Thanks for reporting this and for the detailed analysis!

The vl_part and vl_part_0 signals encode the VL (vector length) for the part of the vector currently being processed. They are derived from the vl_q and vl_0_q signals in vproc_core.sv.

The encoding is as follows: The value in vl_q is the vector length in bytes (rather than in elements) minus 1. As an example, vsetivli t0,3,e16,m1 (i.e., selecting a vector length of 3 for 16-bit elements) would result in vl_q being set to 5 (3*2-1). Since a VL of 0 cannot be encoded in vl_q, the extra bit vl_0_q is used as a flag to indicate that the content of vl_q is invalid and the vector length is 0 instead.

When one of the execution units processes a part of a vector register, a vl_part and vl_part_0 signal are derived from vl_q and vl_0_q. The encoding is the same, except that these signals only cover the part that is currently being processed (so vl_part_0 would initially be low and vl_part indicates how many bytes of the current part are still covered by the VL setting and once the part being processed is beyond the VL, then vl_part_0 is set).

I initially selected that (rather unintuitive) encoding because it allowed for some optimizations, although I am not sure if that still applies. Maybe it might be better to switch to a simpler encoding for VL.

I ran your code and the reason why vl_part_0 is high is that vl_0_q is set in vproc_core.sv. That in turn is because with some recent refactoring I moved a conditional branch in the code which updates vl_q and vl_0_q upon a vsetvl instruction and forgot to take the special case into account that applies when both rd and rs1 are x0 (keeping the current VL). That is why the instruction vsetvli zero,zero,e32,m2,tu,mu incorrectly sets vl_0_q.

Apologies for that, I fixed it now and hopefully your code should work now.

from vicuna.

Thanks, looks good on my end. Is there an easy way to add a test case for this? How do you generate your test code and data? I'm happy to create PRs for new tests for all these little bugs as I find them.

from vicuna.

That would be awesome! New test cases can be added by creating a new assembly (*.S) file in one of the sub-directories of test/. Currently, most of them are unit tests for the individual execution units, grouped into sub-directories named according to the respective unit.

The test/csr/ sub-directory is intended to contain tests for instructions manipulating the vector CSR. Currently, it only contains two test cases. A new test case for checking that the special vsetvl variant for keeping the current VL is handled correctly would best fit under this directory.

The way the test cases work is by executing the main function in the assembly file, which usually reads data from the memory section between vdata_start and vdata_end, modifies it, and writes it back (although some test cases might only write to that section). The test framework then checks whether the final content of that memory section corresponds to the expected reference, which is also encoded in the *.S file (it is the content between vref_start and vref_end).

A way to implement a test case for the special vsetvl variant would be to first set the VL to some value using a regular vsetvl, then use the special variant and then verify that subsequent vector instructions still process the expected number of vector elements. For instance, the following instructions should overwrite the first 11 bytes after vdata_start with 0x5a.

    la              a0, vdata_start

    li              t0, 11
    vsetvli         t0, t0, e16,m2

    vsetvli         x0, x0, e8,m1

    li              t0, 0x5a
    vmv.v.x         v0, t0
    vse8.v          v0, (a0)

Therefore, in order to verify that this code has executed correctly, the memory content between vref_start and vref_end should match the initial content between vdata_start and vdata_end expect that the first 11 bytes are replaced by 0x5a. The initial content between vdata_start and vdata_end can be any values, either generated randomly or simply copied over from another test file.

from vicuna.