[TASK] Modify Spike to match core-specific configuration

[zchamski]

Background

Spike implements a complete set of functionality corresponding to the RISC-V specifications. At times this set can be a superset of features of an implementation, in particular in the areas where the specification allows behaviors ("an implementation can" or "may" ...) without enforcing their presence.

In such situations Spike behavior needs to be constrained to match the exact set of features provided by the implementation so that behaviors not supported by the implementation will be duly rejected by Spike.

What (objective description)

Add extra controls to Spike in the areas where the RISC-V specification allows an implementation to choose a specific behjavior so that Spike behaves as described in the specification of the "Embedded" CVA6 configuration.

How To

• Identify all points in RISC-V specification where the behavior is allowed to be implementation-defined
• Identify all points in the specification of the Embedded CVA6 configuration which determine the implementation-defined behaviors identified in previous step
• Extend Spike control interface (command line and/or configuration scripts) with parameters necessary to represent the properties of the Embedded configuration and constrain Spike behavior according to the values of these parameters.

Ideally this would be a set of class extensions for each CVA6 configuration. We can use the "step 1" and "embedded" cores as the examples.

Current Status

• Initial implementation of Spike parameterization done by @MarioOpenHWGroup
• Initial identification of implementation-definable behaviors done by @zchamski

Risks

• Specification of the Embedded configuration incomplete / imprecise

Prerequisites

None

KPI

TBD

Description of DONE

Spike simulations using parameter values for Embedded configuration yield identical results as RTL simulations of the Embedded configuration on all CI tests.

[MarioOpenHWGroup]

Further exploration is needed to catch all the discrepancies between spike and cva6

[zchamski]

We have three sources of discrepancies:

• differences in interpretation of implementation-dependent "may"/"can" cases in the RISC-V specs
• bugs in CVA6
• (unlikely but possible) bugs in Spike.

We need to capture formally the "may" and "can" cases in RISC-V specs. From there we need a systematic review of how these are implemented on both sides.

[MarioOpenHWGroup]

tval value is not matching between core and spike, this needs to be discussed or fixed in spike side

[JeanRochCoulon]

GitHub issue need to be open to speicify which value to assign to tval

[MarioOpenHWGroup]

Tval has been reverted to the original state and the instr field of the scoreboard_entry_t has been removed

[MarioOpenHWGroup]

Issues are appearing regarding specific cva6 config #1625 #1599 #1145

[MarioOpenHWGroup]

It is mandatory in this task that we know what we have the specification to rely when changing the Reference Model. Many issues above exist because unspecified parts or inconsistencies between the spec and the current environment implementation.

[MarioOpenHWGroup]

I am making some notes about the can/may parts of the spec to implement (some of them) in Spike.

[MarioOpenHWGroup]

No updates done in this task.

[zchamski]

The behavior of bit 0 in the PMPADDRn CSRs depends on the address matching mode in effect (encoded in the associated PMPCFG register) and the PMP granularity set for each core.

The corresponding logic appears to be present in Spike and the determination of the PMP granularity is affected by the Device Tree specification used by Spike:

• A default value of 4 is set in the constructor of the processor_t class.
• If a device tree seen by Spike contains an explicit PMP granularity entry for the given core, the associated value will be used (if valid).

By default, Spike reads the built-in device tree which specifies a hard-coded PMP granularity of 4 (a compile-time constant).

On CVA6 the PMP granularity is hardwired to 8, and therefore, any device tree-suppllied values will be silently ignored. The best solution seems thus to be a new Param entry that overrides the default PMP granularity set by Spike.

[MarioOpenHWGroup]

Agree, I will add the parameter

[zchamski]

Agree, I will add the parameter

@MarioOpenHWGroup, I can see Spike params /top/.../pmpregions (number of PMP regions), /top/.../pmpaddr0 (reset value of PMPADDR0), and /top/.../pmpcfg0 (reset value of PMPCFG0), but none that can directly set PMP granularity. Do you (plan to) have a specific parameter for this purpose?