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

[Luke Kenneth Casson Leighton]

On Mon, May 25, 2020 at 6:42 PM Cesar Strauss <cestrauss at 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.