(idea from sorear on IRC #riscv)
The 53000 was originally designed prior to v1.9 priv spec, and thus is currently designed to offer an M-mode only environment for software to run in. However, this makes drop-in CPU upgrades difficult without also replacing the system software to match the new CPU. To improve the ability to upgrade a Kestrel-3 design, the processor should be built around an all U-mode design. This lets a superior processor architecture emulate the base configuration Kestrel-3 using a combination of delegated interrupts and traps, and perhaps paging to simulate the address space.
New CPU modules can come with M-mode code intended to provide an abstraction layer for the existing U-mode firmware and software, allowing portability between the 53000 and, say, a Rocket or BOOM core, for instance, without requiring any recompiles of Forth, Oberon, or whatever else is in Kestrel-3's firmware.
(idea from sorear on IRC #riscv)
The 53000 was originally designed prior to v1.9 priv spec, and thus is currently designed to offer an M-mode only environment for software to run in. However, this makes drop-in CPU upgrades difficult without also replacing the system software to match the new CPU. To improve the ability to upgrade a Kestrel-3 design, the processor should be built around an all U-mode design. This lets a superior processor architecture emulate the base configuration Kestrel-3 using a combination of delegated interrupts and traps, and perhaps paging to simulate the address space.
New CPU modules can come with M-mode code intended to provide an abstraction layer for the existing U-mode firmware and software, allowing portability between the 53000 and, say, a Rocket or BOOM core, for instance, without requiring any recompiles of Forth, Oberon, or whatever else is in Kestrel-3's firmware.