[Libre-soc-bugs] [Bug 745] OP_TERNARY instruction

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=745

--- Comment #27 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
the class where these two types of pspecs merge is AllFunctionUnits.

https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/fu/compunits/compunits.py;h=be3d4e69c5806dcce1cf68642e0a514ac37249e2;hb=4c98cc88be5aba23807c6f4bf97e9de6ba13fd73#l281

you can see here:

 293     def __init__(self, pspec, pilist=None, div_fsm=True):
 294         addrwid = pspec.addr_wid
 295         units = pspec.units
 296         microwatt_mmu = hasattr(pspec, "mmu") and pspec.mmu == True
 297         print("AllFunctionUnits.microwatt_mmu="+str(microwatt_mmu))

that is taking:

* the address width from the TestMemPSpec
* the units dictionary from the TestMemPSpec
* whether mmu is requested to be added

as a special-case the address width is specifically handed to
LDSTFunctionUnit(s):

 344         for i, pi in enumerate(pilist):
 345             self.fus["ldst%d" % (i)] = LDSTFunctionUnit(pi, addrwid, i)

and you can see how in both FunctionUnitBaseMulti and Single
the pspec - this one is the *pipe* specification - is created
and passed through to the ALU:

 135 class FunctionUnitBaseMulti(ReservationStations2):
 157     def __init__(self, speckls, pipekls, num_rows):
 158         id_wid = num_rows.bit_length()
 159         pspec = speckls(id_wid=id_wid)           # spec (NNNPipeSpec
instance)
 160         opsubset = pspec.opsubsetkls             # get the operand subset
class
 161         regspec = pspec.regspec                  # get the regspec
 162         alu = pipekls(pspec)                # create actual NNNBasePipe
 163         self.pspec = pspec

there's a couple of options here:

1) pass the TestMemPSpec instance through to *everything* (an extra argument
   to every function unit class, in addition to idx

2) add a function that passes it in, post-instantiation (which then
   passes it through to the self.alu instance with a follow-on call)

i'd recommend (1) because the constructor of the PipeSpec and also
the ALU may need to adapt.

this will *need* code comments explaining what the hell is going on,
it's the first time these two (identical-named) variables have "met"

-- 
You are receiving this mail because:
You are on the CC list for the bug.