[libre-riscv-dev] lots of stuff broken

[Luke Kenneth Casson Leighton]

On Sun, Jul 19, 2020 at 7:55 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Sat, Jul 18, 2020, 15:19 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:
>
> > hiya jacob,
> >
> > um, the div unit changes is breaking a lot of things that terminates
> > any possibility of doing work.
> >
>
> sorry, I incorrectly assumed you weren't currently using it due to the
> large size of the current div pipeline.

whilst the simulation is slow (and when uploading to an ecp5 is
possible it will take longer) it still allows me - everyone not just
me - to run the unit tests.  and to add new ones.

with those Div unit tests in place, this will be how it becomes
possible for you, jacob, to side-step to the new Div unit and have
confidence that it will work, because the unit tests pass.

in that way it is "safe" for you to work - in parallel - without
psychological pressure of being a significant block to progress.

with a "working" Div unit it is also possible to move further on to
other tests such as the "hello_world" test, micropython, and many
more.

if the code is not working it is therefore a real serious critical
blocker that prevents and prohibits *all* work and all testing that
critically relies on having support for any "div" operations.


> it's not designed for having extra parameters.  if you need two
> > different kinds, then that means having two differerent DivPipeSpec
> > classes: one for the Comb work, one for the Sync work.
> >
>
> ah, ok. I was assuming the constructor would be able to be called directly,
> allowing easily adding an extra parameter, instead of through some generic
> multi-level abstraction.

parameters (pspec) are typically for reconfiguring things in the
pipeline.  width of bus.  number of stages.

the key (only allowed) parameter "id_wid" is for the ReservationStation width.

it *is* possible to do dynamic merging - dynamic construction of
mix-in classes: DynamicPipe is a meta-class that... well... you can
read up on it at the links in the source code:
https://git.libre-soc.org/?p=nmutil.git;a=blob;f=src/nmutil/dynamicpipe.py;hb=HEAD

DynamicPipe allows us to "mix in" alternative pipeline base classes
(SimpleHandshakeRedir, MaskCancellable) without a total rewrite and
without having dozens if not hundreds of special mix-in classes or,
worse, large-scale deployment of "redirector" classes with functions
whose sole purpose is to call identical functions of a sub-object,
with the exact same API.

however the experience of deploying and using that type of
meta-programming comes with a warning: the actual construction (and in
particular correct calling of __init__) is... fraught.  it's one of
the only legitimate places where you would use the 3-argument version
of the python "type" function (to literally dynamically construct a
class, on-the-fly).

the same technique *could* be deployed here - place the DivPipeKind
into the pspec:

    pspec.div_pipe_type = DivPipeKind.SimOnly.config() # or something

however i would seriously not recommend it.

i think what's there, now - the fact that there is a default argument
- is "good enough".

 class DivPipeSpec(CommonPipeSpec):
-    def __init__(self, id_wid, div_pipe_kind):
+    def __init__(self, id_wid, div_pipe_kind=None):
+        if div_pipe_kind is None:
+            div_pipe_kind = DivPipeKind.DivPipeCore

that default argument can be "flipped over" when you are confident
that the Div FSM works, and passes all unit tests.

those btw are:

* fu/div/test/test_pipe_caller.py
* fu/compunit/test/test_div_compunit.py (or, it should be... *sigh* -
it needs writing)
* simple/test/test_core.py
* simple/test/test_issuer.py by adding the unit tests imported from
div test_pipe_caller.py

the way that those work are:

* test_pipe_caller.py simply tests the actual pipeline.
* test_div_compunit.py tests whether the pipeline correctly interacts
with its "Manager" - a CompAluMulti instance
* test_core.py tests whether the pipeline correctly interacts with
register files through its "Manager"
* test_issuer.py tests whether the pipeline correctly responds to
actual instructions as issued from actual Instruction memory.

i tend not to run test_core.py any more because it's kinda served its
purpose: test_issuer.py sort-of supercedes it (and is just as big).

at the *very minimum* you should be running the div
test_pipe_caller.py (and not modifying it, except to add new unit
tests) and test_issuer.py after uncommenting the div tests.

l.