[libre-riscv-dev] MultiCompUnit- ALU interaction. was: daily kan-ban update 30may2020

[libre-riscv-dev] MultiCompUnit- ALU interaction. was: daily kan-ban update 30may2020

[Luke Kenneth Casson Leighton]

On Saturday, May 30, 2020, Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

>
> > * more on ALU to MultiCompUnit.
> >
> > i *do not* know what i am doing, here.  the time dependent signalling is
> critical and could take several days to weeks to get right.
>
> a simple bug where XER so and ca were swapped as inputs masked efforts
> to get the interaction working.  no point trying to debug against a
> target with multiple unknowns, any one of which causes the entire test
> to fail.
>
> progress should be better, now.


we are reeeaally damn lucky.

i managed to get at least something running.  it failed only because one
operation required one operand (exts).  this leaves the CU waiting for RB
which never gets activated.

we are going to have to make a couple of modifications:

1. a "read mask".  this will tell the CompUnit that some operands are not
required.

2. a "write mask" which actually already exists (Data.ok) for output
results to also be optional.

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] MultiCompUnit- ALU interaction. was: daily kan-ban update 30may2020

[Yehowshua]

When you say you got something working, do you mean that you got the decoder to decode, the issuer to issue, and the ALU FU to compute? All working together?

If this is the case, how can I make the codebase do this myself?

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] MultiCompUnit- ALU interaction. was: daily kan-ban update 30may2020

[Luke Kenneth Casson Leighton]

On Saturday, May 30, 2020, Yehowshua <yimmanuel3@gatech.edu> wrote:

> When you say you got something working, do you mean that you got the
> decoder to decode, the issuer to issue, and the ALU FU to compute? All
> working together?


the interaction - the interface - between MultiCompUnit (a data "monitor"
aka Reservation Station) and a pipelined ALU.

MCU is a massively complex and compact FSM (the LDST CompUnit equally so).

it must:

* handle multiple ready/valid signalling to bring in multiple (optional)
operands from the regfile
* then use ready/valid signalling to kick off the ALU
* *WAIT* for ready/valid signalling from the ALU and capture the output
* finally use *yet more* ready/valid signalling to independently
acknowledge every single output being sent to its corresponding regfile for
write.

all of that *back-propagates* such that if the ALU *OUTPUT* is not ready,
the incoming data to the ALU must not be sent.

and every single one of those ready/valid events can occur independently at
any time.

and some of them are optional at the input phase.

and some of them are optional at the output phase.

it is quite ridiculously complex for such a relatively small amount of code.



> If this is the case, how can I make the codebase do this myself?


$ cd soc/src/soc
$ python3 fu/compunits/test/test_alu_compunit.py

it will currently fail at the extsb unit test because the MCU expects *all*
operands (non-optionally) to be requested from the regfile, and extsb does
not have RB.

l.




-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] MultiCompUnit- ALU interaction. was: daily kan-ban update 30may2020

[Luke Kenneth Casson Leighton]

On Sat, May 30, 2020 at 7:06 PM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:

> it will currently fail at the extsb unit test because the MCU expects *all* operands (non-optionally) to be requested from the regfile, and extsb does not have RB.

sorted.  a "source operand read mask" is now passed in to the
MultiCompUnit, telling it *not* to request specific register file
ports that are not actually required.

should now complete without error:
$ python3 fu/compunits/test/test_alu_compunit.py

next phase: the write-side.  again: just as read-ports should not be
requested which are not required, neither should write-ports.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev