Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add unratified Smclic, Ssclic, Smclicshv extensions #420

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

dansmathers
Copy link
Contributor

Spec: https:/riscv/riscv-fast-interrupt
Tests: riscv-non-isa/riscv-arch-test#436

Note: pulls are not yet available for spike that support CLIC

Related pulls to run arch-tests against the sail-riscv model:
riscv-software-src/riscv-config#169
riscv-software-src/riscof#106
riscv-software-src/riscv-isa-sim#1596

To include m-mode CLIC interrupt tests in riscof testlist flow, add Smclic to riscof yaml file, e.g.:
spike/spike_isa.yaml:
ISA: RV32IMCZicsr_Zifencei_Smclic

_ => [v with Mode = o[Mode]]
}
}

function haveSmclic() -> bool = mtvec[Mode] == 0b11
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

haveFoo means Foo is available for use, not that its additions are currently being used. That is, haveSmclic means "is the model configured to provide the Smclic extension?", not "has software configured mtvec to use the CLIC?".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can change all places that say haveSmclic to SmclicMode. Is that acceptable?


val trapVectorMode_of_bits : tv_mode -> TrapVectorMode
function trapVectorMode_of_bits (m) =
match (m) {
0b00 => TV_Direct,
0b01 => TV_Vector,
0b11 => TV_Smclic,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only if you have the CLIC extension. Plus this is for all xtvec, not just mtvec.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see this in the Priv spec:

The mtvec register must always be implemented, but can contain a read-only value. If mtvec is
writable, the set of values the register may hold can vary by implementation. The value in the
BASE field must always be aligned on a 4-byte boundary, and the MODE setting may impose
additional alignment constraints on the value in the BASE field.

So just as TV_Vector may not be supported by an implementation, TV_Smclic may not be supported by an implementation. When @billmcspadden-riscv adds WARL config support to the riscv-sail model, TV_Smclic WARL support can be handled the same way as TV_Vector. So I think it is incorrect to say "only if you have the CLIC extension". CLIC extension is defined as just another mtvec mode which is labeled Reserved in the current priv spec.

Copy link
Collaborator

@jrtc27 jrtc27 Mar 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well there's a bit of a distinction though. Direct and Vectored are both specified as what mtvec.BASE=0/1 mean, with >=2 reserved. Whereas this CLIC encoding is specified in its own extension on top of the base privileged spec. That is, the philosophical distinction is that vectored is part of the base privileged spec but may not be supported, whereas CLIC support is its own named extension on top.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants