[libre-riscv-dev] [Bug 305] Create Pipelined ALU similar to alu_hier.py

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Sat May 9 00:08:27 BST 2020


--- Comment #13 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---

        # If there's an immediate, set the B operand to that
        with m.If(self.i.ctx.op.imm_data.imm_ok):
            comb += self.o.b.eq(self.i.ctx.op.imm_data.imm)
        with m.Else():
            comb += self.o.b.eq(self.i.b)

...is already done by the Computation Unit:

        # select immediate if opcode says so.  however also change the latch
        # to trigger *from* the opcode latch instead.
        op_is_imm = oper_r.imm_data.imm_ok
        src2_or_imm = Signal(self.rwid, reset_less=True)
        src_sel = Signal(reset_less=True)
        m.d.comb += src_sel.eq(Mux(op_is_imm, opc_l.q, src_l.q[1]))
        m.d.comb += src2_or_imm.eq(Mux(op_is_imm, oper_r.imm_data.imm,

there is *not* supposed to be a relationship between "register numbers"
and "Function Unit Operands".  Function Units are not permitted to know
about registers, at all (however by a coincidence we happen to be
preserving the order, RA = operand1, RB = operand2 etc).

however... i quite like that it's possible to test against the actual
decoded instructions, and that makes me think that maybe yes, the
FunctionUnit should *not* be decoding the immediate, just pass it

otherwise to achieve the same unit test coverage it would be necessary
to have the immediate decoding in the unit test.

i will go ahead and modify the compalu_multi.py to remove immediate
decoding/selection from here:



here, it receives data in ALUInputData format (which is correct)

class ALUInputStage(PipeModBase):
    def __init__(self, pspec):
        super().__init__(pspec, "input")

    def ispec(self):
        return ALUInputData(self.pspec)

    def ospec(self):
        return ALUInputData(self.pspec)

however the output spec is a *modified* copy of the same data structure.

with "carry_in" being *generated* by ALUInputStage, ALUInputData should
*not* have "carry_in" as a field.

the reason is because it will never be set by the *user* of this stage,
and consequently a dangling wire will end up being created.

i've created a class ALUFirstInputData (bad name i know) which should
be used instead.  


what's "so" intended for?

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

More information about the libre-riscv-dev mailing list