CVA6 CSR spike discrepancies list

[spidugu444]

HI,

Please find the below list of CSRs which has discrepancies between CVA6 and spike

 

 

Sl no	Name	Address Offset	Width	Access Type	Reset Value	Display Name	STATUS	COMMENT
1	sstatus	0x100	32	RW	0x00000000	Supervisor Status	Spike Dependency	Need to disable FS field on spike end
2	mstatus	0x300	32	RW	0x00000000	Machine Status	Spike Dependency	Need to disable FS field and enable ube bit on spike end
3	misa	0x301	32	RW	0x4014_1105	Machine ISA	Spike Dependency	On MISA Bits 0, 2, and 12 behave like RW rather than WARL on spike end.
4	pmpcfg[0..1]	0x3A0	32	RW	0x00000000	Physical Memory Protection Config 0	spike dependency	Issue with default value reading as 0x01f
5	pmpaddr[7]	0x3B0 [+ i*0x1]	32	RW	0x00000000	Physical Memory Protection Address	spike dependency	Issue with spike configuration and default values
6	mvendorid	0xF11	32	RO	0x00000602	Machine Vendor ID	spike dependency	Need to configure reset value as 0x602 on spike end
7	marchid	0xF12	32	RO	0x00000003	Machine Architecture ID	spike dependency	Need to configure reset value as 0x01 on  spike end
8	icache	0x7C0	32	RW	0x00000001	Instruction Cache	spike dependency	Need to configure Custom CSRs on spike end
9	dcache	0x7C1	32	RW	0x00000001	Data Cache	spike dependency	Need to configure Custom CSRs on spike end

For MCOUNTEREN and SCOUNTEREN CSRs, even though when we write non-zero values these CSRs are always reading zero on spike end. The reserved field bit 12 for MIE and MIDELEG CSRs is reading one on the spike end when written with a non-zero value which it should be always zero.

Thanks

[spidugu444]

As per the riscv privileged specification, for PMPCFG CSR bit [6:5] marked as reserved. In CVA6 bits 5 and 6 has never used but they are stored and will be returned as written. As of now on spike end bit [6:5] acting like reserved field, need to change bits 5 and 6 access type to RW on spike end to make compliance with RTL. For more info, please refer issue(#1363).

Thanks

[zchamski]

Regarding discrepancy 3 (MISA bits), an implementation may use the MISA register to support emulating multiple ISAs on the same hardware, effectively changing the currently recognized ISA. The unprivileged spec states p. 5 (non-normative text) that :

The RISC-V privileged architecture provides fields in misa to control the unprivileged ISA at each level to support emulating different base ISAs on the same hardware. We note that newer SPARC and MIPS ISA revisions have deprecated support for running 32-bit code unchanged on 64-bit systems.

The privileged spec states in normative text (section 3.1.1, Machine ISA Register misa, p.16) that :

The Extensions field encodes the presence of the standard extensions, with a single bit per letter of the alphabet (bit 0 encodes presence of extension “A” , bit 1 encodes presence of extension “B”, through to bit 25 which encodes “Z”). The “I” bit will be set for RV32I, RV64I, RV128I base ISAs, and the “E” bit will be set for RV32E. The Extensions field is a WARL field that can contain writable bits where the implementation allows the supported ISA to be modified. At reset, the Extensions field shall contain the maximal set of supported extensions, and “I“ shall be selected over “E“ if both are available.

When a standard extension is disabled by clearing its bit in misa, the instructions and CSRs defined or modified by the extension revert to their defined or reserved behaviors as if the extension is not implemented.

[spidugu444]

As per the riscv privileged specification, for PMPCFG CSR bit [6:5] marked as reserved. In CVA6 bits 5 and 6 has never used but they are stored and will be returned as written. As of now on spike end bit [6:5] acting like reserved field, need to change bits 5 and 6 access type to RW on spike end to make compliance with RTL. For more info, please refer issue(#1363).

Thanks

With the Implementation of PR https://github.com/openhwgroup/cva6/pull/1368, the PMPCFG CSR bit [6:5] is hardwired to zero, which fixes the discrepancy between spike and CVA6 for the PMPCFG CSRs bit [6:5].

[JeanRochCoulon]

Thanks. Can you point the solved issue from the above table ?

[spidugu444]

@JeanRochCoulon, For PMPCFG CSR it has multiple issues on spike end, for PMPCFG[0] CSR it has issue with default value as it is reading it as 0x01F. In PMPCFG[1] CSR, while trying to read by configuring combinations A set to NA4 or R=0 and W=1 it needs to ignore the write and read the CSRs previous value but on spike end it is reading different value.

For more info on PMPCFG CSR this please refer to this https://github.com/openhwgroup/cva6/issues/1363 .

[MarioOpenHWGroup]

In the modified version of Spike of the tasks #1402 and #1403 the following CSRs has been adapted: pmpcfg0, pmpaddr0, marchid, mvendorid, misa mstatus status (now follows cva6 isa),

[ASintzoff]

Related to task https://github.com/openhwgroup/cva6/issues/1403

[zchamski]

Regarding the UBE bit in mstatus (row 2 in table above): our current vendorized Spike version (upstream commit fcbdbe794) knows about this bit and examines it when the core supports the U extension. Otherwise, the corresponding value is read as constant 0. The reset value in Spike is 0 unless the target is configured as big-endian (which we do not support.)

[MarioOpenHWGroup]

@zchamski as you say if the U extension is not active the UBE bit will be constant 0.