search

riscv / riscv-isa-manual

RISC-V Instruction Set Manual
https://riscv.org/
Creative Commons Attribution 4.0 International
3.72k stars 647 forks source link

Reference pseudo-code for complex HW events #364

Closed avpatel closed 5 years ago

avpatel commented 5 years ago

It will be very helpful to HW designers, simulator/emulator developers, and hypervisor developers if we have a separate section in RISC-V privilege spec providing reference pseudo-codes for complex HW events such as trap and trap return.

These reference pseudo-code will show a order/sequence for HW-state change when a complex HW event such as trap or trap return happens. Of course, HW designers can do things differently to optimize as long as end-result is same.

Here are few reference pseudo-codes which I came-up with based on my limited understanding...

PC == Current program counter MODE == Current mode (M/HS/U/VS/VU) V == Current virtualization state (1 == inside VM and 0 == not inside VM)

Trap taken into M-mode (M/HS/U/VS/VU ==> M)

1)  S<xyz> <=> BS<xyz> (only for MODE == VS or MODE == VU)
2)  MEPC <== PC
3)  PC <== MTVEC
4)  MCAUSE <== Exception cause
5)  MTVAL <== Trap value
6)  MSTATUS.MPP <== 1 (V == 1 and MODE == VS) or
            0 (V == 1 and MODE == VU) or
            3 (V == 0 and MODE == M) or
            1 (V == 0 and MODE == HS) or
            0 (V == 0 and MODE == U)
7)  MSTATUS.MPIE <== MSTATUS.MIE
8)  MSTATUS.MPV  <== V
9)  MODE <== M
10) V <== 0

Trap return from M-mode using MRET (M ==> M/HS/U/VS/VU)

1)  V <== MSTATUS.MPV
2)  MODE <== VS (MSTATUS.MPV == 1 and MSTATUS.MPP == 1) or
         VU (MSTATUS.MPV == 1 and MSTATUS.MPP == 0) or
         M  (MSTATUS.MPV == 0 and MSTATUS.MPP == 3) or
         HS (MSTATUS.MPV == 0 and MSTATUS.MPP == 1) or
         U  (MSTATUS.MPV == 0 and MSTATUS.MPP == 0)
3)  MSTATUS.MIE <== MSTATUS.MPIE
4)  PC <== MEPC
5)  S<xyz> <=> BS<xyz> (only for MODE == VS or MODE == VU)

Trap taken into HS-mode (VS/VU/HS/U ==> HS)

1)  S<xyz> <=> BS<xyz> (only for MODE == VS or MODE == VU)
2)  SEPC <== PC
3)  PC <== STVEC
4)  SCAUSE <== Exception cause
5)  STVAL <== Trap value
6)  HSTATUS.SP2P <== SSTATUS.SPP
7)  SSTATUS.SPP <== 1 (V == 1 and MODE == VS) or
            0 (V == 1 and MODE == VU) or
            1 (V == 0 and MODE == HS) or
            0 (V == 0 and MODE == U)
8)  SSTATUS.SPIE <== SSTATUS.SIE
9)  HSTATUS.SP2V <== HSTATUS.SPV
10) HSTATUS.SPV  <== V
11) MODE <== HS
12) V <== 0

Trap return from HS-mode using SRET (HS ==> VS/VU/HS/U)

1)  V <== HSTATUS.SPV
2)  MODE <== VS (HSTATUS.SPV == 1 and SSTATUS.SPP == 1) or
         VU (HSTATUS.SPV == 1 and SSTATUS.SPP == 0) or
         HS (HSTATUS.SPV == 0 and SSTATUS.SPP == 1) or
         U  (HSTATUS.SPV == 0 and SSTATUS.SPP == 0)
3)  HSTATUS.SPV <== HSTATUS.SP2V
4)  SSTATUS.SIE <== SSTATUS.SPIE
5)  SSTATUS.SPP <== HSTATUS.SP2P
6)  PC <== SEPC
7)  S<xyz> <=> BS<xyz> (only for MODE == VS or MODE == VU)

Trap taken into VS-mode (VS/VU ==> VS)

1)  SEPC <== PC
2)  PC <== STVEC
3)  SCAUSE <== Exception cause
4)  STVAL <== Trap value
5)  SSTATUS.SPP <== 1 (V == 1 and MODE == VS) or
            0 (V == 1 and MODE == VU)
6)  SSTATUS.SPIE <== SSTATUS.SIE
7)  MODE <== VS
8)  V <== 1

Trap return from VS-mode using SRET (VS ==> VS/VU)

1)  MODE <== VS (V == 1 and SSTATUS.SPP == 1) or
         VU (V == 1 and SSTATUS.SPP == 0)
2)  SSTATUS.SIE <== SSTATUS.SPIE
3)  PC <== SEPC
jscheid-ventana commented 5 years ago

I agree that pseudo-code specification style would be an improvement. Given the existence of the formal modeling effort, would direct reference to an "official" complete formal model, either the source or possibly some generated presentation thereof, be suitable?

I made a very quick search for equivalents to your first blurb in the source of formal models that implement traps:

aswaterman commented 5 years ago

The plan is for the formal models to address this need, rather than including this kind of thing in the English spec.

tommythorn commented 5 years ago

Well, IMhO it belong in the spec and it should have been written like this from the beginning. There are a lot of ambiguity in the English prose that shows up again and again. Rather than waiting for the perfect four formal specs, I'd much rather see us incrementally move to a more explicit spec and have the formal spec be complementary.

FWIW, I don't think the formal spec serves exactly the same purpose. The formal specs come with their own formalism that require a new level of interpretation whereas Anup's style is somewhere between the freewheeling english prose and a machine comprehensible formal spec.

Tommy

On Mon, Apr 8, 2019 at 9:54 AM Andrew Waterman notifications@github.com wrote:

The plan is for the formal models to address this need, rather than including this kind of thing in the English spec.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-manual/issues/364#issuecomment-480913415, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0pmKhgXxxBe9mdjB7fOAlzs0akkO3Gks5ve3RXgaJpZM4chkgP .

avpatel commented 5 years ago

The set of pseudocodes in RISC-V spec don't need to be very detailed like the formal spec but it should give high-level idea about the sequence of HW state changes for functional correctness.

kasanovic commented 5 years ago

The formal spec will be used to document this exactly, and is designed to be human-readable.