[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