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

[bugzilla-daemon at libre-soc.org]

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

--- Comment #49 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
ok.  i think we need to look more closely at decoder2.py compared to
decode2.vhdl
https://github.com/antonblanchard/microwatt/blob/master/decode2.vhdl

i'm not seeing any reason though why the operands should need "swapping over":
why RC is needing to go into a.

the alignment should definitively be:

* reg3_data into c
* reg2_data (or imm) into b
* reg1_data into a

ah hang on...

https://github.com/antonblanchard/microwatt/blob/master/execute1.vhdl

see lines 183-184:

    logical_0: entity work.logical
        port map (
            rs => c_in,
            rb => b_in,

and here, lines 166-169:

    rotator_0: entity work.rotator
        port map (
            rs => c_in,
            ra => a_in,

that's it.  that's what's going on.  the different pipelines have *different*
register map/alignment, *depending on function-group*.

the *adder* takes A as A, and B as B.  rotator crosses over, logical crosses
over.

what a mess.

ok what i suggest, then, here is: split out Logical ALU operations as well.
the ADD ALU will deal with OP_ADD and OP_CMP.  i don't yet know if we should
allow the ADD ALU to change the PC (handle OP_TRAP), i'm inclined to suggest
that that one be handled in the Branch Computation Unit.

by splitting out:

* ADD/CMP into one pipeline
* Logical into another
* Rotator into another

basically on the face of it we need to use the FunctionOp to determine the
re-routing of the operands.

but... it looks like you've discovered a correlation, where if reg_data3 is
available it can go *first* (into out.a), otherwise if reg_data1 is available, 
*that* goes first (into out.a)

however B i think definitely goes into out.b, or the immediate definitely
goes into out.b, and i think we'll find that there is no "immediate" form
with a register B.

fields.txt

    RB (16:20)
        Field used to specify a GPR to be used as a
        source.
        Formats: A, M, MDS, VA, X, XO

ok so strictly speaking MDS-Form has immediates in it, however if you look
at what anton's done, in minor-opcode table 30:
https://libre-soc.org/openpower/isatables/

he's marked rdlcr as *not* reading the immediate (bit 21, mb/me) as an
immediate, but instead operand2 is marked as "RB".  which explains why
we have to decode insn to get at dec2.mb and dec2.me.

so i think we're good to go with reg2_data (or imm_data) always going into
out.b
and perhaps to have an assert that checks, for these 2-operand pipelines,
that reg3_ok and reg1_ok can never be set simultaneously, and to always put
reg3_data or reg1_data into out.a.  perhaps even as an OR rather than a Mux.

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