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

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Thu Jun 25 17:32:57 BST 2020


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

--- Comment #3 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Luke Kenneth Casson Leighton from comment #2)

> i would recommend that every Function Unit's inputs and outputs
> be on the same "side", because those inputs and outputs ultimately
> have to go to the Regfiles, which is a single location.


so, the data which goes through the pipeline will "loop back".

when this is expanded and there are 15 to 28 Function Units, i would recommend
having very "narrow" Function Units that have half of their pipeline stages
going one direction, turn round, then half of them come back again.

when we include DIV and MUL this will almost certainly need to be done.  these
will be very big Function Units as large as all other Function Units combined.

at that point a kind of "tree" will be needed that fans out the "thin" Function
Units like branches, all of them leading back to the point where the
PriorityPickers are.

the Regfile Broadcast Buses will be quite large (a lot of wires back and
forth).  i do not yet have a handle on the relative sizes, here.

however from the internals, we have INTRegs which is 3R2W and whilst the data
is 64 bit the "address" remember is in *unary* so is 32 bits, one bit for each
register.

therefore there are 96 x 5 wires going in and out of the INT regfile.

* for the RA Read Port the 6 bit data fans out to i think 5 Function Units.
* likewise for RB
* for the RT Write Port i think it is 3 fan-in

basically these relationships between Regfiles and Function Units are multiple
fan-in and multiple fan-out each being Broadcast Buses, each Bus being managed
by a PriorityPicker.

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


More information about the libre-soc-bugs mailing list