Libre RISC-V Mailing list Archives (accessible via public-inbox)
 help / color / Atom feed
* [libre-riscv-dev] lots of stuff broken
@ 2020-07-18 22:18 Luke Kenneth Casson Leighton
  2020-07-19  6:55 ` Jacob Lifshay
  0 siblings, 1 reply; 12+ messages in thread
From: Luke Kenneth Casson Leighton @ 2020-07-18 22:18 UTC (permalink / raw)
  To: Libre-RISCV General Development

hiya jacob,

um, the div unit changes is breaking a lot of things that terminates
any possibility of doing work.

i can't run any of the compunit tests, or test_issuer.py (the main
test i use for verifying the core is operational).  could you make
sure in future to run some of the unit tests, and also rather than
make major adjustments to code that's in use in ways that cause
significant failures (only partially changing names of classes from
DIVXXX to DivXXX without doing a global search/replace throughout the
code), put in place migration plans?

for example: if you make major name changes without a global
search/replace, put a temporary variable (commented), "DIVXXX=DivXXX"
with a "TODO: complete transition to new name".

the better strategy would have been to start a new subdirectory with
the new code - or just new filenames
pipe_data_to_be_replaced_once_working.py

regarding DivPipeSpec:

class DivPipeSpec(CommonPipeSpec):
    def __init__(self, id_wid, div_pipe_kind):
        super().__init__(id_wid=id_wid)
        self.div_pipe_kind = div_pipe_kind
        self.core_config = div_pipe_kind.config.core_config

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.

then in compunits.py, different Function Units are declared as follows:

class DivFunctionUnitWhateverType(FunctionUnitBaseSingle):
    fnunit = Function.DIV
    def __init__(self, idx):
        super().__init__(DivPipeSpecWhateverType, DivBasePipe, idx)

class DivFunctionUnitCombType(FunctionUnitBaseSingle):
    fnunit = Function.DIV
    def __init__(self, idx):
        super().__init__(DivPipeSpecCombType, DivBasePipe, idx)

anyway.  i worked out that this is "fixable" by giving DivPipeSpec a
default argument.

l.


compunits/compunits.py:221: UnusedElaboratable:
<soc.fu.compunits.compunits.DivFunctionUnit object at 0x7f0a131a57f0>
created but never used
  self.fus["%s%d" % (name, i)] = kls(i)
UnusedElaboratable: Enable tracemalloc to get the object allocation traceback
E
======================================================================
ERROR: run_all (__main__.TestRunner)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "simple/test/test_issuer.py", line 87, in run_all
    m.submodules.issuer = issuer = TestIssuer(pspec)
  File "/home/lkcl/src/libresoc/soc/src/soc/simple/issuer.py", line
39, in __init__
    self.core = core = NonProductionCore(pspec)
  File "/home/lkcl/src/libresoc/soc/src/soc/simple/core.py", line 67,
in __init__
    self.fus = AllFunctionUnits(pspec, pilist=[pi])
  File "/home/lkcl/src/libresoc/soc/src/soc/fu/compunits/compunits.py",
line 221, in __init__
    self.fus["%s%d" % (name, i)] = kls(i)
  File "/home/lkcl/src/libresoc/soc/src/soc/fu/compunits/compunits.py",
line 153, in __init__
    super().__init__(DivPipeSpec, DivBasePipe, idx)
  File "/home/lkcl/src/libresoc/soc/src/soc/fu/compunits/compunits.py",
line 108, in __init__
    pspec = speckls(id_wid=2)                # spec (NNNPipeSpec instance)
TypeError: __init__() missing 1 required positional argument: 'div_pipe_kind'


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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [libre-riscv-dev] lots of stuff broken
  2020-07-18 22:18 [libre-riscv-dev] lots of stuff broken Luke Kenneth Casson Leighton
@ 2020-07-19  6:55 ` Jacob Lifshay
  2020-07-19 10:46   ` Luke Kenneth Casson Leighton
  0 siblings, 1 reply; 12+ messages in thread
From: Jacob Lifshay @ 2020-07-19  6:55 UTC (permalink / raw)
  To: Libre-RISCV General Development

On Sat, Jul 18, 2020, 15:19 Luke Kenneth Casson Leighton <lkcl@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.

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.

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [libre-riscv-dev] lots of stuff broken
  2020-07-19  6:55 ` Jacob Lifshay
@ 2020-07-19 10:46   ` Luke Kenneth Casson Leighton
  2020-07-19 21:11     ` Luke Kenneth Casson Leighton
  0 siblings, 1 reply; 12+ messages in thread
From: Luke Kenneth Casson Leighton @ 2020-07-19 10:46 UTC (permalink / raw)
  To: Libre-RISCV General Development

On Sun, Jul 19, 2020 at 7:55 AM Jacob Lifshay <programmerjake@gmail.com> wrote:
>
> On Sat, Jul 18, 2020, 15:19 Luke Kenneth Casson Leighton <lkcl@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.

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [libre-riscv-dev] lots of stuff broken
  2020-07-19 10:46   ` Luke Kenneth Casson Leighton
@ 2020-07-19 21:11     ` Luke Kenneth Casson Leighton
  2020-07-19 21:27       ` [libre-riscv-dev] div pipe Jacob Lifshay
  0 siblings, 1 reply; 12+ messages in thread
From: Luke Kenneth Casson Leighton @ 2020-07-19 21:11 UTC (permalink / raw)
  To: Libre-RISCV General Development

btw jacob i'm aware i did exactly the same thing to the ieee754 div pipe! i
did try running the div core unit tests, they weren't working.  i didn't
understand how to fix them so i proceeded anyway.  should have kept you
informed, apologies.

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [libre-riscv-dev] div pipe
  2020-07-19 21:11     ` Luke Kenneth Casson Leighton
@ 2020-07-19 21:27       ` Jacob Lifshay
  2020-07-19 22:07         ` Luke Kenneth Casson Leighton
  0 siblings, 1 reply; 12+ messages in thread
From: Jacob Lifshay @ 2020-07-19 21:27 UTC (permalink / raw)
  To: Libre-RISCV General Development

On Sun, Jul 19, 2020, 14:12 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> btw jacob i'm aware i did exactly the same thing to the ieee754 div pipe! i
> did try running the div core unit tests, they weren't working.  i didn't
> understand how to fix them so i proceeded anyway.


DivPipeCore broke because you forgot (or didn't know) to account for the
changing number of fractional bits when you changed the bit width for
supported={UDivRem}

I was working on fixing that but gave up since I'm planning on using the
FSM instead for the oct tapeout, and I'm planning on rewriting the div
pipeline to add dynamic partitioning and loop-back for the 28nm tapeout, so
the current div pipe core won't be needed. What we could do is just revert
the bitwidth changes if we want to have working code anyway.

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [libre-riscv-dev] div pipe
  2020-07-19 21:27       ` [libre-riscv-dev] div pipe Jacob Lifshay
@ 2020-07-19 22:07         ` Luke Kenneth Casson Leighton
  2020-07-20  0:32           ` Jacob Lifshay
  0 siblings, 1 reply; 12+ messages in thread
From: Luke Kenneth Casson Leighton @ 2020-07-19 22:07 UTC (permalink / raw)
  To: Libre-RISCV General Development

On Sunday, July 19, 2020, Jacob Lifshay <programmerjake@gmail.com> wrote:

> On Sun, Jul 19, 2020, 14:12 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
> wrote:
>
> > btw jacob i'm aware i did exactly the same thing to the ieee754 div
> pipe! i
> > did try running the div core unit tests, they weren't working.  i didn't
> > understand how to fix them so i proceeded anyway.
>
>
> DivPipeCore broke because you forgot (or didn't know) to account for the
> changing number of fractional bits when you changed the bit width for
> supported={UDivRem}


i was kinda aware of it but didn't know what to do.


>
> I was working on fixing that but gave up since I'm planning on using the
> FSM instead for the oct tapeout, and I'm planning on rewriting the div
> pipeline to add dynamic partitioning and loop-back for the 28nm tapeout, so
> the current div pipe core won't be needed.


about dynamic patitioning: i'd like to talk to whitequark about doing a
context manager that stores the partition mask...

*and provides m.If, m.Else and all other functionality* with literally zero
code changes.

the plan is that the mask-partition-manager would be initialised as:

     with pm.Mask(m, self.i.mask):

code then runs as:

             with m.If(some_partitioned_signal):

the Mask context *CHANGES* the behaviour of m.If, Else, Switch, Case and so
on.

underneath, the new context does all the work "on your behalf".

the actual number of changes should be *absolutely minimal*.  a single
indent to add the "with pm.Mask", the addition of the mask parameter to all
ispec and ospec (which should best come from ctx.op) and a few changes to
the constructor of each Stage.

we _might_ have to declare some parameters as explicitly PartitionedSignal,
plus some things which are single bit "test" (with m.If(foo)) these have to
be multi-bit, of width equal to the mask width.

aside from those changes there should be literally no changes to the actual
"logic" - the actual algorithm - at all

obviously, however, the fact that the data width can drop to 8 bit wide
means that running say 12 pipeline stages, the result will be produced far
earlier.

also any "constants" - assumptions that things will have the top bit set
for example - these need looking into.  i would *like* the Mask context to
even extend down into the behaviour of ArrayProxy so that even slices
(accessing psig[-1] for example) actually returns a special MaskArrayProxy
instead.

this would be fantastic, to be able to dynamically have the code reference
*different* parts of signals depending on how the Mask is set up.

however it would be seriously complex code.

the absolute last thing we need however jacob is a bunch of case statements
testing for different partition widths, all doing exactly the same thing.

one line of current code becomes ten, each almost identical excep different
widths.

that approach would be absolutely disastrous as the code repetition would
result in around a fivefold increase in code, and i can guarantee there
would be cut/paste errors.

in addition the explicit expansion of the code with such mask-based switch
statements would make it unmaintainable.


What we could do is just revert
> the bitwidth changes if we want to have working code anyway.


well, what i did was, if the configuration (initialisation) requests sqrt
or rsqrt the bitwidth is set to the 3x

no reversion should be needed.

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [libre-riscv-dev] div pipe
  2020-07-19 22:07         ` Luke Kenneth Casson Leighton
@ 2020-07-20  0:32           ` Jacob Lifshay
  2020-07-20  1:38             ` Luke Kenneth Casson Leighton
  0 siblings, 1 reply; 12+ messages in thread
From: Jacob Lifshay @ 2020-07-20  0:32 UTC (permalink / raw)
  To: Libre-RISCV General Development

On Sun, Jul 19, 2020, 15:07 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> On Sunday, July 19, 2020, Jacob Lifshay <programmerjake@gmail.com> wrote:
>
> > What we could do is just revert
> > the bitwidth changes if we want to have working code anyway.
>
>
> well, what i did was, if the configuration (initialisation) requests sqrt
> or rsqrt the bitwidth is set to the 3x
>

yeah, that part's correct as far as I can tell.
the part that's broken is where the width is set to 2x for div-only, since
effectively what's happening is the code is treating the compare_?hs
signals as if the binary value N means the fraction N/2^(3*fract_width)
(essentially fixed-point numbers), so changing the bit width of N without
adjusting the fract_width means there are too few integer bits and too many
fractional bits. additionally, some of the shifts and bit sliced will have
to be adjusted to get the right bits.

>
> no reversion should be needed.
>

except that, last I checked DivPipeCore doesn't correctly do divisions when
configured to only support UDivRem, since that's when it enables the broken
code adjustments.

see the test_bit_width_8_fract_width_4_radix_4[_comb]_div_only test
functions in TestDivPipeCore -- the code only breaks when div-only is
enabled: compare to test_bit_width_8_fract_width_4_radix_4[_comb]

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [libre-riscv-dev] div pipe
  2020-07-20  0:32           ` Jacob Lifshay
@ 2020-07-20  1:38             ` Luke Kenneth Casson Leighton
  2020-07-20  2:06               ` Jacob Lifshay
  0 siblings, 1 reply; 12+ messages in thread
From: Luke Kenneth Casson Leighton @ 2020-07-20  1:38 UTC (permalink / raw)
  To: Libre-RISCV General Development

On Monday, July 20, 2020, Jacob Lifshay <programmerjake@gmail.com> wrote:

>
> effectively what's happening is the code is treating the compare_?hs
> signals as if the binary value N means the fraction N/2^(3*fract_width)
> (essentially fixed-point numbers), so changing the bit width of N without
> adjusting the fract_width means there are too few integer bits and too many
> fractional bits.


ahh i remember.  that took a while to get right when connecting to fpdiv.


> additionally, some of the shifts and bit sliced will have
> to be adjusted to get the right bits.
>
> >
> > no reversion should be needed.
> >
>
> except that, last I checked DivPipeCore doesn't correctly do divisions when
> configured to only support UDivRem, since that's when it enables the broken
> code adjustments.


yuk.  hmm a way to "cheat" there: tell it that it can handle sqrt as well,
temporarily :)

that at least provides a functional codepath.  inefficient but functional.

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [libre-riscv-dev] div pipe
  2020-07-20  1:38             ` Luke Kenneth Casson Leighton
@ 2020-07-20  2:06               ` Jacob Lifshay
  2020-07-20  2:13                 ` Luke Kenneth Casson Leighton
  0 siblings, 1 reply; 12+ messages in thread
From: Jacob Lifshay @ 2020-07-20  2:06 UTC (permalink / raw)
  To: Libre-RISCV General Development

On Sun, Jul 19, 2020, 18:39 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> On Monday, July 20, 2020, Jacob Lifshay <programmerjake@gmail.com> wrote:
>
> >
> > effectively what's happening is the code is treating the compare_?hs
> > signals as if the binary value N means the fraction N/2^(3*fract_width)
> > (essentially fixed-point numbers), so changing the bit width of N without
> > adjusting the fract_width means there are too few integer bits and too
> many
> > fractional bits.
>
>
> ahh i remember.  that took a while to get right when connecting to fpdiv.
>
>
> > additionally, some of the shifts and bit sliced will have
> > to be adjusted to get the right bits.
> >
> > >
> > > no reversion should be needed.
> > >
> >
> > except that, last I checked DivPipeCore doesn't correctly do divisions
> when
> > configured to only support UDivRem, since that's when it enables the
> broken
> > code adjustments.
>
>
> yuk.  hmm a way to "cheat" there: tell it that it can handle sqrt as well,
> temporarily :)
>

I think a better way would be to find all the code like:

if core_config.supported == {DP.UDivRem}:
    self.compare_len = bw * 2
else:
    self.compare_len = bw * 3

and replace every occurrence with:

# TODO(programmerjake): re-enable once bit_width reduction is fixed
if False and core_config.supported == {DP.UDivRem}:
    self.compare_len = bw * 2
else:
    self.compare_len = bw * 3

As far as I can tell, that should work.

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [libre-riscv-dev] div pipe
  2020-07-20  2:06               ` Jacob Lifshay
@ 2020-07-20  2:13                 ` Luke Kenneth Casson Leighton
  2020-07-20  3:21                   ` Jacob Lifshay
  0 siblings, 1 reply; 12+ messages in thread
From: Luke Kenneth Casson Leighton @ 2020-07-20  2:13 UTC (permalink / raw)
  To: Libre-RISCV General Development

On Monday, July 20, 2020, Jacob Lifshay <programmerjake@gmail.com> wrote:

> l
> and replace every occurrence with:
>
> # TODO(programmerjake): re-enable once bit_width reduction is fixed


yeh that makes sense.


> if False and core_config.supported == {DP.UDivRem}:
>     self.



> As far as I can tell, that should work


yeh should do.

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [libre-riscv-dev] div pipe
  2020-07-20  2:13                 ` Luke Kenneth Casson Leighton
@ 2020-07-20  3:21                   ` Jacob Lifshay
  2020-07-20 10:31                     ` Luke Kenneth Casson Leighton
  0 siblings, 1 reply; 12+ messages in thread
From: Jacob Lifshay @ 2020-07-20  3:21 UTC (permalink / raw)
  To: Libre-RISCV General Development

On Sun, Jul 19, 2020 at 7:14 PM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> On Monday, July 20, 2020, Jacob Lifshay <programmerjake@gmail.com> wrote:
>
> > l
> > and replace every occurrence with:
> >
> > # TODO(programmerjake): re-enable once bit_width reduction is fixed
>
>
> yeh that makes sense.
>
>
> > if False and core_config.supported == {DP.UDivRem}:
> >     self.
>
>
>
> > As far as I can tell, that should work

Pushed a fix.

Fixed the comb tests since the generate process was 1us ahead of the
check process, causing test failures.

Jacob

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [libre-riscv-dev] div pipe
  2020-07-20  3:21                   ` Jacob Lifshay
@ 2020-07-20 10:31                     ` Luke Kenneth Casson Leighton
  0 siblings, 0 replies; 12+ messages in thread
From: Luke Kenneth Casson Leighton @ 2020-07-20 10:31 UTC (permalink / raw)
  To: Libre-RISCV General Development

On Monday, July 20, 2020, Jacob Lifshay <programmerjake@gmail.com> wrote:

>
> > > if False and core_config.supported == {DP.UDivRem}:
> > >     self.
> >
> >
> >
> > > As far as I can tell, that should work
>
> Pushed a fix.


nice


>
> Fixed the comb tests since the generate process was 1us ahead of the
> check process, causing test failures.


whoops :)



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

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, back to index

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-18 22:18 [libre-riscv-dev] lots of stuff broken Luke Kenneth Casson Leighton
2020-07-19  6:55 ` Jacob Lifshay
2020-07-19 10:46   ` Luke Kenneth Casson Leighton
2020-07-19 21:11     ` Luke Kenneth Casson Leighton
2020-07-19 21:27       ` [libre-riscv-dev] div pipe Jacob Lifshay
2020-07-19 22:07         ` Luke Kenneth Casson Leighton
2020-07-20  0:32           ` Jacob Lifshay
2020-07-20  1:38             ` Luke Kenneth Casson Leighton
2020-07-20  2:06               ` Jacob Lifshay
2020-07-20  2:13                 ` Luke Kenneth Casson Leighton
2020-07-20  3:21                   ` Jacob Lifshay
2020-07-20 10:31                     ` Luke Kenneth Casson Leighton

Libre RISC-V Mailing list Archives (accessible via public-inbox)

Archives are clonable: git clone --mirror https://inbox.libre-soc.org/libre-riscv-dev

Example config snippet for mirrors


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git