Hi, Alan. My proposal is still a work in progress, hence has not been shared publicly, but is significantly based on a proven architecture with about 30 years in the field and a few billion shipping

Bill, Hopefully my last email also answers your question. Greg

Alan, Hi. Comments below. At this surface it isn't, but in practice it is or wants to be for the following reasons: - One wants the 'Active' state to be with all the other state of a counter so that

Comments below: Switches to/from Bare mode should be rare. Typically one will switch from Bare mode to a translated mode as part of booting up an OS (e.g. Linux), and then will remain in that mode

Hi Greg, My sense is that the transitions from SvXX to Bare and from Bare to the same SvXX that was previously in force are special transitions. One reason seems to me the extreme simplicity of Bare

Brian, I'm curious whether the 'marked' bit is a significant improvement on the mcountinhibit CSR, which could be swapped to enable counters for multiple processes. Bill On 7/20/20 1:54 PM,

Hi Greg, Questions: - Is Active (bit[31]) any different from the inhibit register, functionally speaking? - Assume that we are making this HPM as an extension (maybe Zmhpm, Zshpm?). How is it possible

I would like to get people's views on the question of when is an sfence.vma required after changing the satp.mode field (to see what support there is for the following change/clarification in the

It's nice to see people starting to get serious about addressing this long standing issue. We (Ventana) also worked out a proposal for these issues - that is more in the vein of what Brian mentioned

It was just so poorly rendered in my mail client, so please forgive my spam. Hi Brian, > I have been working on a similar proposal myself, with overflow, interrupts, masking, and delegation. One of

Hi Brian, Thanks for sharing your experience and the elaboration. The overloading-hpmevent idea looks like the one in the SBI PMU extension threads in Unix Platform Spec TG by Greg. I have a bunch of

I had thought about reserving config bits in hpmevent as well, but thought that it would not be backwards compatible then. In practice, it might be (in practice, I suspect the MSU bits are already

I have been working on a similar proposal myself, with overflow, interrupts, masking, and delegation. One of the key differences in my proposal is that it unifies each counter's configuration control

Hi all, This proposal is a refinement and update of a previous thread: https://lists.riscv.org/g/tech-privileged-archive/message/488. We noticed the current activities regarding HPM in Linux

mcycle is considered part of the HPM facility. If the clock to the core is not running, mcycle does not need to increment. If part of the core is being clocked (including just mcycle), then mcycle can

Hi, The mcycle CSR is described in the RISC-V Privileged Architecture spec as: What does 'clock cycles executed by the processor' mean in the context of a WFI instruction? For example, if a core is

Yes: X (our implementation conforms to this constraint or implements XLEN bits) roger.

Also a good implementation approach - adding a second variation to what WARL compliance testing would probably need to allow for. At the end of the day, with both the "1-bit" and "2-bit" schemes, one

One could view the effect of MPRV as changing the mode that is in effect for a memory access. For *tval purposes that end result is all that matters. Ditto for the new-ish HLV/HLVX/HSV

The Rocket approach works here if you set the width of mtval to 1+max(VAbits,PAbits) and then sign-extend from the most-significant implemented bit. The extra 1 bit allows for zero-extension of PAs.