[libre-riscv-dev] daily status update 05may2020

[libre-riscv-dev] daily status update 05may2020

[Luke Kenneth Casson Leighton]

i'm going to start doing daily status updates on the list,
"kanban-style".  it would be good if everyone else did as well, as we
can keep in touch and see what's going on.

yesterday i got the preliminary / testing L0CacheBuffer up and
running: the important bit being the PortInterface class which
connects to the LD/ST Computational Units.

today i'll be working on the redesigned LD/ST Computational Unit which
has 3R-2W (indexed and update) capability.
https://libre-soc.org/3d_gpu/ld_st_comp_unit.jpg

the L0CacheBuffer is on the critical path even for testing of the
LDSTCompUnit, because there are several LDSTCompUnits, all connecting
to the (one) L0CacheBuffer.

that's it.  what is everyone else doing?

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 status update 05may2020

[Yehowshua]

> On May 5, 2020, at 6:47 AM, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> 
> yesterday i got the preliminary / testing L0CacheBuffer up and
> running:

Great!

> the important bit being the PortInterface class which
> connects to the LD/ST Computational Units.
> 

What exactly is a LDSTCompUnit? A cursory Google search just brings up Libre-SOC.
Does it take a LD/ST instruction and compute the offset before access?

Why do you call it cache buffer - I’ve only heard the term cache.

Also, how many ways is the cache? Is it configureable - are you pulling in the source from minerva?

> today i'll be working on the redesigned LD/ST Computational Unit which
> has 3R-2W (indexed and update) capability.
> https://libre-soc.org/3d_gpu/ld_st_comp_unit.jpg <https://libre-soc.org/3d_gpu/ld_st_comp_unit.jpg>
Can we have a link to the gittree for this code.
_______________________________________________
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 status update 05may2020

[Yehowshua]

> On May 5, 2020, at 6:47 AM, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> 
> it would be good if everyone else did as well, as we
> can keep in touch and see what's going on.

I’m working my way through the codebase and slowly adding documentation.

I was hired by Georgia Tech to revise critical parts of the Computer Architecture curriculum and I have to write my Thesis this summer - about 14 hours a day - so yeah - slowly documenting.

Talking to some lawyers about bringing in the Libre-SOC and Kazan trademarks under Systèmes Libres.

Also, discussing equity. Individuals who made contributions to Libre-SOC in the past and who continue to make contributions until seed-funding of Systèmes Libres are eligible for equity according to the Slicing Pie model.

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] daily status update 05may2020

[Luke Kenneth Casson Leighton]

On Tue, May 5, 2020 at 2:02 PM Yehowshua <yimmanuel3@gatech.edu> wrote:

> What exactly is a LDSTCompUnit? A cursory Google search just brings up Libre-SOC.

:)  Load Store Computational Unit.

see Mitch Alsup's "Scoreboard Mechanics" chapters (which are a
critical pre-requisite to read, for understanding).

10.4.6 A Computational Unit
A Computational Unit is responsible for the data manipulation of an
instruction, while the
Function Unit is responsible for the data-flow of an instruction.
Thus, a CDC 6600
Computational Unit will contain storage for the 6-bit instruction,
storage for both operand
values, storage for the result value(s), and a ​Timing Chain​. The
timing chain is used to
generate the Request_Release signal back to the ScoreBoard, at the
appropriate point in
time. Some more modern Function Units will have implicit Request_Release timing.

therefore, a  "Load Store Computational Unit" is responsible for the
data-manipulation side of LOAD and STOREs.

> Does it take a LD/ST instruction and compute the offset before access?

it "manages":

* the computation of the Effective Address,
* the communcation to the actual LOAD/STORE memory
* the sending (ST) or receipt (LD) of data

i just updated the docstring to explain it further:
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/experiment/compldst_multi.py;hb=HEAD

> Why do you call it cache buffer - I’ve only heard the term cache.

because it effectively performs both roles.  it both buffers the LD/ST
data and also has some of the characteristics of a cache.  and because
i couldn't decide which it was :)

> Also, how many ways is the cache?

one.  it's not a "normal" cache.

> Is it configureable

yes, however it strictly matches the total number of LDSTCompUnits as
inputs, and is strictly and specifically designed to have "dual ports"
- connecting to interleaved odd-even *dual* L1 128-bit-wide Caches.

  https://libre-soc.org/3d_gpu/twin_l0_cache_buffer.jpg

so the "options" are hard-coded by other resources.  its role is
basically to "merge" a whopping *SIXTEEN* non-cache-aligned individual
and narrow LD/ST operations into (two) wide cache-aligned
operations... *on every clock cycle*.

yes, 16 incoming 64-bit requests on every cycle.

yes, 2 outgoing 128-bit requests on every cycle.

this is the only way we're going to meet the (insane) memory bandwidth
requirements of a GPU.


> are you pulling in the source from minerva?

that's already been done.  i described this yesterday.

the plan is to move the source code from minerva for the L1 Caches
(and delete everything else as extraneous), widen the minerva L1 cache
code to 128 bit wide cache lines, and add double 64-bit Wishbone
Interfaces to *each*.

we'll need Wishbone Arbiters to do that.

> > today i'll be working on the redesigned LD/ST Computational Unit which
> > has 3R-2W (indexed and update) capability.
> > https://libre-soc.org/3d_gpu/ld_st_comp_unit.jpg <https://libre-soc.org/3d_gpu/ld_st_comp_unit.jpg>
> Can we have a link to the gittree for this code.

yes, sorry.  just committed the work-in-progress:
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/experiment/compldst_multi.py;hb=HEAD

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 status update 05may2020

[Luke Kenneth Casson Leighton]

On Tue, May 5, 2020 at 2:07 PM Yehowshua <yimmanuel3@gatech.edu> wrote:
>
>
>
> > On May 5, 2020, at 6:47 AM, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> >
> > it would be good if everyone else did as well, as we
> > can keep in touch and see what's going on.
>
> I’m working my way through the codebase and slowly adding documentation.

ah good.  thank you for this, yehowshua.

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 status update 05may2020

[Tobias Platen]

Today I was mostly reading documentation for the add[o][.], subf[o][.], adde*, subfe*, addze*, neg*, mullw*, divw* instructions that I will implement tomorrow in the simulator.

On Tue, 5 May 2020 11:47:32 +0100
Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:

> i'm going to start doing daily status updates on the list,
> "kanban-style".  it would be good if everyone else did as well, as we
> can keep in touch and see what's going on.
> 
> yesterday i got the preliminary / testing L0CacheBuffer up and
> running: the important bit being the PortInterface class which
> connects to the LD/ST Computational Units.
> 
> today i'll be working on the redesigned LD/ST Computational Unit which
> has 3R-2W (indexed and update) capability.
> https://libre-soc.org/3d_gpu/ld_st_comp_unit.jpg
> 
> the L0CacheBuffer is on the critical path even for testing of the
> LDSTCompUnit, because there are several LDSTCompUnits, all connecting
> to the (one) L0CacheBuffer.
> 
> that's it.  what is everyone else doing?
> 
> l.
> 
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev@lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev


-- 
Tobias Platen <libre-soc[at]platen-software[dot]de>

_______________________________________________
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 status update 05may2020

[Michael Nolan]

On 5/5/20 6:47 AM, Luke Kenneth Casson Leighton wrote:
> i'm going to start doing daily status updates on the list,
> "kanban-style".  it would be good if everyone else did as well, as we
> can keep in touch and see what's going on.

I worked some on the floating point pipelined cordic, adding 
FPPipeContext tracking so it could be integrated with the FPU. I also 
fixed test_decoder_gas, and began working on adding branches to the 
pseudocode simulator. Basic branches (b, ba) should work, conditional 
ones and branch with link, not so much.

--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 status update 05may2020

[Cole Poirier]

> On May 5, 2020, at 3:48 AM, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> 
> i'm going to start doing daily status updates on the list,
> "kanban-style".  it would be good if everyone else did as well, as we
> can keep in touch and see what's going on.
> 
> ...
> 
> that's it.  what is everyone else doing?
> 
> l.

I worked on the coriolis2 chroot setup script. The basics are finally working properly, now I’m starting to add the libraries and tools that must be compiled from source.

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 status update 05may2020

[Luke Kenneth Casson Leighton]

On Tuesday, May 5, 2020, Tobias Platen <libre-soc@platen-software.de> wrote:

> Today I was mostly reading documentation for the add[o][.], subf[o][.],
> adde*, subfe*, addze*, neg*, mullw*, divw* instructions that I will
> implement tomorrow in the simulator.


fantastic, that's really helpful.

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 status update 05may2020

[Luke Kenneth Casson Leighton]

On Tuesday, May 5, 2020, Michael Nolan <mtnolan2640@gmail.com> wrote:

>
> I worked some on the floating point pipelined cordic, adding FPPipeContext
> tracking so it could be integrated with the FPU. I also fixed
> test_decoder_gas, and began working on adding branches to the pseudocode
> simulator. Basic branches (b, ba) should work, conditional ones and branch
> with link, not so much.


still excellent.  coordinating with tobias, working in separate areas you
should do fine.

if it would help, check in pearpc see how it's done.  generic subdirectory
not the JIT ones.  alain should know where.

at least with the simulator there is no need to be concerned about pipeline
latency.

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 status update 05may2020

[Luke Kenneth Casson Leighton]

On Tuesday, May 5, 2020, Cole Poirier <colepoirier@gmail.com> wrote:

>
> I worked on the coriolis2 chroot setup script. The basics are finally
> working properly, now I’m starting to add the libraries and tools that must
> be compiled from source.


fantastic.

if you coordinate with yehowshua he can link it on the docs pages.

remember though yehowshua there exists HDL_workflow and the coriolis2 pages
so duplicating or superceding those, not productive.

Alain, Jacob?




-- 
---
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 status update 05may2020

[Michael Nolan]

On 5/5/20 3:11 PM, Tobias Platen wrote:
> Today I was mostly reading documentation for the add[o][.], subf[o][.], adde*, subfe*, addze*, neg*, mullw*, divw* instructions that I will implement tomorrow in the simulator.

Which simulator are we using now? There's internalop_sim.py and the 
autogenerated one in decoder/isa.

--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 status update 05may2020

[Luke Kenneth Casson Leighton]

On Tuesday, May 5, 2020, Michael Nolan <mtnolan2640@gmail.com> wrote:

> On 5/5/20 3:11 PM, Tobias Platen wrote:
>
>> Today I was mostly reading documentation for the add[o][.], subf[o][.],
>> adde*, subfe*, addze*, neg*, mullw*, divw* instructions that I will
>> implement tomorrow in the simulator.
>>
>
> Which simulator are we using now? There's internalop_sim.py and the
> autogenerated one in decoder/isa.


autogenerated.  good catch michael.  no need to implement code that already
exists.

unit tests need to be written for them however, to confirm that they work.
that funnily enough is more work as you have to test corner cases esp. on
carryin and out.

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 status update 05may2020

[Cole Poirier]

> On May 5, 2020, at 3:03 PM, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> 
> On Tuesday, May 5, 2020, Cole Poirier <colepoirier@gmail.com> wrote:
> 
>> 
>> I worked on the coriolis2 chroot setup script. The basics are finally
>> working properly, now I’m starting to add the libraries and tools that must
>> be compiled from source.
> 
> 
> fantastic.
> 
> if you coordinate with yehowshua he can link it on the docs pages.
> 
> remember though yehowshua there exists HDL_workflow and the coriolis2 pages
> so duplicating or superceding those, not productive.

In the process of scripting HDL_workflow.coriolis2 I’ve found a good number of things in the coriolis2 part of the workflow that conflict with each other or don’t quite work. I’m planning on finishing my testing of that section tomorrow, so I will coordinate with Yehowshua when I make my modifications to the HDL_Workflow.coriolis2  wiki via this bug report "Bug 291 - HDL Workflow and Coriolis2 chroot automated setup scripts” <https://bugs.libre-soc.org/show_bug.cgi?id=291>.

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 status update 05may2020

[Jacob Lifshay]

On Tue, May 5, 2020 at 3:48 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
> that's it.  what is everyone else doing?

I saw the phoronix article that the wayland book is now freely
available, so I ended up reading it since it will be useful for
implementing wayland support in Kazan later.
https://www.phoronix.com/scan.php?page=news_item&px=Wayland-Book-Free

I mentioned that our project extensively uses reset_less=True with
combinatorial signals on the now-closed nmigen bug about adding
warnings for that case:
https://github.com/nmigen/nmigen/issues/379

I ended up adding the DEFERRED status to the bugzilla installation,
since that way bugs will still show up in the lists of open bugs but
it's obvious from a glance that we aren't worrying about them right
now.

I'm in the midst of figuring out the load/store code Luke wrote, so
you may not see much activity right away.

I read through some of the latest progress on all of PyO3, rust's
RFCs, gitlab-rust, and a few others.

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 status update 05may2020

[Luke Kenneth Casson Leighton]

On Wednesday, May 6, 2020, Jacob Lifshay <programmerjake@gmail.com> wrote:

> On Tue, May 5, 2020 at 3:48 AM Luke Kenneth Casson Leighton
> <lkcl@lkcl.net> wrote:
> > that's it.  what is everyone else doing?
>
> I saw the phoronix article that the wayland book is now freely
> available, so I ended up reading it since it will be useful for
> implementing wayland support in Kazan later.
> https://www.phoronix.com/scan.php?page=news_item&px=Wayland-Book-Free


nice.


>
> I mentioned that our project extensively uses reset_less=True with
> combinatorial signals on the now-closed nmigen bug about adding
> warnings for that case:
> https://github.com/nmigen/nmigen/issues/379


there is a resetless domain.



>
> I ended up adding the DEFERRED status to the bugzilla installation,
> since that way bugs will still show up in the lists of open bugs but
> it's obvious from a glance that we aren't worrying about them right
> now.


ok good idea


>
> I'm in the midst of figuring out the load/store code Luke wrote, so
> you may not see much activity right away.


ok.

do ask questions.  incremental approach.  questions is activity and is
perfectly 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] daily status update 05may2020

[Luke Kenneth Casson Leighton]

On Wed, May 6, 2020 at 10:34 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:

>> I mentioned that our project extensively uses reset_less=True with
>> combinatorial signals on the now-closed nmigen bug about adding
>> warnings for that case:
>> https://github.com/nmigen/nmigen/issues/379
>
>
> there is a resetless domain.

... which probably wouldn't have helped.

thank you for taking care of that: it would have been a royal pain in
the neck to suddenly have thousands of unnecessary warnings.

btw as an example, the CompUnits have an explicit "reset" capability -
a line named "go_die".  when that's asserted, the SR Latches reset
back to "known-good".  to have a "hidden nice convenient reset line"
to every single synchronous signal would be a huge waste of resources.
likewise the Dependency Matrices have a similar thing.

nice reset is great for FPGAs.  it's also useful for interface code,
to get it back into a known-good state.

we *do* use reset - i think - in the pipeline register-latch API,
because that's a place where it's needed.  although, there, again, for
"mask cancellable" pipelines we do *not* need "reset"... because
pulling the mask-cancel bit *does that exact same job*.

l.

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