[Libre-soc-bugs] [Bug 199] Layout using coriolis2 main core, 180nm

[bugzilla-daemon at libre-soc.org]

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

--- Comment #35 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
okaay jean-paul, about the floor-plan layout version:

i have renamed all of the operands so that they now have the following
prefix format:

* oper_i_alu_PIPENAME{N}_{field}
* oper_i_ldst_ldst{N}_{field}

where earlier i recommended to put all I/O on the *bottom* (SOUTH) of each
pipeline (except LD/ST which would specially have the Memory interface on
NORTH) i thought about this a bit more, and realised that the opcode expansion
is going to be too many wires.

oper_i_alu_alu0 and oper_i_alu_logical0 for example, the 32-bit incoming
instruction is expanded to *ONE HUNDRED AND THIRTY* wires because it contains,
for example, the expansion of the immediate field out to its full 64-bit.

i will do something about this... but not right now.

so what i figured was: those operand wires could come in at the *side* (RIGHT)
down at the bottom (SOUTH) part of the RIGHT (left?) side.

LDST:

    Memory (PortInterface)
                 ^
                 |
             +---|---------+
             |             |
             |  +-----+    |
             |  |     |    |
             | pipe2 pipe3 |
             |  ^     |    |
             |  |     v    |
 oper_i_alu->--pipe1 pipe4 |
             |  |     |    |
             +--|-----|----+
                ^     v
              IN regs OUT


the oper_i_alu_* needs to "propagate" through the pipeline in synchronisation
with the IN regs data, therefore it is sensible to have oper_i_alu_* be close
to IN data/regs, rather than be on the opposite side.

therefore, if IN is better placed on the *right* of OUT at the SOUTH side, then
oper_i_alu_* should _also_ go on the RIGHT side, close to the bottom.

many (most) of these Pipelines i expect to be quite "thin".  ALU0 for example,
or TRAP0, or Branch0.

however MUL will be extremely "fat" (take up literally 50% of the entire width
of the layout).

the "thin" ALUs are what concerns me, hence the idea of bringing in the
oper_i_* signals in at the "side".

what this in turn means is that there will be some clear delineation /
separation between the pipelines, potentially needing those "channels" you
mentioned, because those oper_i signals will have to be routed *between* the
pipelines (which are laid out in a horizontal line, just like in the CDC 6600
diagram).

https://libre-soc.org/3d_gpu/architecture/6600scoreboard/600x-multiple_function_units.png

one other alternative is to have, exactly as is shown *in* that diagram,
complete separation between input and output on pipelines: however this
means that one of the register WRITE and READ port Buses need routing *round*
(to the top).  i am not keen on that.

in the arrangement where pipeline data goes in and out of the same side
(and the pipeline doubles back on itself), both the WRITE and READ regfile
ports may be very close to the pipelines.


fascinatingly, the full auto-route version actually *mixes* the FAST regfile,
TRAP0 pipeline and BRANCH0 pipeline, interspersed in some regularly
patterned "blobs", side-by-side with each other.

this because TRAP0 and BRANCH0 both need significant access to the FAST
regfile.

anyway.

yes.

summary of idea: oper_i_alu_* field signals on EAST or WEST, and i've
named them conveniently so that they can be searched for, easily, with
pattern-matching that prefix.

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