| # Kelvin Dispatch Rules |
| |
| We want to dispatch as many instructions as possible in the Kelvin core. The |
| following describes the general rules we use to determine which instructions can |
| be dispatcted. |
| |
| ## In-order |
| |
| Kelvin is an in-order core. In at instruction at address n cannot be dispatched, |
| n+4 is also not considered for dispatch. |
| |
| ## Hazard Handling |
| |
| Kelvin uses scoreboarding to track dependencies across instructions. This |
| prevents RAW and WAW data hazards. All execution units read their operands from |
| the register file the cycle after the instructions are dispatched. Therefore, |
| WAR hazard never occurs. |
| |
| ## Execution Unit Constraints |
| |
| There are a limited number of execution units to service instructions. While |
| there are enough Alu and Bru units to service each lane, Kelvin contains only |
| 1 Mlu. Therefore, we restrict the number of multiply instructions per-cycle to |
| a single instruction. Simiarily, non-pipelined execution units (ie. Dvu) may |
| exert backpressure to prevent an instruction from being dispatched while it is |
| busy. |
| |
| Memory today is limited to dispatching one instruction per cycle. |
| |
| ## Control Flow |
| |
| Conservatively, Kelvin will not dispatch past the following jump instructions: |
| `jal`, `jalr`, `ebreak`, `ecall`, `mret`, `wfi`. |
| |
| ## Special Instructions |
| |
| Instructions that can affect the core state beyond the PC/RegisterFile are |
| limited to executing out of the first slot. They are also typically treated as |
| jump control flow instructions, so no other instructions should be dispatched in |
| the same cycle as these. These instructions are: `csrrw`, `csrrs`, `csrrc` |
| `ebreak`, `ecall`, `mret`, `fence`, `fenci` and `wfi`. |
