[libre-riscv-dev] daily kan-ban update 19may2020

[libre-riscv-dev] daily kan-ban update 19may2020

[Luke Kenneth Casson Leighton]

yesterday i went over the pipeline code, thought about register to function
unit allocation, wrote to Marketnext to alert their members to preinstall
the dev environment (thanks to Cole for helping with that), and recovered
slightly from late nights.

today i plan (started) drawing out the Function Units with their Read and
Write register port allocations.

the idea is to have everything on one page, from which it will be clear how
many (total) ports will be needed on each type of Regfile (INT, SPR,
Condition, Exception). then, the classes connecting FUs to Regfiles can be
designed.

except, i can't complete the diagram because i am blocked waiting for Jacob
to do the DIV and MUL pipelines, which we have found highlights clearly
what regs are needed in ways that a cursory examination does not reveal.

i will therefore try to do this task without having the pipeline code to
examine.


one of the primary purposes of the kan-ban daily updates is to identify
these kinds of blocks, when collaborating in a group.

we also have a few other blocks / task dependencies:

* Yehowshua, the pinouts need to be discussed with Tim as to what he would
like to see, before we put them into the pinmux.  we cannot allocate that
to Rudi until it has been agreed by the team, and he has been waiting for
over 7 days (5 percent of the available time for completion of his task)

* Cole, the bperm proof (not exactly a block, more a confidence boost)

* Tobias, the countzero proof (not exactly a block, more a confidence boost)

* Alain, the kan-ban board, which will help us to identify task
dependencies a lot better.

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] daily kan-ban update 19may2020

[Luke Kenneth Casson Leighton]

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

except, i can't complete the diagram because i am blocked waiting for Jacob
> to do the DIV and MUL pipelines, which we have found highlights clearly
> what regs are needed in ways that a cursory examination does not reveal.
>

after doing some preliminary checks we also have a block on the reg
allocation task for a TRAP pipeline.

i think what i will do is, morph CompALUUnit to use a Record.

Cesar, CompLDSTUnit also will need converting to use a Record.

this because when grouping the CompUnits together it is a lot easier to do
so using arrays of Records.

however if i do CompALU first you will get an idea of what it will look
like and so are not surprised by code changes.

i will create "dummy" variables in the classes so that it does not require
massive code changes.

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] daily kan-ban update 19may2020

[Cesar Strauss]

Em 19/05/2020 09:36, Luke Kenneth Casson Leighton escreveu:
> i think what i will do is, morph CompALUUnit to use a Record.
> 
> Cesar, CompLDSTUnit also will need converting to use a Record.
> 
> this because when grouping the CompUnits together it is a lot easier to do
> so using arrays of Records.
> 
> however if i do CompALU first you will get an idea of what it will look
> like and so are not surprised by code changes.
> 
> i will create "dummy" variables in the classes so that it does not require
> massive code changes.

Sure, fire away.

Regards,

Cesar


_______________________________________________
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] daily kan-ban update 19may2020

[Jacob Lifshay]

On Tue, May 19, 2020, 05:00 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> except, i can't complete the diagram because i am blocked waiting for Jacob
> to do the DIV and MUL pipelines, which we have found highlights clearly
> what regs are needed in ways that a cursory examination does not reveal.


I'll be working on the mul and div pipelines today, I'm planning on adding
mul-add and mul-sub support to the partitionable multiplier since that's
much easier than writing a whole new multiplier. Will then add the FU
interface logic needed to drive it, perhaps in simplified form (1 mul per
clock, no packing smaller muls together) since that would allow me to get
back to the load/store unit faster. If there's spare time later, it can be
made fancier to allow issuing multiple smaller ops per clock and/or have
fpmul/fpmuladd added.

Will modify the fpdiv pipe to add idiv/udiv/irem/urem as well as div by
zero and int overflow detection, will then use that in the DIV FUs, can add
support for fdiv/fsqrt/frsqrt if there's spare time later.

I picked both those routes since that seems like the path of least
resistance, and because it makes adding fp later that much easier.

Jacob
_______________________________________________
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] daily kan-ban update 19may2020

[Luke Kenneth Casson Leighton]

On Tue, May 19, 2020 at 6:13 PM Jacob Lifshay <programmerjake@gmail.com> wrote:

> I'll be working on the mul and div pipelines today,

ah good, whew

> I'm planning on adding
> mul-add and mul-sub support to the partitionable multiplier since that's
> much easier than writing a whole new multiplier.

true.

(remember, the initial plan is not to use partitioning: just a
straight 64-bit MUL.  we are running in 180nm: latency is not high)

however.... if you feel that this really should be split into 2
pipeline stages, then even without partitioning at all (which,
remember, we are *not* doing - at all - for this critical Oct
deadline) it may indeed be easier to use PartMul because of its
pipeline capability, hard-code the partition bits to "fully open", and
set the "breakdown" point to a matrix of 4x32 or a matrix of 16x16-bit
MULs rather than the 8x8 which we tested the code with, last year.

in particular i think if we went with 4x32-bit MULs it would not
result in massive simulation times.

also now that i think of it, because it already has the
signed/unsigned calculation (done and tested), it may definitely turn
out to be easier to use PartMul than starting from zero.


> Will then add the FU
> interface logic needed to drive it, perhaps in simplified form (1 mul per
> clock, no packing smaller muls together) since that would allow me to get
> back to the load/store unit faster.

if you can cookie-cut soc.fu.shift_rot (cut/paste copy) i did notice
that the input-data and output-data formats are identical to what is
needed for MUL (particularly due to the 3-input MAC).  so that would
just leave the intermediary pipe stages which would be dropped into
soc.fu.shift_rot/pipeline.py ok cookie-cut it would be
soc.fu.mul/pipeline.py

this will get the infrastructure in place very rapidly and give a
template which ultimately just involves filling in main_stage.py and
adjusting pipeline.py

> If there's spare time later, it can be
> made fancier to allow issuing multiple smaller ops per clock and/or have
> fpmul/fpmuladd added.

we're definitely not going to have time to add any of the FP pipeline, at all.

> Will modify the fpdiv pipe to add idiv/udiv/irem/urem as well as div by
> zero and int overflow detection, will then use that in the DIV FUs,

this one i agree fully, yes, good idea, like it.  here, use
soc.fu.logical as a cookie-cut template, using the LogicalInputData
data structure (that's: if you can confirm and agree that it is
identical to what is used, for its register allocation).

> can add support for fdiv/fsqrt/frsqrt if there's spare time later.

there definitely won't.  time is *really* short.

> I picked both those routes since that seems like the path of least
> resistance, and because it makes adding fp later that much easier.

i am inclined to recommend leaving even consideration of FP off the
table, and, when we have time, literally dumping whatever code was
written and replacing it.  although, i suspect that, actually, very
little would actually get thrown away: more... morphed.

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] daily kan-ban update 19may2020

[Michael Nolan]

Today I was going to try and work on the trap block, but it looks like 
Luke is already working on defining the registers for it and I don't 
want to interfere.

I was able to modify caller.py to correctly generate carries, and added 
checking of the carry bit to the alu unit tests. One snarl with that 
though is I am unable to get qemu to show modifications to the carry bit 
in XER for some reason. This isn't an issue for carry (or overflow), but 
it would be good to have for the 32 bit carry and overflow. I may need 
to hold off on the 32 bit versions until I'm able to run tests on a real 
power machine.

I also looked at the differences between nmutil.clz and nmigen's 
PriorityEncoder, and summarized them in 
https://bugs.libre-soc.org/show_bug.cgi?id=326

--Michael


_______________________________________________
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] daily kan-ban update 19may2020

[Luke Kenneth Casson Leighton]

On Tue, May 19, 2020 at 6:47 PM Michael Nolan <mtnolan2640@gmail.com> wrote:
>
> Today I was going to try and work on the trap block, but it looks like
> Luke is already working on defining the registers for it and I don't
> want to interfere.

nope, go for it Michael.  i was just taking notes.  it is end-of-day
here for me anyway.

> I was able to modify caller.py to correctly generate carries, and added
> checking of the carry bit to the alu unit tests. One snarl with that
> though is I am unable to get qemu to show modifications to the carry bit
> in XER for some reason. This isn't an issue for carry (or overflow), but
> it would be good to have for the 32 bit carry and overflow. I may need
> to hold off on the 32 bit versions until I'm able to run tests on a real
> power machine.

ar

> I also looked at the differences between nmutil.clz and nmigen's
> PriorityEncoder, and summarized them in
> https://bugs.libre-soc.org/show_bug.cgi?id=326

yep good call, closed and commented nmigen.clz given that it's better.

have to remember that because PriorityEncoder gets used in a few places.

l.

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

[libre-riscv-dev] priority encoder replacement

[Jacob Lifshay]

On Tue, May 19, 2020, 10:57 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> On Tue, May 19, 2020 at 6:47 PM Michael Nolan <mtnolan2640@gmail.com>
> wrote:
> > I also looked at the differences between nmutil.clz and nmigen's
> > PriorityEncoder, and summarized them in
> > https://bugs.libre-soc.org/show_bug.cgi?id=326
>
> yep good call, closed and commented nmigen.clz given that it's better.
>
> have to remember that because PriorityEncoder gets used in a few places.


If clz is strictly better, replace PriorityEncoder with clz, or just change
clz to match PriorityEncoder's interface and rename it PriorityEncoder,
deleting the old one.

Jacob
_______________________________________________
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] priority encoder replacement

[Luke Kenneth Casson Leighton]

On Tuesday, May 19, 2020, Jacob Lifshay <programmerjake@gmail.com> wrote:


>
>
> If clz is strictly better, replace PriorityEncoder with clz, or just change
> clz to match PriorityEncoder's interface and rename it PriorityEncoder,
> deleting the old one.


it does have some subtle differences, PE sets a flag when the input is
entirely zero.

i do not believe there is an offbyone.  PE will set its output to 0 if bit
0 is 1.  output is 1 if input is 0bxxx10 which is pretty much the
definition of CLZ.

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] daily kan-ban update 19may2020

[Cole Poirier]

Today I am going to attempt to try hooking up the bperm.py module to the
logical pipeline and adding a test for it, using logical/main_stage.py's
OP_CNTZ as a model for OP_BPERM and logical/test/test_pipe_caller.py's
test_cmpb as a model for test_bperm.

Thank you very much for the confidence boost on the formal proof
yesterday Luke, it was very, very helpful.

Cole

_______________________________________________
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] daily kan-ban update 19may2020

[Tobias Platen]

On Tue, 19 May 2020 I was re-reading 'ScoreBoard Mechanics1.pdf' and 'ScoreBoard Mechanics2.pdf'.

_______________________________________________
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] daily kan-ban update 19may2020

[Luke Kenneth Casson Leighton]

On Wed, May 20, 2020 at 7:39 AM Tobias Platen
<libre-soc@platen-software.de> wrote:

> On Tue, 19 May 2020 I was re-reading 'ScoreBoard Mechanics1.pdf' and 'ScoreBoard Mechanics2.pdf'.

they're kinda fascinating, aren't they?

l.

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