To clarify, my point was that the proposed "mask on read" mandate is no different than mandating that WARL fields must be legalized on read and not on write. Mandating "legalize on read" (or

Could you give an example of the kind of timing critical operation? What I was thinking of was the added delay from clock to CSR output, and if the next instruction has a dependency hazard on that,

If I understand it correctly, the proposal states that the csr value must be updated as usual by csrw and normalized according to the r/w qualifier on read. The argument is that since there exists at

Greg beat me to it; the case where a WARL mapping becomes illegal has concerned me for a while. OR when an illegal value is written, but writing another CSR would have made that original value legal -

The current Priv spec effectively allows implementation flexibility (for better or worse) and it's quite reasonable to expect that some implementations answered this question one way, other

Hi Privileged ISA group, There's been a longstanding shortcoming in the RISC-V Privileged ISA document that it doesn't precisely explain what may happen when one CSR controls the writability of bits

I personally equated availability to tolerance of errors i.e. mechanism that would help minimize the impact of an error and avoid unplanned downtime as much as possible. These mechanisms may provide

As you rightly pointed out monitoring or allocation of resources requires a way to identify the originator of the request. Traditionally, as the request proceeds downstream through the network of

The scontext and hcontext registers from the Debug spec also serve a similar function as process/context identifier. Maybe there is some synergy there.

A good paper on this topic is "Per-Thread Cycle Accounting in Multicore Processors" https://dl.acm.org/doi/pdf/10.1145/2400682.2400688

There is already a process identifier defined in the architecture (ASID) though it is local and not global across a system. I vaguely remember that the IOMMU and/or IOPMP proposals make use of

Vedvyas, Thank you. We have a RAS committee on the org and approved by the BOD but has not been formed and QOS is one part of what it was intended to look at (as part of availability). I wonder if we

Greeting all, I would like to start a discussion on supporting QoS capabilities in RISC-V architecture. I hope I am posting on the right list/TG/HC. First, a short background: Quality of Service

We have a new revision of our IOMMU spec. The Latex source is available on github for readers to find out the changes more easily moving forward. https://github.com/sqzsq/xuantie-iommu-spec Also you

Totally agree its not just a matter of writing a larger specification. My observation in this specific case was that its not creating fundamentally new architecture. The CSR we discussed would

Over the past year RVI (the TSC especially) has clearly moved towards expecting extensions to be developed as smaller separate extensions instead of being glommed together in longer development

Ordinarily I'd recommend against the duplication of information, but I've got to agree this information would be more usefully presented next to the description of the counters than at the description

Fair enough. But it would be nice to have the full definition of instret in one place. To discern that instructions that cause exceptions don't increment the counter requires reading the

I don't argue against a non-normative clarification, but a direct literal reading of the RV text (i.e. only completed/retired instructions are counted) leaves no ambiguity. Taking an interrupt or an

Exactly. Even if the after-effect of an instruction is to establish a new execution context for the target or next instruction, the instruction itself is considered as being fetched/decoded/executed