[rv_core_ibex] Suggested Address Translation improvements

[alees24]

Description

Background:

The rv_core_ibex logic that wraps the portable Ibex core provides not just TL-UL compatibility for the OT project but also some additional functionality including a simple address translation layer. This translation scheme was originally created to allow one ROM image from a set of images at different physical addresses to be mapped to a fixed logical address, with all images having been built to run at that fixed address.

With Darjeeling the number of regions has been increased to implement the required ROM patching functionality for the second boot ROM.

Darjeeling presently extends the original two regions per access port to 32 regions per port. There are two ports - Instruction accesses and Data accesses - but in order to present consistent views to both Instruction fetches and Data accesses, the same information is programmed into the set of 'D' registers as the 'I' registers.

Additionally, each of the 2 x 32 regions has its own 'EN'able register that holds just a single bit specifying that the region is valid. This is rather wasteful of address space and has limited extensibility.

Proposal:

Replace the sets of 'I' and 'D' registers with a single set of configuration registers that is accessible to both ports, and include two enable bits which may be stored in the 'remap' register:

ADDR_MATCHING[n] 31:0 - Matching address region for both Ibus and Dbus.
REMAP_ADDR[n] 31:2 - Remap address after a match has been made.
1 - Enabled for Data accesses
0 - Enabled for Instruction accesses

This reduces the amount of address space used and allows a larger number of remappings to be accommodated for a given number of configuration registers, since the normal use case will require a remapping to be presented on both the Instruction and the Data buses.

Caveat:

Since this mechanism is already used within Earl Grey and ROM code, it may be necessary to treat the first couple of regions in a manner that is backwards-compatible, depending upon the amount of existing software, hardware and tooling etc that already depends upon their specification/behavior.

[msfschaffner]

In general this sounds like a useful improvement to me as it would save quite a bit of config registers and addresses. It may be possible to accommodate this change as part of the Earlgrey Prod push, but I let the SW folks to speak to the feasibility of the change. @cfrantz @moidx @timothytrippel

[GregAC]

I think this is a very sensible change but my preference is not to do this for Earlgrey PROD simply to minimize changes from ES unless there is a strong preference for this from the software side. With just 2 regions in Earlgrey the original setup still seems reasonable.

For Darjeeling we should definitely implement this proposal.

[cfrantz]

I would like to eliminate the address translation windows in favor of using position independent code. However, in order to be confident about eliminating the windows, we need to have a PIC-capable compiler and take the time to examine the security implications of PIC code.

For Earlgrey-PROD, I concur with @GregAC : we should avoid unnecessary changes.

[msfschaffner]

I agree with the assessment, and since we only use two regions in the Earlgrey configuration, area reduction would only be minor.

Moving to the backlog.