[libre-riscv-dev] lots of stuff broken
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Sun Jul 19 11:46:49 BST 2020
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>
> > 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
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:
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
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".
- 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/compunit/test/test_div_compunit.py (or, it should be... *sigh* -
it needs writing)
* simple/test/test_issuer.py by adding the unit tests imported from
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.
More information about the libre-riscv-dev