[Libre-soc-dev] in-order core hazard detection is functional
luke.leighton at gmail.com
Sat Nov 27 15:54:53 GMT 2021
i thought of a potential solution to "addi 5,5, #20" which was to delay write-hazard bitvector setting by 1 clock cycle, so that the instruction itself does not have the dependency of its own write.
this delay immediately caused a combinatorial loop in WaW checking! that was also solved by latching data in from a different source.
basically we now have a reasonably functional superscalar in-order engine, which, when the issue front-end is added should give us a reasonable IPC. 0.6 to 0.75 should be achievable (where right now we have around 0.1 with TestIssuer).
this is a relief because rewriting to use 6600 scoreboards would be about 3 weeks, which is appx 10% of the remaining available time.
all of us have some serious speeding up to do in order to meet the committments made to NGI POINTER.
More information about the Libre-soc-dev