I believe that @en-sc's comment here is correct:
https://github.com/riscv-software-src/riscv-isa-sim/pull/2161#discussion_r2564958203
Nevertheless, failing an assertion when someone sets a trigger on memory
accessed by a wide access is not reasonable behavior for Spike. Better to
do something that follows the principle of least surprise, despite the
debug spec's lack of clarity on this point.
According to the debug specification (select bit description):
0 (address): There is at least one compare value and it contains
the lowest virtual address of the access. In addition, it is recommended
that there are additional compare values for the other accessed
virtual addresses match. (E.g. on a 32-bit read from 0x4000,
the lowest address is 0x4000 and the other addresses
are 0x4001, 0x4002, and 0x4003.)
1 (data): There is exactly one compare value and it contains
the data value loaded or stored, or the instruction executed.
Any bits beyond the size of the data access will contain 0.
Previously, when select bit was 0, Spike did not follow
the recommendation and provided only 1 matching value to the trigger module.
This change modifies the behavior to the recommended one.
The implementation follows the debug specification recommendation.
Signed-off-by: Farid Khaydari <f.khaydari@syntacore.com>
- Change polarity of svukte_qualified to match ISA spec
- Avoid address dependence of svukte_qualified, per ISA spec
- Move address check to separate routine
Based on section 18.2 in spec
"All Zve* extensions support all vector integer instructions (Section
Vector Integer Arithmetic Instructions), except that the vmulh integer
multiply variants that return the high word of the product (vmulh.vv,
vmulh.vx, vmulhu.vv, vmulhu.vx, vmulhsu.vv, vmulhsu.vx) are not
included for EEW=64 in Zve64*."
"All Zve* extensions support all vector fixed-point arithmetic
instructions (Vector Fixed-Point Arithmetic Instructions), except that
vsmul.vv and vsmul.vx are not included in EEW=64 in Zve64*"
Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com>
Based on spec
section 18.4
"The Zvfhmin extension depends on the Zve32f extension."
section 18.5,
"The Zvfh extension depends on the Zve32f and Zfhmin extensions."
Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com>
Andrew Waterman
pointerliu
steven
muhammad.moiz.hussain
mslijepc
Ömer Güzel
Farid Khaydari
Muhammad Moiz Hussain
Binno
Chih-Min Chao