[libre-riscv-dev] morphing 6600 code to use power decoder

[libre-riscv-dev] morphing 6600 code to use power decoder

[Luke Kenneth Casson Leighton]

i'm making a start on linking up the 6600 experimental code with the power
isa decoder based on microwatt.

given that the 6600 code already was in an "internal opcode" format very
similar in principle to microwatt, this _should_ be relatively
straightforward.

i will start with the CompUnit for fixed integer ALUs, keeping it simple
and passing over cherry picked decoded fields.

however one key difference will be that whilst immediates are read from the
opcode, registers are *not* immediately read from the regfile, they are
done by way of a regfile port bus, and only when available are "latched"
into registers.

only when all read regs become available can the op proceed.

so it is a little different from microwatt which just does, in sequence,
decode read execute write.

it should be fine.

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] morphing 6600 code to use power decoder

[whygee]

On 2020-04-08 15:26, Luke Kenneth Casson Leighton wrote:
> however one key difference will be that whilst immediates are read from 
> the
> opcode, registers are *not* immediately read from the regfile, they are
> done by way of a regfile port bus, and only when available are 
> "latched"
> into registers.
> 
> only when all read regs become available can the op proceed.
> 
> so it is a little different from microwatt which just does, in 
> sequence,
> decode read execute write.
> 
> it should be fine.
> 
> l.

Could you please elaborate on your system ?
Is there some sort of buffer to store the immediates
while waiting for other operands to be ready ?

yg

_______________________________________________
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] morphing 6600 code to use power decoder

[Luke Kenneth Casson Leighton]

On Thursday, April 9, 2020, <whygee@f-cpu.org> wrote:

>
> Could you please elaborate on your system ?
> Is there some sort of buffer to store the immediates
> while waiting for other operands to be ready ?


it's literally as described in Mitch's book chapters.  minor alterations
are documented here
https://libre-soc.org/3d_gpu/architecture/6600scoreboard/

you can see in the CompUnit, a latch for immediates and a latch for reg
operands.

one bit says "latch the immediate instead of operand2 as the 2nd input to
the ALU".

very simple.

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] morphing 6600 code to use power decoder

[Luke Kenneth Casson Leighton]

okaay, i have a first successful - one instruction (an add) -
execution of an "internal op" which is manually placed into the
instruction queue.  adding the POWER decoder in front of that should
be a trivial exercise.

the code's been... messed about somewhat, to get it functional, and
the LDST and Branch Comp Units also need converting.  however the core
out-of-order engine remains exactly the same, so this again should
just be a straightforward exercise.

we do need to write a "proper" Integer ALU - one that uses
PartitionedSignal for operations.  this will be where all the pieces
and hard work that everyone's put in will gel together.

l.

_______________________________________________
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] morphing 6600 code to use power decoder

[Luke Kenneth Casson Leighton]

decoded instruction and executed add and addi!  w00t!

l.

_______________________________________________
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] morphing 6600 code to use power decoder

[Luke Kenneth Casson Leighton]

https://libre-soc.org/3d_gpu/compunit_multi_rw.png

argh.  the addition of Carry (and other registers) means that the
"simple" 2-in, 1-out Computation Unit is not going to work.
additionally, there are actually 3-in 2-out operations such as the
int-mul-and-add, and FP operations will need to modify FPSCR as well.

the original 6600 CompUnits *specifically* waited until *both*
incoming operand Register Read Ports were free, choosing *one signal
pair* (Rd_Req and Go_Read) to synchronise that.

with the strong possibility of not *having* more than two read ports
per stratification of the Register File (HI-ODD32, LO-ODD32,
HI-EVEN32, LO-EVEN32) the original scheme is not going to work.

therefore where previously there was only one RD_REQ-GO_RD pair,
*multiple* (individual) RD_REQ-GO_RD pairs are needed.

this requires some additional logic.  where previously, the logic was
just simply: ISSUE, GO_RD, GO_WR, where only one of those can be
active at any one time, it now has to be:

* ISSUE
* send out multiple RD-REQs
* wait for *ALL* GO_RD responses to come in
* ONLY THEN send out WR-REQs
* wait for *ALL* GO_WR responses to come in
* reset back to the start.

complicated.

l.

_______________________________________________
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] morphing 6600 code to use power decoder

[Luke Kenneth Casson Leighton]

https://groups.google.com/forum/#!topic/comp.arch/qeMsE7UxvlI
https://libre-soc.org/3d_gpu/architecture/6600scoreboard/
https://www.youtube.com/watch?v=ohHbWRLDCfs

this is quite a significant core change to the 6600 scoreboard engine,
so i'm soliciting outside help in reviewing it.  ironically (and very
much to the point) i realised an error towards the end of the
description.

l.

_______________________________________________
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] morphing 6600 code to use power decoder

[whygee]

On 2020-04-13 16:16, Luke Kenneth Casson Leighton wrote:
> https://groups.google.com/forum/#!topic/comp.arch/qeMsE7UxvlI
> https://libre-soc.org/3d_gpu/architecture/6600scoreboard/
> https://www.youtube.com/watch?v=ohHbWRLDCfs
> 
> this is quite a significant core change to the 6600 scoreboard engine,
> so i'm soliciting outside help in reviewing it.  ironically (and very
> much to the point) i realised an error towards the end of the
> description.

I couldn't be sure to understand all the subtleties.

However remove the comment from "Tom"/Temar
who is a click-harvesting bot on youtube.

Anyway : impressive work !

> l.
yg

_______________________________________________
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] morphing 6600 code to use power decoder

[Luke Kenneth Casson Leighton]

On Mon, Apr 13, 2020 at 6:46 PM <whygee@f-cpu.org> wrote:
>
> On 2020-04-13 16:16, Luke Kenneth Casson Leighton wrote:
> > https://groups.google.com/forum/#!topic/comp.arch/qeMsE7UxvlI
> > https://libre-soc.org/3d_gpu/architecture/6600scoreboard/
> > https://www.youtube.com/watch?v=ohHbWRLDCfs
> >
> > this is quite a significant core change to the 6600 scoreboard engine,
> > so i'm soliciting outside help in reviewing it.  ironically (and very
> > much to the point) i realised an error towards the end of the
> > description.
>
> I couldn't be sure to understand all the subtleties.

CompUnits are a forward-progress looped Finite-State-Machine.  Issue,
Read, Write, Issue, Read, Write.  that's now Issue, {Read1/2/3},
{Write1/2}, Issue {Read1/2/3}, {Write1/2} repeat repeat.

Dependency Matrices: Reads stop Writes, Writes stop Reads.  now there
are multiple read-regs, any one of those multiple Read-Regs must stop
Writes, any one of those multiple Write-Regs must stop Reads.

> However remove the comment from "Tom"/Temar
> who is a click-harvesting bot on youtube.

done.

> Anyway : impressive work !

appreciated.  now i have to implement it.  and modify all the
dependent code that uses it.  sigh.  it'll be about a month's work.

l.

_______________________________________________
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] morphing 6600 code to use power decoder

[Luke Kenneth Casson Leighton]

https://www.youtube.com/watch?v=_5fmPpInJ7U

continuing the code-morph, i now have the FU-FU Matrices also working
with multiple GO-RD and GO-WR signals.  now to actually start using
them, which is where the fun starts. there are already several hundred
signals in the gtkwave files *sigh*...

l.

_______________________________________________
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] morphing 6600 code to use power decoder

[Luke Kenneth Casson Leighton]

ok i've got the computation unit "operational" with multiple
go-read/acknowledge signals.  i say operational, it's tricky code that
i'm not completely happy with, however it "works".  finally i can move
on to getting the comp unit and dependency matrices multi-rd/write
signals integrated.

l.

_______________________________________________
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] morphing 6600 code to use power decoder

[Luke Kenneth Casson Leighton]

adding multi-read and multi-write register port selection is a massive
ripple-effect change, going through virtually absolutely every module
involved in the 6600 layout.

* PriorityPicker can no longer be used, it has to be
MultiPriorityPicker because that's the class which can arbitrate
exclusive access to multiple register file ports
* Group Picker uses PriorityPicker, which is told not just which
read/write ports are being requested, it has to be told which ones are
safe to read/write
* Function-Unit to Function-Unit Matrices need to be multi-port aware
* Function-Unit to Register Matrices need to be multi-port aware
* Computation Units need to be multi-port aware

all this because we need to have a separate register file for POWER
branch/condition/link registers, which needs its own separate port
"management" signals from the INT/FP regfile.

gaah.

l.

_______________________________________________
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] morphing 6600 code to use power decoder

[Luke Kenneth Casson Leighton]

https://libre-soc.org/3d_gpu/multi_bus_arbiter.png

i'm trying to design a multi-bus arbiter which routes:

* multiple banks of src1, src2, src3
* to ANY register-file read-port 1, read-port 2, read-port 3.

at the moment we have:

* multiple banks of src1, src2, src3
* read-port 1 has an INDEPENDENT PriorityPicker to manage access from src1
* read-port 2 has an INDEPENDENT PriorityPicker to manage access from src2
* read-port 3 has an INDEPENDENT PriorityPicker to manage access from src3

the actual arbitration can be done as "select" lines, and, once done,
they can be easily used to enable ORing of data onto buses.

am i overthinking this?

is it as simple as just flattening the multiple banks of src1, src2,
src3 into a linear 1D line of requests?  so if there are 6 banks each
with src1,src2,src3 simply flatten that to 18 requests (for access to
the 3 read-ports)?

l.

_______________________________________________
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] morphing 6600 code to use power decoder

[Luke Kenneth Casson Leighton]

this is excruciatingly slow work. i've only just got 4 out-of-order
instructions (2 per Function Unit) operational again after changing to
use multi-control signals on the register file: one each for each
port.

that's still not out of the woods, yet: the last time i did this it
took hundreds of runs of random operations to be partially confident
of an operational OoO design.

i still have LD/ST and branch to put back in.

l.

_______________________________________________
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] morphing 6600 code to use power decoder

[Luke Kenneth Casson Leighton]

i started on adding LD/ST back in: and, argh, i spotted that the
LDSTCompUnit needs some rework / redesign.  it "worked" previously
however there were some assumptions which, because of the new
multi-signalling, don't work.

i think i will take the opportunity to remove the triple-functionality
from the LDSTCompUnit.  the original intention was to have its ADD ALU
be capable of performing standard ADD arithmetic, thus allowing us to
have dozens of parallel ADD units.

we're running out of time, and unfortunately i'm not coping with the
logic complexity involved in writing out these state-based diagrams
(last time it took 3 weeks to get right), so i'm going to cut ADD and
simply make the address-generation part of the actual LDSTCompUnit.

l.

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