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

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

[Luke Kenneth Casson Leighton]

yesterday:

* split out Popcount into separate module, used by Logical pipeline
* added MFMSR and MTMSR to the CSV files (they were missing)
* created a new SPR pipeline bugreport
* completed a rather large update to make every pipeline use "Data" for
  for output, because of the "ok" signalling it provides.
* documented which regfiles are needed.
* worked out a test plan for how to test the pipelines by connecting
   them to regfiles in a very, very basic way.

this morning:

* reviewed DataMerger beginnings (Tobias: see #216)
* added zero_a support to LDSTCompUnit (and a preliminary test)

planned today:

* define some regfiles and their ports
* work out how to do the link and test of pipelines to regfiles

blocked:

* (Cesar) the multi-process unit test for MultiCompUnit is critical to
   proceeding with a test of the pipelines when they are accessed
   through MultiCompUnit.  the exact same functions are needed.
* (Jacob) DIV and MUL pipeline stages in ieee754fpu, for integration
   into corresponding soc.fu.*.main_stage

_______________________________________________
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 25may2020

[Tobias Platen]

yesterday:
	begun work on DataMerger
this morning:
	reading the whole bug report related to #216
planned this evening:
	more work on Datamerger

_______________________________________________
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 25may2020

[Luke Kenneth Casson Leighton]

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

> yesterday:
>         begun work on DataMerger


looks good tobias.  i updated the docstring.  should actually be really
short, despite being strategically a critical component.

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 25may2020

[Michael Nolan]

Today I'm working on understanding how the MultiCompUnit from 
compalu_multi.py works, and how to go about formally verifying it.

--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 25may2020

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Mon, May 25, 2020 at 5:39 PM Michael Nolan <mtnolan2640@gmail.com> wrote:
>
> Today I'm working on understanding how the MultiCompUnit from
> compalu_multi.py works, and how to go about formally verifying it.

cool.  here's some notes:

1. i moved compunit_multi.py's docstring to here (it was a bit long):
https://libre-soc.org/3d_gpu/architecture/compunit/  there, you will
find a description of the crucial stages that a CompUnit goes through.

2. if you set n_src=1, and n_dst=1, and you pass it a CompNNNOpSubset
that has neither an imm_data nor a zero_a, you end up preeettty much
exactly with this:
https://libre-soc.org/3d_gpu/comp_unit_req_rel.jpg

3. if however you have n_src=3 and n_dst=2, and you pass in an
opsubset that has an imm_data, you end up with something like this
(ignore go_adr and go_st for now):
https://libre-soc.org/3d_gpu/ld_st_comp_unit.jpg

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 25may2020

[Cesar Strauss]

The day before yesterday:

 * Helped Luke add an optional zero_a immediate option to MultiCompUnit

Yesterday:

 * Continued examining the simulated output of compalu_multi.py on
GTKWave to better understand the rel/go protocol and the overall
behavior of MultiCompUnit. This will help with the unit tests.
 * In the process, understood better how nMigen Signals and Records are
shown (or not) in GTKWave. Hints: (1) do not use the exact same "name"
parameter for distinct signals. (2) Do use the "name" parameter on
Records when necessary.

This morning:

 * Refined my knowledge of the parallel simulation capability of
nMigen, taking a look at src/nmutil/test/test_buf_pipe.py.
 * Implemented a proof of concept of a parallel test.

planned today:

 * Use the parallel test capability of nMigen to simulate multiple
concurrent ports of the Scoreboard, giving a more comprehensive coverage
of MultiCompUnit.

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 25may2020

[Luke Kenneth Casson Leighton]

On Mon, May 25, 2020 at 6:42 PM Cesar Strauss <cestrauss@gmail.com> wrote:

> The day before yesterday:
>
>  * Helped Luke add an optional zero_a immediate option to MultiCompUnit

i must apologise, it would seem that even just talking with you
accelerates what i am able to do.  i must try to divert my attention
away and allow you to get on with some things :)

> Yesterday:
>
>  * Continued examining the simulated output of compalu_multi.py on
> GTKWave to better understand the rel/go protocol and the overall
> behavior of MultiCompUnit. This will help with the unit tests.

the rel/go protocol is extremely simple (this for michael as well):

* when rel[x] is raised, go[x] must (not immediately, but at some
point, from 0 to N cycles in the future) be raised, and it must be
raised once and only once, for one clock cycle and one clock cycle
only.

* once go[x] is raised, rel[x] must de-assert exactly one clock cycle
from that point, and it must *remain* de-asserted until busy_o is
de-asserted.


>  * In the process, understood better how nMigen Signals and Records are
> shown (or not) in GTKWave.

sigh.  there is actually a bug in nmigen which stops top-level signals
from even being listed in gtkwave.  michael tracked down a workaround.

> Hints: (1) do not use the exact same "name"
> parameter for distinct signals. (2) Do use the "name" parameter on
> Records when necessary.
>
> This morning:
>
>  * Refined my knowledge of the parallel simulation capability of
> nMigen, taking a look at src/nmutil/test/test_buf_pipe.py.
>  * Implemented a proof of concept of a parallel test.

yes, i saw - i filled in some stub (TODO) comments.

> planned today:
>
>  * Use the parallel test capability of nMigen to simulate multiple
> concurrent ports of the Scoreboard, giving a more comprehensive coverage
> of MultiCompUnit.

excellent.  this test class actually becomes quite important as i
would like to use it as the basis for feeding data into the
soc.fu.compunits that you can see in that module.

the bit of "weirdness" about the parallel test capability of nMigen is:

1) it's not actually parallel: it's a co-iterative event-driven
simulation which steps through even "tick" (each yield) ensuring that
each and every one of them is kept in time-step depending on the clock
"pulse" that each "yielding" function returns.

2) it is slightly weird given that you can actually pass a parameter
(or parameters) to each of the functions, like this:

    test = CompUnitParallelTest(dut)
    run_simulation(dut, [test.driver(),
                         test.monitor(),
                         test.rd(0), # one read port (a)
                         test.rd(1), # one read port (b)
                         test.wr(0)  # one write port (o)
                        ],
                   vcd_name="test_compunit_parallel.vcd")

where test.rd() and test.wr() are defined like this:

class CompUnitParallelTest:
    def rd(self, rd_idx):
        # monitor self.dut.rd.req[rd_idx] and sets dut.rd.go[idx] for one cycle
        yield

so that parameter rd_idx is *DIFFERENT* for each "instance" of the
[not-]parallel tests, and we exploit this to get one function to
monitor dut.rd.req[0] and set dut.rd.go[0], another to look at
dut.rd.req[1] and dut.rd.go[1] and so on.

note, Cesar, i just put a quick extra bit into the TODO notes,

         # TODO: also when dut.rd.go is set, put the expected value into
-        # the src_i.
+        # the src_i.  use dut.get_in[rd_idx] to do so

so basically in this way, everything about the read(idx) function
involves data and signals that are indexed by "idx", and likewise for
the write(idx) function.

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 25may2020

[Jacob Lifshay]

On Mon, May 25, 2020, 05:31 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> * (Jacob) DIV and MUL pipeline stages in ieee754fpu, for integration
>    into corresponding soc.fu.*.main_stage


Will be working on the mul and div pipelines today, created an enum of all
the ops supported by the div pipeline on friday.

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 25may2020

[Luke Kenneth Casson Leighton]

On Mon, May 25, 2020 at 8:30 PM Jacob Lifshay <programmerjake@gmail.com> wrote:
>
> On Mon, May 25, 2020, 05:31 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
> wrote:
>
> > * (Jacob) DIV and MUL pipeline stages in ieee754fpu, for integration
> >    into corresponding soc.fu.*.main_stage
>
>
> Will be working on the mul and div pipelines today,

superb.

> created an enum of all the ops supported by the div pipeline on friday.

yeh saw that, especially the notes about how POWER complies with c semantics.

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 25may2020

[Cole Poirier]

Took yesterday off. Thanks for your help Michael and Luke. Today I took
a look at what Michael and Luke did to fix Bpermd so it passed the
fu/logical/test_pipe_caller.py tests, it seems like there was a previous
module in that test messing with the value of register a which caused my
module to erroneously fail when I tried adding the modifications to
bpermd.py that are now there from Michael. What should I do next? Should
I try optimizing the gate count of bpermd, or is there something more
helpful I can work on today?



_______________________________________________
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 25may2020

[Luke Kenneth Casson Leighton]

On Monday, May 25, 2020, Cole Poirier <colepoirier@gmail.com> wrote:

> Took yesterday off. Thanks for your help Michael and Luke. Today I took
> a look at what Michael and Luke did to fix Bpermd so it passed the
> fu/logical/test_pipe_caller.py tests, it seems like there was a previous
> module in that test messing with the value of register a which caused my
> module to erroneously fail when I tried adding the modifications to
> bpermd.py that are now there from Michael.


sigh that was an annoying weird bug.

 i think 316 can be closed now

What should I do next? Should
> I try optimizing the gate count of bpermd, or is there something more
> helpful I can work on today?


in your wiki home page you will find a link to bugs assigned to you.  the
default action is basically "monitor and do that list".

one to add:

if you can also find the "interfaces" issue, and assign it to yourself, you
will see a list of interfaces in the last comment, including "serialized
irq" which you shouls find somewhere from raptor engineering.

can you track the source code down, add them to the wiki  under the right
subdurectory (shakti mclass) and also crossreference them in the bugtracker?

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 25may2020

[Cole Poirier]

On May 25 2020, at 2:35 pm, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> in your wiki home page you will find a link to bugs assigned to you.  the
> default action is basically "monitor and do that list".

Thanks that makes it easy. I saw you assigned me 'Bug 337 - Convention
for register outputs in *OutputData structures is to use "Data"', and
looked at your comment. Is this simply reorg or is there something
additional I should be aware of?
 
> one to add:
> 
> if you can also find the "interfaces" issue, and assign it to
> yourself, you
> will see a list of interfaces in the last comment, including "serialized
> irq" which you shouls find somewhere from raptor engineering.
> 
> can you track the source code down, add them to the wiki  under the right
> subdurectory (shakti mclass) and also crossreference them in the bugtracker?


Are you referring to "Bug 304 - Define minimum viable interface set for
180nm ASIC", comment #6?
```
Luke Kenneth Casson Leighton 2020-05-20 23:14:26 BST

conversation notes from Tim (Raptor Engineering)

priority:

* 2x SPI master
* 4x I2C master
* 2x UART
* 4x LPC master
* EINT* Serialsed IRQ (LPC, from PCIe) - 15 or so IRQs, these are
PC>PCIe>OpenPower mappings

Quad SPI raptorengineering
LPC bridge github raptorengineering
```

I searched for "raptor serialized irq, and only found references to
raptors lpc-spi-bridge-fpga gitlab repo. Is this what we need
https://gitlab.raptorengineering.com/raptor-engineering-public/lpc-spi-bridge-fpga?
An in terms of adding the source code to the wiki, do you want me to
just copy and paste the 1000+ line verilog file or files to the
soc/libreriscv/shakti/m_class directory? Or do you want me to do
something similar to what you did for sdram.mdwn in the same directory?

```
# SDRAM

* <https://bitbucket.org/casl/c-class/src/3fba75dfbd0c64815eb8ec6dc965666812c44bae/src/peripherals/sdram/?at=master>
* <https://opencores.org/projects/sdr_ctrl>
```

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 25may2020

[Luke Kenneth Casson Leighton]

On Monday, May 25, 2020, Cole Poirier <colepoirier@gmail.com> wrote:

> On May 25 2020, at 2:35 pm, Luke Kenneth Casson Leighton <lkcl@lkcl.net>
> wrote:
> > in your wiki home page you will find a link to bugs assigned to you.  the
> > default action is basically "monitor and do that list".
>
> Thanks that makes it easy. I saw you assigned me 'Bug 337 - Convention
> for register outputs in *OutputData structures is to use "Data"', and
> looked at your comment. Is this simply reorg or is there something
> additional I should be aware of?


ah i think i kinda did that one yesterday.


>
> > one to add:
> >
> > if you can also find the "interfaces" issue, and assign it to
> > yourself, you
> > will see a list of interfaces in the last comment, including "serialized
> > irq" which you shouls find somewhere from raptor engineering.
> >
> > can you track the source code down, add them to the wiki  under the right
> > subdurectory (shakti mclass) and also crossreference them in the
> bugtracker?
>
>
> Are you referring to "Bug 304 - Define minimum viable interface set for
> 180nm ASIC", comment #6?


yes.


> ```
> Luke Kenneth Casson Leighton 2020-05-20 23:14:26 BST
>
> conversation notes from Tim (Raptor Engineering)
>
> priority:
>
> * 2x SPI master
> * 4x I2C master
> * 2x UART
> * 4x LPC master
> * EINT* Serialsed IRQ (LPC, from PCIe) - 15 or so IRQs, these are
> PC>PCIe>OpenPower mappings
>
> Quad SPI raptorengineering
> LPC bridge github raptorengineering
> ```
>
> I searched for "raptor serialized irq, and only found references to
> raptors lpc-spi-bridge-fpga gitlab repo. Is this what we need
> https://gitlab.raptorengineering.com/raptor-engineering-public/lpc-spi-
> bridge-fpga?


that sort of thing.

we need to find the full implementation, an actual serialized-irq master



> An in terms of adding the source code to the wiki,


> do you want me to
> just copy and paste the 1000+ line verilog file or files to the
> soc/libreriscv/shakti/m_class directory?


no!  a wiki is not a source code repository, it is for documentation



> Or do you want me to do
> something similar to what you did for sdram.mdwn in the same directory?


yes.


>
> ```
> # SDRAM
>
> * <https://bitbucket.org/casl/c-class/src/3fba75dfbd0c64815eb8ec6dc96566
> 6812c44bae/src/peripherals/sdram/?at=master>
> * <https://opencores.org/projects/sdr_ctrl>
> ```
>
> Cole
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev@lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>


-- 
---
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 25may2020

[Cole Poirier]

May 25 2020, at 3:45 pm, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> we need to find the full implementation, an actual serialized-irq master

After about 30 min of googling I've only been able to find the following
which I believe from the below copyright is what you're looking for?

```
$Id: serirq_host.v,v 1.2 2008-12-27 19:46:18 hharte Exp $   ////
////  serirq_host.v - SERIRQ Host Controller                      ////
////                                                              ////
////  This file is part of the Wishbone LPC Bridge project        ////
////  http://www.opencores.org/projects/wb_lpc/                   ////
////                                                              ////
////  Author:                                                     ////
////      - Howard M. Harte (hharte@opencores.org) 
```
https://opencores.org/websvn/filedetails?repname=wb_lpc&path=%2Fwb_lpc%2Ftrunk%2Frtl%2Fverilog%2Fserirq_host.v

Once you let me know if this is correct I'll add it to the wiki and
crossref with bug 304.

Aside from this, my only other active bug report is to do with fixing
one small thing in coriolis2 chroot setup script and documenting the
changes to the hdl_workflow on the wiki. Is there HDL work that I can
take on? Possibly some formal proofs that I could see if I can crack?

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 25may2020

[Luke Kenneth Casson Leighton]

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

> May 25 2020, at 3:45 pm, Luke Kenneth Casson Leighton <lkcl@lkcl.net>
> wrote:
> > we need to find the full implementation, an actual serialized-irq master
>
> After about 30 min of googling I've only been able to find the following
> which I believe from the below copyright is what you're looking for?
>
> ```
> $Id: serirq_host.v,v 1.2 2008-12-27 19:46:18 hharte Exp $   ////
> ////  serirq_host.v - SERIRQ Host Controller                      ////
> ////                                                              ////
> ////  This file is part of the Wishbone LPC Bridge project        ////
> ////  http://www.opencores.org/projects/wb_lpc/                   ////
> ////                                                              ////
> ////  Author:                                                     ////
> ////      - Howard M. Harte (hharte@opencores.org)
> ```
> https://opencores.org/websvn/filedetails?repname=wb_lpc&
> path=%2Fwb_lpc%2Ftrunk%2Frtl%2Fverilog%2Fserirq_host.v
>
> Once you let me know if this is correct I'll add it to the wiki and
> crossref with bug 304.


it looks like it.  we can ask Raptor Engineering.


>
> Aside from this, my only other active bug report is to do with fixing
> one small thing in coriolis2 chroot setup script and documenting the
> changes to the hdl_workflow on the wiki. Is there HDL work that I can
> take on?


yes.  the multiport Regfile one.
https://bugs.libre-soc.org/show_bug.cgi?id=351

 it should be simple to do, it is just to use Cat() on the 8 ports data.

however it should be done under a Mux which ensures only one reader/writer

i will write more in the bugreport.

this one is time sensitive.


> Possibly some formal proofs that I could see if I can crack?


actually one for Regfile and RegfileArray would be good.

if you can raise a bugreport about that?

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 25may2020

[Cole Poirier]

On May 25 2020, at 4:40 pm, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> On Tuesday, May 26, 2020, Cole Poirier <colepoirier@gmail.com> wrote:
>> https://opencores.org/websvn/filedetails?repname=wb_lpc&
>> path=%2Fwb_lpc%2Ftrunk%2Frtl%2Fverilog%2Fserirq_host.v
>> 
>> Once you let me know if this is correct I'll add it to the wiki and
>> crossref with bug 304.
> 
> 
> it looks like it.  we can ask Raptor Engineering.

Ok. I'll make a note on bug 304 that you will ask Raptor engineering
about this document? Then after we have confirmed I'll add it to the
repo in our mdwn file format for referencing external resources, and
note on this on the bug report.

> yes.  the multiport Regfile one.
> https://bugs.libre-soc.org/show_bug.cgi?id=351
> 
> it should be simple to do, it is just to use Cat() on the 8 ports data.
> 
> however it should be done under a Mux which ensures only one reader/writer
> 
> i will write more in the bugreport.
> 
> this one is time sensitive.

Awesome! I'll start now.

>> Possibly some formal proofs that I could see if I can crack?
> 
> 
> actually one for Regfile and RegfileArray would be good.
> 
> if you can raise a bugreport about that?

Will do this now then start on the multiport regfile task.

Cole

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