Add mcounteren register

[SamuelRiedel]

This PR adds the mcounteren register, which has so far been tied to zero and implements the U-mode performance counter aliases. The mcounteren register can be locked with an external MUBI signal (mcounteren_writable_i).

DV:
This PR adds two directed tests:

• mcounteren_test goes through multiple configurations of the mcounteren register and validates that u-mode can only access the ones enabled.
• mcounteren_lock_test verifies that the mcounteren CSR cannot be modified without the mcounteren_writable_i signal being set.

To Dos:

• For the directed tests and the cosim to pass, we have to update riscv-isa-sim to also support those performance counters: Enable ZIHPM unpriviledged performance counters riscv-isa-sim#29
• Currently, u-mode counter reads will lead to illegal instruction exceptions. However, we are not gating the value at the CSR module's interface for simplicity. The signal will not leave the core, but we should double-check that this is no security issue.
• The dv/uvm/core_ibex/directed_tests/directed_testlist.yaml changes a lot everytime I regenerate it after even small modifications. This polluted the diff quite a bit. Is this expected?

[gautschimi]

The changes look all good to me! Just a few minor comments. (I did not look at the two WIP commits about formal)

[gautschimi]

should we assign this to zero if the condition below does not match?

[SamuelRiedel]

I was wondering the same. The values currently never make it to the register file because we trap, but we could also gate it to prevent any potential security concerns.

[gautschimi]

what is this buffer used for?

[SamuelRiedel]

I was following the fetch_enable example here, which says to buffer security critical signals to prevent synthesis optimisation removing them.

[gautschimi]

This test is good! It verifies that the counters are accessible or not depending on mcounteren.

Maybe we can add a short test that also verifies that the read values are correct.

[SamuelRiedel]

I can add this, that should not be difficult.

[gautschimi]

did something change in this file (except for the new mcounteren_test)? The diff is big. Did the order of the tests change or was something real added?

[SamuelRiedel]

No, this is what I was also confused about. The order seems to change every time I add a test or even modify the description of the test. This makes it quite hard to check the diff. I was wondering whether someone with more experience with this tool had any insights on this.

[SamuelRiedel]

I disabled the check of the mcounteren CSR in the formal verification for now. Another reason for the failure of the formal verification was that we ran out of memory on the runner that has twice as many cores but half as much memory available. I'll address this in a separate PR and rebase once merged.