[Libre-soc-bugs] [Bug 737] in-order single-issue Power ISA 3.0 core
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Sun Nov 7 15:47:53 GMT 2021
https://bugs.libre-soc.org/show_bug.cgi?id=737
--- Comment #13 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
https://bugs.libre-soc.org/show_bug.cgi?id=742#c5
ReservationStations2 is now working, and has been tested with num_rows=1
(and is in active usage already).
something to watch out for, in core.py:
# enable the required Function Unit based on the opcode decode
# note: this *only* works correctly for simple core when one and
# *only* one FU is allocated per instruction
for funame, fu in fus.items():
fnunit = fu.fnunit.value
enable = Signal(name="en_%s" % funame, reset_less=True)
comb += enable.eq((self.e.do.fn_unit & fnunit).bool())
comb += fu_bitdict[funame].eq(enable)
therefore it is not yet safe to enable num_rows > 1
it is perfectly fine to set num_rows=1 and have InOrder overlapping
instructions, that can go ahead (right now), there should be no
problem.
an add instruction will quite safely overlap with a mul instruction
will quite safely overlap with a DIV instruction etc. etc.
the problem will come if num_rows is set to greater than one: this will
result in more than one "en_{funame}" being set, and the instruction
will be sent to *more than one* Function Unit.
to solve that, a PriorityPicker is needed (just like exists in the
CDC6600 and therefore also in the scoreboard6600 experimental code)
but, that is for later: right now there is nothing stopping the InOrder
core from being written (just with all num_rows=1)
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs
mailing list