Open for a new FemtoRV with exceptions ?

[0BAB1]

Hi,

I was going around the FemtoRV codebase as I really was impressed by the elegance of the designs ! This is very inspiring !

I also noticed the cores support interrupts but not exceptions, which can be very useful when we need to debug things. But maybe you did not introduce it for a reason ?

I would like to participate by adding a core with basic exception support (which would result in adding mtval + some new CSR logic).

Would that be possible,

Best

[BrunoLevy]

Yes, I would like to have a FemtoRVMorph version, that implements some instructions in HW and some instructions in a trap handler.
Would be interesting to create a minimalistic Linux(noMMU) capable core.
We could do that step by step:
Step 1: an RV32I core that implements RV32M in a trap handler

[0BAB1]

I'm not sure what you mean by "an RV32I core that implements RV32M in a trap handler"

What I had in mind was a simple exception handling core that is able to detect ecalls, faulty instructions, branch targets, etc... and give standard insights to the user via standard CSRs to ease the debugging process.

I saw that most of the femtoRV already handle interrupts so you may already have trap handler support and some example programs ? From there, detecting exceptions is mostly a matter of adding some CSR logic and make it compliant to the privileged specs.

To run linux on top of that will be challenge for me as I never did that before though, but I can surely try, it shouldn't be that hard once the hardware is here...

[BrunoLevy]

What I have in mind with "an RV32I core that implements RV32M in a trap handler" is a RV32I core with logic to detect faulty instructions and a ROM that implements the RV32M instructions in the handler. It is interesting because it lets seemlessly move functionalities between hw and sw.

[0BAB1]

e.g. would use ecalls to run some multiplications ?

[yrabbit]

How it worked starting with the most ancient processors used in PDP11 - there might not have been a math coprocessor, but the code still worked as if there was one.

Simply, in the absence of hardware support for floating point commands, an ‘incorrect instruction’ exception occurred, the handler extracted the actual code of the incorrect instruction from the stack information, decrypted it, and called a subroutine from the ROM, which performed the necessary actions and returned control back.

[0BAB1]

I see, but compilers already allows one to compile multiplications for a RV32I target without trap handler's overhead. But I guess performance is not really the issue here, maybe you want to implement make a RV32M target out of a RV32I core so it would make a small core that "technically is a 100% RV32M target" ? @BrunoLevy

[Mecrisp]

Nice to read you here! Back then Bruno and me were thinking of adding an exception on invalid instuctions, with the goal to allow a software handler to emulate these, but I could not find an elegant way to add these. For a start, the FemtoRV cores have no capability to detect invalid instructions at all. Next, and more difficult, is mixing interrupt handlers with invalid instruction exceptions, as this would need two layers of interrupts, for example to execute an emulated instruction within an interrupt handler, and the RISC-V privileged specs were shady and opaque to me in this regard, with a steep slope of complexity to do it right:

#1 (comment)
stnolting/neorv32#284
#1 (comment)

If we can sketch out an elegant way to add invalid instruction traps to one of the FemtoRV32 cores that already support interrupts, this would be great!

[0BAB1]

Thanks ! And yes, adding exception support in a elegant way will be a challenge indeed.

But once we can reliably detect exceptions, the rest will become a bit more clear. As an example, the way I do it is I give priority to interrupts, but in the end both interrupts and exception cause the same thing to happen : raise the trap flag, which is used by the control unit to automticlly set the pc source to whatever mtvec is:

// in my csr file///

if(trap)begin
        // interrupts have priority over excpetions

        // if its an interrupt...
        if((|(mie & mip))) begin
            next_mcause[31] = 1;
            // the order here defines priority
            if(mip[11] && mie[11])begin
                // external
                next_mcause[30:0] = 31'd11;
            end
            else if(mip[7] && mie[7])begin
                // timer
                next_mcause[30:0] = 31'd7;
            end
            else if(mip[3] && mie[3])begin
                // soft
                next_mcause[30:0] = 31'd3;
            end
        end
        // or if its an exception (less priority)
        else if(exception) begin
            next_mcause[31] = 0;
            // we reuse cause given by control 
            next_mcause[30:0] = exception_cause;
        end
    end

This is not very elegant code.. but the spirit is here.

Also, to detect invalid instructions, I use a set of flags in my control unit:

// control unit

wire valid_load_func3 = (func3 == 3'b000) || // LB
                        (func3 == 3'b001) || // LH
//etc...

// Stores (SB, SH, SW)
wire valid_store_func3 = (func3 == 3'b000) || // SB
                         (func3 == 3'b001) || // SH
                         (func3 == 3'b010);   // SW

// ALU I-type ops (ADDI, SLTI, SLTIU, XORI, ORI, ANDI, SLLI, SRLI, SRAI)
wire valid_alu_func3 = (func3 == 3'b000) || // ADDI
                       (func3 == 3'b001 && func7 == 7'h00 ) || // SLLI (shift left logical immediate)
                       (func3 == 3'b010) || // SLTI
//etc...

// Branches (BEQ, BNE, BLT, BGE, BLTU, BGEU)
wire valid_branch_func3 = (func3 == 3'b000) || // BEQ
                          (func3 == 3'b001) || // BNE
//etc...

// R-type ALU ops (ADD, SUB, SLL, SLT, SLTU, XOR, SRL, SRA, OR, AND)
wire valid_rtype_combination = (
    // ADD, SUB
    (func3 == 3'b000 && (func7 == 7'b0000000 || func7 == 7'b0100000)) ||
    // SLL
//etc...
);

and use these to determine if the instruction is valid (all instructions are flagged as invalid by default and the exception flag is deasserted only when the corresponding valid flag is high).

Anyway, this is a pretty brute force way to do it so I guess some optimizations are in order, which would be a nice challenge, thus me asking if I could try it out here.

Best

[Mecrisp]

Go for the quest, its absolutely worth it, and we are there for discussions!

I think, the interrupt CSRs should keep being the standard ones, whereas I -personally- am fine if the invalid instruction trap works in a custom, nonstandard way, but Bruno needs to chime in on this matter, too. People come to this project for elegance and simplicity, this is our main focus (and a little bit of research) here, and this is what we measure additions in functionality against.

For emulating instructions, the invalid instruction exceptions need higher priority than hardware interrupts, because emulated instructions might happen in interrupt handlers, and RISC-V does not readily handle deeply nested interrupts/exceptions.

Another difficulty is that whereas hardware interrupts can be accepted at the state that puts the next instruction address on the memory bus, an invalid instruction exception will happen within the decode or execute states.

[0BAB1]

I see...

I'll look into it when I'm done with my current take, which may take some time. I wanted to make sure you were open to the idea so I can start thinking about the specifics of how to make it happen in a nice looking compact way.

I'll come back to you once I get started.

NB : I did not mention adding non standard CSRs, the goal being to be 100% compliant to the specs. CSR logic should be added to take exception handling into account, and not much CSRs would be added, in fact, I think only mtval is to add (which gives additional, standard insights on the "bug"/exception) and maybe mscratch<0-1> for additional platform specific infos, but it's optional if I recall correctly...

Thanks again for the answers, Best
-Hugo

[BrunoLevy]

I suggest we do that step by step (and this will make a nice tutorial), for what I call the "FemtoRVMorph" core:

• start with a RV32I femtoRV
• step 1: create an exception mechanism, triggered each time an RV32M instruction is encountered
  implement all RV32M instructions in the trap (but for now we do not suppose re-entrance, the handler
  solely uses RV32I instructions). Implement a as-minimalistic-as possible subset of Zicsr
• step 2: support re-entrant exceptions
  test it with RV32F implemented with RV32M, in turn implemented with RV32I
• step 3: make the mechanism compatible with interrupts
• step 4: play with @Mecrisp's minimalistic preemptive multitasking kernel. Create an example program that uses RV32M instructions in each task, to demonstrate that everything plays well together
• step 5: implement the rest of the bare minimum Zicsr needed by Linux-nommu in software (in the exception and interrupt handlers)

Regarding standard (RISC-V) vs non-standard exception mechanism, I have a preference for standard, but I'm also fine with non-standard (and I guess it will be much easier to start from a non-standard mechanism, gain some experience, and maybe morph it into the standard mechanism). The official documentation on the priviledged ISA is very hard to read (at least for me).

There are some sw emulators that can be a source of inspiration (the second one is super compact):

• exactstep RISC-V emulator by @ultraembedded
• mini-rv32ima RISC-V emulator by @cnlohr

Once we have a good experience with that, I'd be interrested in the following versions of FemtoRVMorph:

• Design a RV32IMFC core with IC in hw, multiplication in hw, division in sw, floating point add, sub, mul, fma in hw, division in sw.
  What does it say in terms of performance/gate usage ratio ?
• What about pipelining ? How exception handling / pipelining / caches play together ?
  In the end, I'd like to have a as-simple-as-possible pipelined core with the bare necessary plus some important operations in hw and all the rest in sw.

[0BAB1]

That's a good roadmap, I did not know F was doable only with RV32I ! that would be a great claim to have such a small core do Floating point..

What about pipelining ? How exception handling / pipelining / caches play together ?
In the end, I'd like to have a as-simple-as-possible pipelined core with the bare necessary plus some important operations in hw and all the rest in sw.

That is the shady part for me. I did not implement it on pipelined cores yet but I guess it's like an unexcpected branch, the whole pipeline is flushed and we start fetching from mtvec, same when returning with mret.

[BrunoLevy]

• About floating point: everything is doable as soon as our exception mechanism gives us sufficient information to retreive the faulty instruction and emulate it ! What excites me is the possibility of implementing some instructions in hw (+,-,*) and some others (/) in sw. FemtoRVPetitbateau implements RV32F with micro-instructions and a micro-program ROM. Basically everything is done using fused-multiply adds (FMA). It works but it is a rather stupid waste of resources, we could implement FMA in hw and all the other operations in sw. This would create a reasonably efficient RV32F core with a very small footprint.
• About pipelining, we'll do one step at a time (I see that in a distant future) !

[0BAB1]

that sounds exciting !

But won't moving some of the complexity of the more complex instruction away in software to reduced the footprint be like "mettre la poussière sous le tapis" ?

That's a joke, of course, I never really thought about this kind of mixed SW/HW architecture, that's clever, I like it.

Anyways, for your information, I would love to participate as this is the kind of projects I love. But I can't get at it right now as I'm facing some deep cache debugging challenges to make my core run DOOM as fast as possible... So I won't be able to start before a couple of weeks.

[BrunoLevy]

There's no rush ! Anyway I'll be also quite busy with my job during the next weeks. We'll start when everybody is ready.