Replace performance counters with Hardware Performance Monitor

[silabs-PaulZ]

The following change was approved by the OpenHW Core Task Group:

Replace existing performance counter implementation with the Hardware Performance Monitor specified in the privileged architecture.

Access to an existing performance counter will be removed:

• PCMRs,
• PCERs,
• PCCRs No longer support external events

Specific feature details that were not fully discussed are now mentioned in this issue :

• All counters shall be 64bits.
• MCYCLE and MINSTRET shall always be implemented and available
• The number of MHPMCOUNTERs (and corresponding MHPMEVENTs) registers shall be parameterizable with a top level parameter, NUM_MHPMCOUNTERS
  • default value of 1
  • range between 1 and 29
  • Access to non-implemented MHPMCOUNTER and MHPEVENT shall be allowed and will always return a read value 0
• MCOUNTEREN and SCOUNTEREN shall not be implemented, as these WARL registers control access to lower privilege modes and shall return a value of 0 when read (it will not cause an illegal instruction)
• MCOUNTINHIBIT shall be implemented to disable/enable counting of each counter
• The MHPMEVENT will each have 15 bits, allowing for the selection of the following monitor counting options (matches existing PCCR count types):

Index	Name	Description
0	CYCLES	Counts the number of cycles the core was active (not sleeping)
1	INSTR	Counts the number of instructions executed
2	LD_STALL	Number of load data hazards
3	JR_STALL	Number of jump register data hazards
4	IMISS	Cycles waiting for instruction fetches, i.e. number of instructions wasted due to non-ideal caching
5	LD	Number of data memory loads executed. (Misaligned accesses are counted twice)
6	ST	Number of data memory stores executed. (Misaligned accesses are counted twice)
7	JUMP	Number of unconditional jumps (j, jal, jr, jalr)
8	BRANCH	Number of branches. (Counts taken and not taken branches)
9	BTAKEN	Number of taken branches.
10	RVC	Number of compressed instructions executed
11	FP_TYPE	Cycles wasted due to different latencies of subsequent FP-operations
12	FP_CONT	Cycles wasted due to contentions at the shared FPU (PULP only)
13	FP_DEP	Cycles wasted due to data hazards in subsequent FP instructions
14	FP_WB	Cycles wasted due to FP operations resulting in write-back contentions

[Silabs-ArjanB]

FPGA synthesis `define may be used to increase the default count to the maximum allowed

I have had complaints about this feature in the current design. Personally I also think that we should not reconfigure modules just because the core is mapped onto FPGA. If FPGA users want a different configuration they should simply explicitly use the top level parameters to configure the core as they want (and not rely on a non-obvious side effect of ifdef FPGA)

[Silabs-ArjanB]

What will the external (top level) interface look like?

[silabs-PaulZ]

Based on some feedback, I propose we remove the external event counters and also make the number of MPHCounters parameterizable with no FPGA `define.

I will modify the original ticket description comment. Even though the comment history is kept, the changes are listed below for convenience.

• Remove the following events from MPHMEVENT 11: LD_EXT, 12: ST_EXT, 13: LD_EXT_CYC, 14: ST_EXT_CYC, 15: TCDM_CONT, 16: CSR_HAZARD.
• Remove FPGA define
• Change NUM_MHPMCOUNTERS from localparam to top level parameter from 1 to 29

[davideschiavone]

I agree that the external perf counters should be memory mapped, thus readable and writable with load and stores and not mapped to the CSR space. Rather than removing the LD_EX, ST_EX we should move them to NUM_MHPMCOUNTERS ? Is that correct?

Best Davide

[silabs-PaulZ]

Yes, these 'could' be part of the HPM Counters (mhpmcounter[]). There is a corresponding HPM Event register (mphmevent[]) that selects which events will increment each counter (similar to PCER, but per counter).

These external events were brought in through an external port that was removed.

I would prefer that we do not bring in external events.

But, if needed, it would be fairly easy of course. My concern then would be that the external events are user selectable, meaning they could hook up anything, not just a LD_EX (presumably LoaD EXternal). We would add the port and extend the event register with names such as EXT0, EXT1, EXT2, EXT3. If needed, can we create a separate issue/pull request?

[Silabs-ArjanB]

Agreed to not implement EXT0, EXT1, EXT2, EXT3 at the moment. External events can be added on a future core if users request it.

[Silabs-ArjanB]

We are closing this issue as it either has been fixed with the stated (merged) pull request, because it is no longer valid, or because a follow up question for further clarification or feedback remained unanswered for at least 7 days. Please do not hesitate to re-open this issue if you do not agree that the issue has been handled satisfactorily or if you have further questions.