Performance Counters: event selectors not implemented?

[RTLhamster]

Hi there, according to the IBEX documentation the performance counter behaviour of mhpmcounter3 to mhpmcounter31 can be configured by mhpmevent3 - mhpmevent31 register: ibex-core.readthedocs.io

Observed Behavior

writing to register mhpmevent3 has no effect on counting behaviour of mhpmcounter3

Expected Behavior

mhpmevent3 should select the event to count e.g. NumCycles ...

Steps to reproduce the issue

I've set verilog parameter MHPMCountersNum to 1 (only mhpmcounter3 is implemented), MHPMCountersWidth = 32

In my Software something like that:

unsigned int get_mhpmcounter3 () {
  uint32_t result;
  __asm__ volatile("csrr %0, mhpmcounter3;" : "=r"(result));
  return result;
}

void set_mhpmevent3 (int val){
   asm volatile("csrw  0x323, %0\n" : : "r"(inhibit_val));
}

..... in main.c:

pcount_reset():                     // reset counters
set_mhpmevent3 (0x0001);  // set counter to count NumCycles
pcount_enable(1);                // enable counters->can you please check: mcountinhibit = 0 means enable, why?
unsigned int res = get_mhpmcounter3 ();

If I comprare counter3 and mcycle they are totally different, counter3 reads 20 and mcycle 320621 in my testcase.

I checked the RTL code (ibex_cs_registers.sv): the selection via mhpmeventXX doesn't seem to be implemented. mhpmcounter_incr[] seems to be hard-wired to inputs.

My Environment

EDA tool and version: Cadence SimVision 21.09-s001

Operating system: CentOS Linux 7

Version of the Ibex source code: 8faf3198fa521c803046b6bd5baf22a1c240f149 no changes to code

[vogelpi]

Hi @RTLhamster , thanks for your question. The reported behavior is inline with the RISC-V priviledge spec (see Section 3.1.10). In particular the spec says:

The event selector CSRs, mhpmevent3–mhpmevent31, are MXLEN-bit WARL registers that control which event causes the corresponding counter to increment. The meaning of these events is defined by the platform, but event 0 is defined to mean “no event.” All counters should be implemented, but a legal implementation is to make both the counter and its correspond- ing event selector be read-only 0.

WARL stands for write-any read-legal, which means an implementation can support configurable mhpmevent registers but it doesn't have to. It is perfectly fine to have hardcoded mhpmevent registers. I couldn't find the section in the Ibex documentation stating that the mhpmevent CSRs in Ibex are indeed configurable. If you can point me to that, I will fix it. Because as you found out yourself this is clearly not what is implemented.

The mhpmevent registers in Ibex are not configurable because so far we didn't have the need for configurable mhpmevent registers. If you want, you can implement it and push a PR. However, one has to be a bit careful because depending on how much flexibility you want, it can result in a lot of area.

[RTLhamster]

Hi @vogelpi, thank you for your explanation.

Well its kind of miss leasing to have a section heading "Event Selector" if the counters are actually not selectable.

In terms of area: I think the current implementation its not a great solution. E.g. If you want to count NumCyclesMulWait, then you have to enable 9 counters to have this particular event counted. At least for ASIC it result in much larger area, compared to 1 selectable counter (in my opinion).

[GregAC]

You could always rearrange the counters to suit your requirements. It's all implementation defined so there's no harm in you changing the numbers.

Remappable event counters is certainly something worth exploring it just hasn't been a priority for us thus far.