Machine mode indicator

[szbieg]

Expose to the output ports whether the core is running in user or machine mode

solves #8

[christian-herber-nxp]

I am thinking if there shouldnt be two different signal. 1, the mode. 2, the effective mode.

privilege can be different for fetches and for data accesses, if mstatus.MPRV is set.

[szbieg]

resolves #8

[davideschiavone]

I am thinking if there shouldnt be two different signal. 1, the mode. 2, the effective mode.

privilege can be different for fetches and for data accesses, if mstatus.MPRV is set.

hi @christian-herber-nxp , what do you mean effective mode or just mode?

when you change mode to be sure 100% nothing in flights (newer than the change mode instruction) you should clear the internal instruction buffer filled by the prefetcher, and before changing the mode, flush the pipeline (e.g. if there are in flights loads/stores)

The cv32e2 pipeline should not have anything inflight from the ld/st viewpoint as 2 pipeline stage, so no issues in that part, but it won't be true from the pre-fetching part - one simple solution would be to make this specific instruction JUMP to the next instruction (PC+4) as jumping fetches the instruction from the memory, hence, the new fetch will come with the updated privilege mode).

But this won't belong to this PR, it would rather be a bug (like bug: PMP did not allow for instruction XYZ to be executed, and it has been executed)

[christian-herber-nxp]

I am thinking if there shouldnt be two different signal. 1, the mode. 2, the effective mode.
privilege can be different for fetches and for data accesses, if mstatus.MPRV is set.

hi @christian-herber-nxp , what do you mean effective mode or just mode?

when you change mode to be sure 100% nothing in flights (newer than the change mode instruction) you should clear the internal instruction buffer filled by the prefetcher, and before changing the mode, flush the pipeline (e.g. if there are in flights loads/stores)

The cv32e2 pipeline should not have anything inflight from the ld/st viewpoint as 2 pipeline stage, so no issues in that part, but it won't be true from the pre-fetching part - one simple solution would be to make this specific instruction JUMP to the next instruction (PC+4) as jumping fetches the instruction from the memory, hence, the new fetch will come with the updated privilege mode).

But this won't belong to this PR, it would rather be a bug (like bug: PMP did not allow for instruction XYZ to be executed, and it has been executed)

I think we are not quite in sync. My point is, that if mstatus.MPRV = 1, loads/and stores use a different privilege level than instruction fetches. At this point, there is no PMP. The ibex PMP is integrated, so i would expect this solves it.

But exposing the privilege level to the busses is a more complicated thing, because you dont know what checks to expect.
Goal is to have the correct HPROT settings on the AHB, and for that you need to potentially know the effective privilege, if it applies.

[christian-herber-nxp]

I had a look into the OBI spec (probably should have done this before).
I think what we really need is simply adding the prot[] signal. This would solve it.

[christian-herber-nxp]

Conclusions from meeting

1. We need a privilege mode exposed per OBI interface. Data accesses need to follow the effective privilege mode as per privileged specification, section Memory Privilege in mstatus Register
2. The privilege mode should be exposed in an OBI compliant way

Definition from OBI spec:

[christian-herber-nxp]

change needed to:

• have prot[] signal for each OBI interface
• prot based on effective privilege level for the data interface

[MikeOpenHWGroup]

Hi @davideschiavone, can you review the latest update by @szbieg?

[davideschiavone]

• have prot[] signal for each OBI interface
• prot based on effective privilege level for the data interface

I still do not see what @christian-herber-nxp requested here:

have prot[] signal for each OBI interface
prot based on effective privilege level for the data interface

[szbieg]

The aim of this task is to expose privilege (effective) level status. OBI interface will be connected to those exposed signals, and as such is already covered in task #70. @davideschiavone please clarify what exactly do you expect to see if not the exposed privilege mode.