memory mapped control registers

[Allen Baum]

Spec section 3.2.1 define 2 memory mapped control registers, mtime and mtimecmp.

But, section 3.1.9 defines a 3rd (which is nameless for some reason), that if written (with undefined value) will signal a software interrupt, or clear a software interrupt.

Bits mip.MSIP and mie.MSIE are the interrupt-pending and interrupt-enable bits for machine-level

software interrupts. MSIP is read-only in mip, and is written by accesses to memory-mapped control

registers, which are used by remote harts to provide machine-level interprocessor interrupts. A hart

can write its own MSIP bit using the same memory-mapped control register. If a system has only one

hart, or if a platform standard supports the delivery of machine-level interprocessor interrupts through

external interrupts (MEI) instead, then mip.MSIP and mie.MSIE may both be read-only zeros.

Why is this not mentioned in section 3.2.1?

(because it is optional if mip.MSIP nd mie.MSIP are readonly0?)
Because the format is not architecturally defined?

likewise, section 12.1.3 hints at an smode version of SSIP, but in more nebulous manner:

is set and cleared by the execution environment, typically through a platform-specific interrupt controller.

[Greg Favor]

On Mon, Apr 7, 2025 at 4:10 PM 'Allen Baum' via RISC-V ISA Dev <isa...@groups.riscv.org> wrote:

Spec section 3.2.1 define 2 memory mapped control registers, mtime and mtimecmp.

But, section 3.1.9 defines a 3rd (which is nameless for some reason), that if written (with undefined value) will signal a software interrupt, or clear a software interrupt.

Bits mip.MSIP and mie.MSIE are the interrupt-pending and interrupt-enable bits for machine-level

software interrupts. MSIP is read-only in mip, and is written by accesses to memory-mapped control

registers, which are used by remote harts to provide machine-level interprocessor interrupts. A hart

can write its own MSIP bit using the same memory-mapped control register. If a system has only one

hart, or if a platform standard supports the delivery of machine-level interprocessor interrupts through

external interrupts (MEI) instead, then mip.MSIP and mie.MSIE may both be read-only zeros.

Why is this not mentioned in section 3.2.1?

(because it is optional if mip.MSIP nd mie.MSIP are readonly0?)
Because the format is not architecturally defined?

Because the Sm1p1x architecture does not specify the specifics of such memory-mapped control registers, nor does it even require any such thing.  It is just saying in high-level terms how MSIP is written, while it chooses to not specify the specifics of those registers and it even allows for there to be nothing that writes MSIP.

In both the case of MSIP and SSIP, the Sm1p1x architecture is only specifying part of an overall software interrupt capability and is choosing to leave a lot of flexibility (for custom and/or RISC-V standard implementations).

A couple or so years ago there was an attempt to standardize one such memory-mapped register mechanism (based on what Si-Five had done in its early years), but that effort ultimately fell by the wayside with AIA coming into the picture (which chose to provide a software interrupt capability that didn't come through the *SIP bits).

Greg

 

likewise, section 12.1.3 hints at an smode version of SSIP, but in more nebulous manner:

is set and cleared by the execution environment, typically through a platform-specific interrupt controller.

 

--
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 visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAF4tt%3DCGOEqT77UX_Uqj-dfuCc-bqMdN%2BQBN96L7YKzts0Yajg%40mail.gmail.com.

[Allen Baum]

That merely says that the format & semantics are implementation specific.

 But that doesn't quite answer the question about why section 3.2.1 doesn't mention it at all. 

It is mentioned in the spec as what is required if SWI is supported, and SWI is defined and has bits reserved for it - just as it is for timer interrupts. The only difference is that mip.MTIP and mie.MTIP are writable, and MSIP bits are allowed to be read-only zero.

 If MSIP bits are allowed to be RW (which is one of the many unnamed, defined architectural options), then architecturally, there must be a memory-mapped location that will cause the MSIP bit to be set if accessed in some implementation defined way. 

It says nothing about whether the access must be a write, that a write has to have some specific value, just that it exists at some implementation-defined address. 

[Greg Favor]

On Tue, Apr 8, 2025 at 3:09 PM Allen Baum <allen...@esperantotech.com> wrote:

That merely says that the format & semantics are implementation specific.

 But that doesn't quite answer the question about why section 3.2.1 doesn't mention it at all. 

It is mentioned in the spec as what is required if SWI is supported, and SWI is defined and has bits reserved for it - just as it is for timer interrupts. The only difference is that mip.MTIP and mie.MTIP are writable, and MSIP bits are allowed to be read-only zero.

 If MSIP bits are allowed to be RW (which is one of the many unnamed, defined architectural options), then architecturally, there must be a memory-mapped location that will cause the MSIP bit to be set if accessed in some implementation defined way. 

It says nothing about whether the access must be a write, that a write has to have some specific value, just that it exists at some implementation-defined address. 

In short (for better or worse), the arch spec way back many years ago chose to not standardize how software interrupts between harts are generated.  I can't speak for the authors' thoughts way back then, but I expect it was to allow system flexibility.  And, as it has turned out, no memory-mapped register approach has been standardized since then and instead an alternative approach based on AIA has been standardized.  Although along the way there have been some popular non-standard ways like the CLINT/ACLINT.

Greg

[Allen Baum]

Maybe my question is too subtle for my own good.

I don't care whether there is a standardized memory mapped approach for software interrupts.

Standardization is irrelevant.

I do care that there is this statement in the spec 

 Sec 3.1.9: "MSIP is read-only in mip, and is written by accesses to memory-mapped control

registers, which are used by remote harts to provide machine-level interprocessor interrupts."

This says that if you have software interrupts, then Machine-Level memory-mapped register(s) ared used to control it.

This matches mtime and mtimecmp, yet it isn't mentioned in section 3.2 Machine-Level Memory-Mapped Registers 

(but mtime and mtimecmp are).

That seems to be a pretty clear oversight.

[Greg Favor]

On Wed, Apr 9, 2025, 12:15 PM Allen Baum <allen...@esperantotech.com> wrote:

Maybe my question is too subtle for my own good.

I don't care whether there is a standardized memory mapped approach for software interrupts.

Standardization is irrelevant.

I do care that there is this statement in the spec 

 Sec 3.1.9: "MSIP is read-only in mip, and is written by accesses to memory-mapped control

registers, which are used by remote harts to provide machine-level interprocessor interrupts."

This says that if you have software interrupts, then Machine-Level memory-mapped register(s) ared used to control it.

This matches mtime and mtimecmp, yet it isn't mentioned in section 3.2 Machine-Level Memory-Mapped Registers 

(but mtime and mtimecmp are).

That seems to be a pretty clear oversight.

I believe it was intentional for the sort of reasons I mentioned.

Greg