Coprocessor / custom function unit interface

[tcal-x]

Potentially interesting project: adding an interface so that the user can attach their own function unit(s) for handling instructions in the RISC-V CUSTOM0 / CUSTOM1 opcode space. For example, PicoRV32 has PCPI.

[mithro]

@BrunoLevy - Doing this potentially means FemtoRV could be an alternative CPU option for usage in the CFU Playground (http://cfu-playground.rtfd.io/). It looks like FemtoRV is already an option in the LiteX ecosystem?.

[Mecrisp]

@tcal-x Yes, PicoRV32 has PCPI, but I vote against the idea - the FemtoRV32 cores are meant to be easy to modify, and I would encourage anybody who wishes to add their own instructions to pick one and add it to the processor itself.

[BrunoLevy]

Hi @tcal-x, @mithro, @Mecrisp,
It is a complicated desgin decision, but I think we will not do that (because I fully agree with @mescrisp). Here are some explanations for that:

We tried different designs for FemtoRV, and we think that a compact single-file/simple/non-generic design is a big plus (initially the first FemtoRV had multiple modules, then @Mecrisp redesigned it, and it gained a lot, both in terms of legibility and efficiency / LUT usage). Then we have a RV32I core that fits in (approx.) 100 lines of VERILOG code, and it's good for the students who read it: they can have a quick overview of it without having to browse multiple files. When you dive into somebody else's design, the "mental cost" of having multiple files / multiple modules is important (of course, it is necessary if the design is super complicated, but I do not think that the size of the different FemtoRV cores reach the "need for modularization" threshold.

In the end, I find it better to have several single-file versions of the whole design (quark, electron, intermissum, gracilis...) rather than assembling them from individual components, because with the second option, the proportion of interface/glue code/administration dominates over the code that implements the functionalities. Another aspect is that multiple modules sometimes constrain the design too much, for instance when you need to draw a wire between two different functional units: I think it is not very clear where the limits of the functional units should be, and whenever a decision is taken for that, there is always a good reason to change that decision a few weeks after (at least it is my own experience !)

I made an exception for the FPU though, because it is a really a big functional unit (even bigger than a complete RV32IMCZcsr core), but even for that part it is still unclear to me, for instance, should the FPU registers go in the FPU (sounds logical) or in a single bank shared with the integer code (will facilitate implementing ZFinx)? Should the FPU control register be in the FPU (sounds logical) or with the other CSRs (much more convenient to implement the CSR manipulation instructions)? With a single-file / single-module design, you do not have to bother with these questions and it is good: the functional units go in the always() blocks where it is easier to manipulate them (but well, my FPU is in a separate module for now... we'll see whether it will be re-merged with the version of the CPU that uses it or kept separate...)

Maybe what we can do is writing a tutorial that explains how to extend a femtorv32 core, what do you think ?