4 does not fit in 2 bits. This appears to not matter in practice, as a
spot check of the generated Verilog shows 3'dN for state-related
constants, but we should not be relying on this surprisingly lax
behaviour from bsc, and who knows if there are ways in which bsc does
end up using the as-written bit width somewhere.
Fixes: 6d4644ce73 ("Add tag-only state to MESI and interface with tagOnlyReq of tag controller")
* Fixed the Decoding of (C)JAL
* Use CSR addresses instead of offsets
* Fixed offsets correctly
* Fixed all offsets I could spot
* Fix use of modifyOffset function
* Corrected brAddrCalc function
* Preliminary fix for ddc offsetting
* Use setAddr instead of incOffset for DDC
* Deleted unnecessarily added lines in ALU pipeline
* Deleted white space
* Switched off verbosity for ALU pipeline
* Removed unnecessary print import
As well as clarifying the logic in the main decode function (no
functionality change), this also fixes some cases that should be
illegal but weren't caught in the memory instructions.
The decode had a TODO to handle illegal instructions more precisely.
Some instructions in the new CHERI spec were not causing traps, and
seemed to wedge the core.
Switch to a new style where instructions are assumed illegal unless
explicitly declared legal.
This definitely at least covers many funct3 etc fields where only
some of the encodings are currently used.
This fixes a wedge in the frontend: the fetch stage could get stuck
in a loop, with the next address predictor deciding that the redirect
PC is a compressed instruction doing a close jump. On mispredict,
this would get retrained, but "mispedict" was denoted as an
untaken branch to PC+2. If unlucky, PC+2 could cross an alignment
boundary, causing the untaken branch to be interpreted as a long
branch, leaving an old competing entry in the compressed branch BTB,
which would then take priority.
Fix by always marking entries in both close and long BTBs when not
taken: to avoid hurting performance, this kind of update will not
insert into either BTB unless already present.
This means that two returns decoded in the same cycle are likely to result in a misprediction.
The trouble here was that the Decode loop wouldn't build with slight changes due to a scheduling conflict through the RAS due to the dependence of the next ras.first method on the earlier ras.pop method. This was indeed an unpleasant combinational path between concurrently decoding instructions. This change allows all RAS predictions to be independent (by assuming no pushes or pops occur earlier in the bundle than a return).
