This probably requires different solutions for different float widths. E.g. for f8 we can most likely use a simple LUT solution, while for f32 we may need to use Newton-Raphson or similar.

For non-branch instructions, the next PC must be PC+4.

B and BL do not need access to any registers, and so should be possible to execute in the ID stage (essentially compute PC + Imm and always branch). The same goes for zero-relative branches (j/jl z, addr).

This would reduce the branch misprediction penalty to 1 cycle for B/BL. C-style for-loops would benefit from this, for instance:

  .loop:
    slt     s9, s20, s21    ; s20 < s21?
    ...
    bns     s9, .loop_done  ; Predicted not taken: +3 cycles on last iteration
    add     s20, s20, 1
    ...
    b       .loop           ; Predicted not taken: +1 cycle on first iteration

.loop_done:
    ...

The potential extra cost is additional muxing in the PC / BTB, as well as more logic for calculating the brancj target in ID.

Caveat: A branch in ID must be considered speculative, since up tp 2 earlier brancjes may be further down the pipeline, waiting to potentially invalidate the branch instruction in the ID stage. One solution is to not let the ID branch update the BTB, but wait until the instruction reaches EX to do the update.

Another problem is that more information may be required in order to determine the correctness of the program flow (i.e. whether or not the EX stage should cancel the following instructions).

Do #1 first.

With late forwarding of the addend, the MADD instruction would work as an MAC with zero latency for consecutive multiply+add operations such as:

    madd  r1, r2, r3
    madd  r1, r4, r5
    madd  r1, r6, r7  ; r1 = r1 + r2 * r3 + r4 * r5 + r6 * r7

We probably only need to worry about forwarding of outputs from the MADD unit.

It should be relatively easy to "pop bubbles" during a stall (i.e. don't propagate the stall signal to earlier stages if a stage is currently holding a bubble).

The current branch predictor is a single-state predictor (taken / not taken). Add weakly taken states (i.e. use a two-bit predictor state).

Also, a return-address stack predictor would be useful.

Investigate current BTB implementation:

• Is it optimal or does it contain redundant bits?
• Can we measure the BTB hit/fail rate?

Currently we use five RAM instances for the register files (35840 effective bits in total):

• Three 1024-bit RAM instances for the scalar register file (three read ports).
• Two 16384-bit RAM instances for the vector register file (two read ports).

In a Cyclone V FPGA this translates to 70 Kbits BRAM usage in total, as follows:

• 3 x M10K BRAM blocks for the scalar register file.
• 4 x M10K BRAM blocks for the vector register file.

That means that we are wasting 50% of the memory bits.

Try out different strategies. E.g. try using MLAB:s / distributed RAM for the scalar register file.

If a branch instruction only advances the PC by 4 bytes when the branch is taken, we essentially have an instruction (the one following the branch) that is predicated. In some situations it would be beneficial to treat that instruction as conditionally executed instead of handling the branch as usual.

If we have a branch misprediction, we could just let the execution flow continue but replace the predicated instruction with a bubble. Or something like that.

This is slightly trickier than for fmul & fdiv.

There are too many levels of MUX:ing going on, especially around the compare logic.

A memory store does not need the data operand until the 2nd execute pipeline stage. Being able to start the store instruction (to calculate the address) before the data operand is ready can save one clock cycle in certain situations, e.g:

    ldw s1, s3, #0 
    stw s1, s4, #0 

The ICache is more important than the DCache for most applications, and it is easier to implement.

Having an ICache will leave the shared memory bus free for the data interface most of the time, letting the instruction fetch stage run uninterrupted even during data operations.

An ICache is also very useful for systems with slow memory (e.g. SDRAM). More so than a DCache since the CPU needs one instruction per clock cycle, while it may not perform data accesses on every clock cycle.

It seems that even if a branch is correctly predicted, the branch execution logic will consider the branch to be incorrectly predicted.

Investigate!

The path to o_is_vector_op_busy (which in turn ends up controlling the stall signal & the IF memory interface) is fairly complex. Try to reduce the complexity.

Right now the config (CPU capabilities) are given in a separate file in the design.

It would be better for users of the VHDL code if you could pass the configuration as parameters to the entity instantiation. This would also enable a single system to instantiate several cores with different configs.