The Kestrel Computer Project 53000 processor is my first, and currently my only, RISC-V processor design. It is a simple, M-mode only RV64I processor design, intended for easy synthesis. By way of analogy, one can think of this processor as a 64-bit CPU on par with a 6502, that can address 16MB of memory, and has a 16-bit data path (similar to MC68000).
However, it does have some issues that need fixing. Some issues are actually bugs, such as misinterpretations of certain bit-fields in various CSRs. Others are performance issues that are long-standing.
Some read-only CSRs, such as
mvendorid, marchid, etc.,
do not contain correct values.
These stem from a prior misinterpretation
of what these registers were intended to hold.
These bugs are not intended to be impactful, and so a next-generation processor should fix them.
The instruction decode and execution units are unified in the 53000 design. The PLA-based instruction decoder makes for a very efficient design from a bus interface perspective; however, it limits the amount of parallelism within the processor that can be exploited while executing instructions. Most ALU instructions typically consumes 3 or 4 clock cycles. Most memory accessors take between 4 and 8 clock cycles, depending on word width transferred.
The lack of a multiply instruction has been a significant pain point over the years. Writing a software multiply routine for each project is error-prone and laborious.
All instructions execute in machine mode, which eliminates any opportunity for resource protection. Even without an MMU, external hardware can still check current CPU state to allow or deny access to hardware resources.
It also has implications with how one decodes the ECALL and EBREAK instructions. For example, in a design with only M-mode, ECALL unconditionally branches into an M-mode handler. However, with machine, supervisor, and user-mode support, an ECALL in U-mode can be handled in S-mode, while an ECALL in S-mode can be handled in M-mode, without expensive software dispatch. This also frees the M-mode software from having knowledge of which S-mode software is currently running.
To address these problems, I came up with the KCP 53010 processor design concept some time ago. This memo documents my current vision.
Note: The KCP 53010 is what the Kestrel-2/EX emulator mainly supports. Support isn't complete; as I write this document, it lacks CSR support. However, it supports M ISA extensions, as well as all three privilege modes.
The 53010 represents a modest yet significant leap forward in RISC-V capability.
Platform-/vendor-specific CSRs will be updated to reflect correct values.
In addition, to support more efficient ECALL handling,
mideleg and medeleg registers will support delegation into supervisor mode.
The 53010 will make use of coarse-grained parallelism in the instruction decode path. Each unit will have its own microcode engine driving that unit asynchronously from all other units. Separating each major unit will be an appropriately-sized queue to absorb differences in completion rates.
An instruction prefetch unit and corresponding queue will essentially cache upcoming instructions to execute.
An instruction decode unit will take the raw instruction stream and translate it into internal microcode addresses for the execution unit.
An instruction execution unit will receive these addresses and dispatch into its microcode.
With this architecture, I do not expect to compete with straight-ahead, pure pipelined architectures. However, compared to the 53000, performance should be enhanced. Moreover, the micro-architecture should prepare us for an eventual migration to more streamlined or advanced micro-architectures in the future.
I expect most ALU instructions typically consumes 1 or 2 clock cycles. CSR instructions will continue to take 3 cycles, since they are inherently read-modify-write in nature.
If the external data path continues to be 16-bits, then we expect byte and half-word memory accesses to take 2 cycles, words 3 cycles, and double-words 5 cycles. Wider external data paths will enable much faster throughputs. A 32-bit path will reduce byte, half-word, and word accesses to just 2 cycles, while double-words will take just 3. Either way, this is a vast improvement over the 8-clock worst case in the 53000 design.
Supporting the M instruction set extension will enable the use of MUL, DIV, and REM instructions without trapping. While these might still take many clock cycles, it should consume significantly reduced time compared to a pure software implementation.
Supporting U-, S-, and M-modes allows each memory reference to be externally qualified. External address decoding logic can use these signals to allow or deny access to a hardware resource. For example, a ROM-emulator might allow S- or M-mode code to write to a bank of RAM sitting in ROM space, while U-mode code has only read-only access. Similarly, hardware to control the power-on status of a computer might allow M-mode code access, but reject S- and U-mode code from changing it.
The 53010 represents the next logical step in the 530x0 family line-up. But what can we expect in a post-53010 world? As usual, the "take it slow and steady" is our guiding principle. Get the simple things working first; move on to more advanced things later.
The biggest bang for the buck would be support for a memory-management unit, possibly with software TLB management. A hypothetical 53020 would probably be the first processor in this line-up to support running Linux, BSD, or Plan 9. This is a high priority feature for the 53020.
Another significant improvement would be support for atomics (A), compressed instructions (C), and at least the option to run floating point (F, D) instruction set extensions. In fact, if we were to run Linux, IMAFDC (aka "GC") is essentially a hard requirement. All of these should be supported by the 53030.
Support for vectors and (if not already supported) hardware page table walk might appear in 53040.
The 53000 has served in its role as the founding member of the Kestrel's RISC-V processor core for many years. However, the needs of the Kestrel-2/EX now requires we move on. Hopefully this roadmap memo will help serve as a guide for future processor developments.