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

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Sat Nov 20 01:01:25 GMT 2021


--- Comment #15 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #14)
> (In reply to Luke Kenneth Casson Leighton from comment #13)
> > (In reply to Jacob Lifshay from comment #12)
> > > https://git.libre-soc.org/?p=soc.git;a=commit;
> > > h=e281a933b5e0b7b0c85040116a404873f4ee0f17
> > 
> > mm... a case could be made either way for the benefits of having
> > a separate pipeline vs putting ops into ones with identical
> > profiles.
> I was thinking I would put all integer bitmanip ops in one pipeline, and all
> cr bitmanip ops in another.

if you examine the source code - or were familiar with it already - you
would have seen how core.py works and how it auto-constructs register file
port access by analysing the regspecs and creating broadcast buses.

due to there being 10 pipelines already there are currently a whopping
35 register file read port accesses: this is after merging RA RB and RC into
one single register file port (which, clearly, requires 3 cycles delay
just to get all the operands).

for an in-order core assuming a 3R1W or 4R1W regfile that goes up to
a staggering 50 register file port read accesses, if that "merging" trick
is removed (in order to get latency down).

the consequences of what you are proposing is that the number of register
file ports goes up to almost 60 register file port read accesses.

that is just read port accessors.

the policy / convention of grouping by regspec profile - not by function -
which i have repeated four times now - is there to ensure that there is
no out-of-control explosion of port proliferation, which requires massive
wide OR gates and Muxes to handle.

when i provide summaries as instructions to you, it is to save time
explaining these things in detail.

it would be good if you could listen because you are still writing
3-5 times as much code as is required, and then i have to spend more
time explaining why that code has to be cut back, usually to what
i said would be needed, when i said it the first time.

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

More information about the libre-soc-bugs mailing list