IOMMU: We await an updated draft and hope to provide final review very soon. Zc*: Recently proposed names for the new instruction formats have been approved with light modification. WFMI: The question

Zicond (fast-track): Final encodings were approved. PR's are being created to provide selected edits to the extension description and to move the DVI text from non-normative to normative text. The

I agree. Bottom line is we need the spec owner to chime in and ideally update the spec so it is more clear which will prevent further questions down the road, hopefully reducing the spec owners

I note Spike goes for the occasionally update time shadow value via a backdoor option I brought up in my reply to Nick:

I guess I am going by the non-normative comment and whilst non-normative comments cannot alter/introduce architecture presumably they cannot suggest anything that explicitly goes against the

I still have concerns with "* It is permissible to implement 'time' by always trapping (regardless of U or M mode execution of the access), leaving an M-mode trap handler to take care of things" What

Thanks for the discussion everyone, I think I've got the answers I need now, in conclusion: * mcycle and minstret are mandatory (If implementing Sm). * Going by latest specification drafts (latest

I agree that mtime et al. seem to be required by Sm. I would support a PR to clarify that Sm does not imply Zicntr. It may be as simple as adding the words "if implemented". I admit I don't know the

We are not responsible for SW bugs - and that's clearly sa software bug. If it hurts when you do that, don't do that. My understanding is that if it's listed in the spec, then it is required for

> While CSR ops must be atomic, that's pretty easy to do when the CSR is read-only, and the time CSR is in that category. Agreed, I had forgotten time was read-only so time accesses becoming a memory

> I'm not sure I follow your reasoning, would you mind elaborating? > From my reading of the spec, I see no ISA mandate that an M-mode execution environment interface must include the `time` CSR (or

1. Divide is an optional instruction, not a required one, contingent on misa.M==1. 2. While CSR ops must be atomic, that's pretty easy to do when the CSR is read-only, and the time CSR is in that

AR Minutes 1/17/2023 Topics covered in the AR meeting: - Fast interrupts: It was noted that one of the CLIC CSRs had been changed to be read-only, but that the new address was poorly chosen

Hi Greg, I'm not sure I follow your reasoning, would you mind elaborating? From my reading of the spec, I see no ISA mandate that an M-mode execution environment interface must include the `time` CSR

"mtime" resides outside the core (as a memory-mapped register). "time" - as a delayed copy of "mtime" - resides inside the core as a CSR that can be quickly accessed (in implementations that don't do

Agree. I am not sure why “time” was a CSR in the first place. Maybe that is the problem? Defining a CSR that lives outside the core is strange. Jeff

I can see your point. Though whilst I've got nothing concrete to point to in the spec I'd say there is a difference between the 'div' and 'csrr time' instructions in that taking a trap from U-mode to

How is "csrr time" different than "div" in this regard? There was a lot of discussion at some point about whether you could claim M extension compatibility if you trapped and emulated divides in

From an implementers point of view, that means an CSRR of the time CSR could read the Mtime MMIO location (or a local copy if implemented that way_), or it could trap and have Mmode firmware do the

Thanks Greg and Jeff, useful to have my interpretation confirmed by a couple of people. I might put a PR together for the spec to add some clarification around these points. Cheers, Greg