The bit fields of mideleg register

618 views
Skip to first unread message

Vincent Lai

unread,
Jan 5, 2017, 5:48:40 AM1/5/17
to RISC-V ISA Dev
The v1.9.1 privileged specification does not have the bit fields layout of the mideleg register.

So here comes a naive question:

Does the mideleg register contains the following read/write bit fields?

mideleg.MEI
mideleg.MTI
mideleg.MSI


Thanks!

Vincent

Michael Clark

unread,
Jan 5, 2017, 10:35:24 AM1/5/17
to Vincent Lai, RISC-V ISA Dev
The mideleg CSR contains the same bitfield as mip and mie.

BBL actually sets mideleg and medeleg to delegate interrupts and traps to the S-mode.

Since the emulator does not implement H-mode, hideleg and hedeleg are not set, but presumably in a full implementation they would be.

Vincent Lai

unread,
Jan 5, 2017, 9:16:11 PM1/5/17
to RISC-V ISA Dev, laivin...@gmail.com
Michael, thanks for your reply.

I assume mideleg.MEI, mideleg.MTI, mideleg.MSI bit fields cannot be written (or does not exist) because these is a sentence in the v1.9.1 specification which says:

"In systems with three privilege modes (M/S/U), setting a bit in medeleg or mideleg will delegate
the corresponding trap in S-mode or U-mode to the S-mode trap handler."

What is the logical behavior of setting mideleg.MTI bit field? Does it mean delegating machine-mode timer interrupt processing to supervisor-mode?
Put it another way, does it mean setting mideleg.MTI to 1 will let 

sip.STIP get the value of mip.MTIP?
sie.STIE get the value of mie.MTIE?

It is very confusing!


Vincent

Stefan O'Rear

unread,
Jan 5, 2017, 9:38:12 PM1/5/17
to Vincent Lai, RISC-V ISA Dev
On Thu, Jan 5, 2017 at 6:16 PM, Vincent Lai <laivin...@gmail.com> wrote:
> What is the logical behavior of setting mideleg.MTI bit field? Does it mean
> delegating machine-mode timer interrupt processing to supervisor-mode?
> Put it another way, does it mean setting mideleg.MTI to 1 will let
>
> sip.STIP get the value of mip.MTIP?
> sie.STIE get the value of mie.MTIE?

No. ST and MT are separate interrupts. If you delegate MT to S-mode,
it will still be MT but it will become visible in SIE/SIP. "ST" is a
software interrupt, see
https://content.riscv.org/wp-content/uploads/2016/11/riscv-privileged-v1.9.1.pdf#page=40
.

-s

Michael Clark

unread,
Jan 5, 2017, 9:50:00 PM1/5/17
to Vincent Lai, RISC-V ISA Dev
On 6 Jan 2017, at 3:16 PM, Vincent Lai <laivin...@gmail.com> wrote:

Michael, thanks for your reply.

I assume mideleg.MEI, mideleg.MTI, mideleg.MSI bit fields cannot be written (or does not exist) because these is a sentence in the v1.9.1 specification which says:

"In systems with three privilege modes (M/S/U), setting a bit in medeleg or mideleg will delegate
the corresponding trap in S-mode or U-mode to the S-mode trap handler.”


I think there needs to be refinement in the privileged spec with respect to the handling of interrupts.

For example, external interrupts, M, H, S, U (EIP) are defined to be controlled by hardware whereas software interrupts, only M is controlled by hardware and H,S and U (SIP) can be set by software. 

Then there is the delegation mechanism, and how this interacts (or does not interact) with software based delegation.


What is the logical behavior of setting mideleg.MTI bit field? Does it mean delegating machine-mode timer interrupt processing to supervisor-mode?
Put it another way, does it mean setting mideleg.MTI to 1 will let 

sip.STIP get the value of mip.MTIP?
sie.STIE get the value of mie.MTIE?

It is very confusing!


Yes. I think we all need to do a little more work modelling and helping to refine the interrupts section of the privileged spec. 

RISCVEMU (I believe from reading the source) and the sim I am working on unconditionally set {M,S}xIP flags and {M,S}xIE controls whether they are delivered and to what mode. I have code in another branch of the sim I am working on that uses the delegation CSRs but I found that BBL does not set h{e,i}deleg, so it does not work on a system that implements H mode. I’m sending details in another email.

The interrupt part of the specification is a work in progress. I believe many things can potentially be fixed up or emulated in M-mode if the specification changes so that silicon that is out there may be able to be patched in M-mode software. The wording may allow some flexibility with interrupts. We’ll see…

Michael.




On Thursday, January 5, 2017 at 11:35:24 PM UTC+8, michaeljclark wrote:

> On 5 Jan 2017, at 11:48 PM, Vincent Lai <laivin...@gmail.com> wrote:
>
> The v1.9.1 privileged specification does not have the bit fields layout of the mideleg register.
>
> So here comes a naive question:
>
> Does the mideleg register contains the following read/write bit fields?
>
> mideleg.MEI
> mideleg.MTI
> mideleg.MSI

The mideleg CSR contains the same bitfield as mip and mie.

BBL actually sets mideleg and medeleg to delegate interrupts and traps to the S-mode.

Since the emulator does not implement H-mode, hideleg and hedeleg are not set, but presumably in a full implementation they would be.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/bb5c4e4b-1e72-4187-a3fb-0c5043e23805%40groups.riscv.org.

Reply all
Reply to author
Forward
0 new messages