About the difference between annotation and spec 0.9. about ara HOT 3 CLOSED

Hello Fog-cake,

You are right; our physical layout is different from the one depicted in the specs (and maybe there is an error in the comment inside ara_pkg.sv).
We have a register file that is split into multiple parts, one part per lane. This somehow "mandates" to have subsequent elements separated by one lane each. The internal representation within the 64-bit data width is kept in the way you see just because it is more convenient for operations in which EEW != SEW (I actually saw that this could not be the case for FP operations, though).
The important part is that thanks to the shuffling and deshuffling functions, everything should behave as VLEN == SLEN from an external point of view (for example, when data loaded in a register is then stored using a store targeting a different SEW), and the execution is predictable and behaves as the elements are physically kept in the VRF respecting the pattern in the specs.
Anyway, this is a nice issue to be raised since a satisfying verification of this behavior (that should be enforced) has not been done yet. In the meantime, if you experience some non-compliant behavior (we can easily verify the correct behavior with SPIKE), please tell us opening a dedicated issue!

from ara.

Hello Fog-cake,

You are right; our physical layout is different from the one depicted in the specs (and maybe there is an error in the comment inside ara_pkg.sv).
We have a register file that is split into multiple parts, one part per lane. This somehow "mandates" to have subsequent elements separated by one lane each. The internal representation within the 64-bit data width is kept in the way you see just because it is more convenient for operations in which EEW != SEW (I actually saw that this could not be the case for FP operations, though).
The important part is that thanks to the shuffling and deshuffling functions, everything should behave as VLEN == SLEN from an external point of view (for example, when data loaded in a register is then stored using a store targeting a different SEW), and the execution is predictable and behaves as the elements are physically kept in the VRF respecting the pattern in the specs.
Anyway, this is a nice issue to be raised since a satisfying verification of this behavior (that should be enforced) has not been done yet. In the meantime, if you experience some non-compliant behavior (we can easily verify the correct behavior with SPIKE), please tell us opening a dedicated issue!

Hi，mp-17,
Thank you for your answers. Yes it is. VLEN=SLEN is currently adopted in the 0.1.0 specification. I see that you have also recently updated to version 0.1.0. If I find a problem that is inconsistent with the specification, I will open a new one.

from ara.

Just as a reference: riscv/riscv-v-spec#738

from ara.