Support Register Aliases That Provide a Restricted View of Another Register

[kathlenemagnus]

There are several RISC-V CSRs that are not physical registers, but instead provide a restricted view of another CSR. Two examples of this in RISC-V are the mstatus/sstatus and the fcsr/frm/fflags CSRs. For mstatus/sstatus, the base register mstatus is a real register while the sstatus CSR only provides access to a subset of the mstatus CSR's fields. To support this with Sparta today, a functional model has to define both registers and manually keep them in sync. A register alias type would allow reads/writes to be performed on the underlying register.

[klingaard]

Sounds like a fun task.

[klingaard]

Some ideas on the design as well as requirements.

General Requirements

1. This is different from alias, where a register with the same type/number can have different names (aliased). For example, register x2 is also known as sp in the RISC-V architecture
2. This is different from RegisterProxy where a register with the same type/number can be viewed differently depending on possible modes of operation (like switching between banks of registers)
3. A register can be considered a "shadow" of another register where reading/writing a register affects another. Neither register should be considered the "parent" of another, but simply related like siblings
4. The framework should enable a modeler's ability to define a relationship between register siblings and when that relationship matters. For example, on a register read, should a sibling register be read before or after the current register? Should the value come from a sibliing register or does the sibling register control what is read from the current register?
5. Performance should be maintained. Many registers do not have relationships to other registers and should incur any performance cost
6. Register notifications will occur on all registers being accessed
7. Register DMI is not allowed on a register that contains a sibling

Register Relationships (Proposed API)

A new API to sparta::Register to establish a relationship will be added:

//!  For full, transparent access between one register and another
void Register::setRelationship(Register * sibling);

//! For unknown access between one register and another
void Register::setRelationship(Register * sibling, 
                               const RegisterAccessReadCB & read_callback, 
                               comet RegisterAccessWriteCB & write_callback);

// where RegisterAccessReadCB is
using RegisterAccessReadCB  = std::function<void(void *buf, size_t size, size_t offset)>;
using RegisterAccessWriteCB  = std::function<void(const void *buf, size_t size, size_t offset)>;

Example

Consider register A having a sibling register B. B knows nothing about register A, but A's behavior is directly affected by B's state/value. A's value is partially derived from register B's value.

The relationship between these registers is established by the modeler:

register_A = register_set->getRegister("A");  // register group 1, idx 10 (example)
register_B = register_set->getRegister("B");  // register group 1, idx 11 (example)

register_A->setRelationship(register_B); // All reads/writes go to register B

1. Reading register B will return register B's value. A is not affected
2. Reading register A will return register B's value
3. Writing register B will update register B.
4. Reading register A will return value written to B.

More to come...

[DavidYu360]

This is the largest CSR network I know in riscv. :)