Based on the optimization as you mentioned, it is good to me if we have SBI call to get the number of HW and SW counters respectively. If s-mode OS can know the separating numbers, then s-mode OS can

I was suggesting to have fixed ranges for both event types. But I agree that it gets tricky with non-standard implementation specific counters. My concern is that it may increase the booting time.

Hi Atish,

Hi Brian, Please see my reply inline below.. Regards, Anup From: Brian Grayson <brian.grayson@...> Sent: 08 July 2020 06:51 To: Atish Patra <Atish.Patra@...> Cc: zong.li@...; Anup Patel

Is there a reason you are limiting the event to 16 bits? On current designs, the mhpmeventX field is already >16 bits wide. I don't see an easy way to support that with this approach directly. (Or

That's what my understanding as well. Assigning continous counter_idx may put a restriction on M-mode implementation. How about assigning some ranges for software vs hardware counters. May be split

OK, I assume the logical number of counte_idx is sequential and started from zero here, so during initialization of s-mode software, we could get the total number 'N' of counters by

Is there more detail about counter_idx? I was wondering that 1. What is the ordering of logical numbers for HW and SW counters? I think that the logical numbers are assigned by OpenSBI. 2. How to know

Hi All, We don't have a dedicated RISC-V PMU extension but we do have HARDWARE performance counters such as CYCLE CSR, INSTRET CSR, and HPMCOUNTER CSRs. A RISC-V implementation can support monitoring

That sounds good. Greg

Hi Greg, How about having event_idx as XLEN bits wide?? It can be encoded as follows (similar to what you suggested): event_idx[XLEN-1:16] = info event_idx[15:12] = type event_idx[11:0] =

Essentially, Yes. This is a little different that what I had described, but this is equally fine (if not a little simpler). One can eliminate the separate event_info parameter and just have one

Yes, I think this should be 4-steps for HW counters. The last step#3 will be broken down into programming hpmeventX CSR and optional platform specific progamming. Regards, Anup From:

You are correct, 16bit CSR_number is sufficient. I am thinking of using lower 12bit of CSR_number as absolute RISC-V CSR number. This way we can point to any (even implementation specific) CSR as

I agree HPMEVENT CSRs are sufficient for most RISC-V system assuming RV64 will be more common compared to RV32. The M-mode runtime firmware (OpenSBI) will have to deal with implementation specific

Hi Greg, I support your suggestion for re-using hpmeventX CSRs for both selecting and filtering events but I am worried about RV32 because hpmeventX CSRs will be 32bit on RV32. Due to this reason,