csrrc/csrrs with mip, sip and uip

[ken...@imperas.com]

The Privileged Architecture specification describes special behavior for mip.SEIP as follows:

When mip is read with a CSR instruction, the value of the SEIP bit returned in the rd destination register is the logical-OR of the software-writable bit and the interrupt signal from the interrupt controller. However, the value used in the read-modify-write sequence of a CSRRS or CSRRC instruction contains only the software-writable SEIP bit, ignoring the interrupt value from the external interrupt controller.

The SEIP field behavior is designed to allow a higher privilege layer to mimic external interrupts cleanly, without losing any real external interrupts. The behavior of the CSR instructions is slightly modified from regular CSR accesses as a result.

I think this description needs improvement, because the intent is not fully clear for SEIP, or other bits. In particular:

1. What about other set-pending bits that are writable by software? For example, if the N extension is implemented, how do mip.UEIP and sip.UEIP behave?

2. For which bits does any externally-asserted interrupt contribute to the result seen in rd for csrrc or csrrs? For example, would the external value of mip.SEIP contribute to rd in this case, or is just the software-writable bit value seen?

As a general case, imagine that:

1. A system using the N extension is being used;

2. All interrupts are delegated to their lowest possible privilege level using mideleg and sideleg;

3. All interrupts are disabled;

4. Interrupts MEI, SEI, UEI, MTI, STI and UTI are all asserted externally (so csrr t1, mip returns 0xbb0).

5. No software pending bits are set for these interrupts.

Given the above set up, what value is observed in t1 in each of these cases:

li      t0, 0

csrrc   t1, mip, t0    // t1 = ???

csrrc   t1, sip, t0    // t1 = ???

csrrc   t1, uip, t0    // t1 = ???

(Note that no CSR state is changed by these instructions - only the result in t1 is of interest.)

And given the same set up, which (if any) software-writable bits are set by these instructions:

li      t0, 0
csrrs   t1, mip, t0
csrrs   t1, sip, t0

(In other words, what externally-asserted interrupt signal values are propagated to software-writable bits?)

Thanks.

[Lee Moore]

bump!

Is there anybody who is in a position to clarify this issue, it has now been outstanding for 2 weeks?

[Tommy Thorn]

I think it's a great question and the spec isn't very clear at all.

It was appropriate to send it here, but maybe filing this as an issue against the spec might get the attention of the key people.

Tommy

On Wed, Aug 12, 2020 at 5:08 AM 'Lee Moore' via RISC-V ISA Dev <isa...@groups.riscv.org> wrote:

bump!

Is there anybody who is in a position to clarify this issue, it has now been outstanding for 2 weeks?

--
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 view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/847cbeae-49ce-44ec-9a51-0507ed758a27o%40groups.riscv.org.

[Allen Baum]

The real answer might be whatever the SAIL formal model says, since that is what compliance will check against (some day).

It might be safe to look at it and spike and see if it can be decoded from there.

There is a new policy that will be coming into force as soon as next week that will require at least an acknowledgement of the question within a short time frame (whose length is being argued about).

The intent of the existing wording is clear: Ensure that bits that are both writable by SW and by external events do not lose the external event.

The other intent is implied: writing to the bit is different than setting or clearing the bit

        "...with a CSR[RW] instruction, the value of the SEIP bit returned .... is the 

             logical-OR of the software-writable SEIP bit and the interrupt signal from the interrupt controller.
 

         " the value used in the read-modify-write sequence of a CSRRS or CSRRC instruction contains

          only the software-writable SEIP bit, ignoring the interrupt value from the external interrupt controller. 

I believe I had this discussion with Andrew, and "used" can be replaced with "read" or "returned", since that is the verb used in the immediately previous sentence.

The term "software-writable SEIP bit"  is the value that would have been read had the external interrupt not been signalled.

In your example above, I'm going to assume that all xIP bits are zero, and that the CSR access occurs simultaneously with the interrupt signals.

It is my interpretation that delegation doesn't matter; it affects which mode handles the interrupt, but not which bits get set.

Instead, since xIP CSRs are restricted view CSRs, then only the bits pertaining to the mode being read from are visible.

In the first example , you'd read all zeros in MIP, SIP and UIP, you're returning the current value of MEIP, MTIP, SEIP, STIP, UEIP, UTIP 

and since MEIP, MTIP

  

 A cycle later, the interrupt signal would have set their respective xxIP bits, and you'd read

 - MEIP, MTIP, SEIP, STIP, UEIP, UTIP in MIP

 - only             SEIP, STIP, UEIP, UTIP in SIP,

 - only                                UEIP, UTIP in UIP

obviously, MIP and SIP accesses would be trapped from Umode, and MIP accesses would be trapped from Smode.

 (The privileged spec I have doesn't actually show UIP, UEIP/UTIP,USIP because those don't exist unless the N extension exists (and has been ratified).

In the second example, you're actually forcing a zero into the IP bit, so the first clause takes effect and you'd see the OR:

-            SEIP, STIP, UEIP, UTIP in MIP (because MEIP and MTIP aren't writable)

 - only   SEIP, STIP, UEIP, UTIP in SIP,

 - only                      UEIP, UTIP in UIP

(let the corrections begin)

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAPZiS_4M2-5BM5AvA2go4pqW32G_kGJuXqaUuTfZOunMvGhhiQ%40mail.gmail.com.