Improve Handling of RV32E

[PhilippvK]

The handling of the Embedded Extension (Register file size (RFS) = 16) is suboptimal for several reasons:

• Realibility is degraded. Consider the ADD instruction as an example:

behavior: if(rd >=RFS || rs1 >= RFS || rs2 >= RFS) raise(0, 2); else if (rd != 0) X[rd] = X[rs1] + X[rs2];
# vs.
behavior: if (rd != 0) X[rd] = X[rs1] + X[rs2];

• Checking constraints and calling raise(...) inside of behavior makes analysing the behavior more difficult.
• Illegal Instructions (due to register file limitations) which can be solely determined based on the encoding and static architectureal state should not be raised during decoding instead.
• This adds a lot of redundant code, because we basically have roughly the same checks for almost every (standard) instruction. Declaring it only once for RV32E would be way cleaner

Let's discuss how to handle the embedded extension in a more sophisticated way.

@jopperm @eyck @AtomCrafty @wysiwyng

[eyck]

Actually I fully agree. My first attempt would be to enhance the encoding part to allow conditional specifications like:

encoding: imm[31:12] :: RFS==16? (1'b0::rd[3:0]) : rd[4:0] :: 7'b0110111;

which would also allow for

encoding: RFS==16? 
                    (7'b0000000 :: rs2[4:0] :: rs1[4:0] :: 3'b000 :: rd[4:0] :: 7'b0110011):
                    (8'b00000000 :: rs2[3:0] :: 1'b0:: rs1[1:0] :: 4'b000 :: rd[3:0] :: 7'b0110011);

But in conjunction with #96 there might be other solutions.

[PhilippvK]

I haven’t considered such syntax yet. But I kinda like it because it is probably the least invasive. Of course this does not offer enough flexibility to also support #96…