[libre-riscv-dev] daily kan-ban update 09jul2020

[Jacob Lifshay]

On Fri, Jul 10, 2020, 02:06 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Fri, Jul 10, 2020 at 8:45 AM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
> >
> > On Thu, Jul 9, 2020 at 7:10 PM Luke Kenneth Casson Leighton
> > <lkcl at lkcl.net> wrote:
> > >
> > > On Friday, July 10, 2020, Jacob Lifshay <programmerjake at gmail.com>
> wrote:
> > >
> > > > today:
> > > > attended the OpenPower virtual coffee meeting
> > > > Luke found a bug in the div pipeline, I was able to reproduce it, but
> > > > the VCD file nmigen produced was utterly useless -- nearly everything
> > > > is set to 0. Luke (or someone else), I need help here.
> > >
> > >
> > >  i got that too, gtkwave is known to not always display everything
> > > correctly.
> >
> > I checked with a completely independent vcd reader and gtkwave is not
> > at fault this time. nmigen really did write a messed up file.
>
> ok then that's best raised as a bugreport.


> btw before doing that i suggest examining the yosys graphviz (show
> {modulename}).  i just noted for example that ra$1 (etc) are not
> connected yet are passed into pipe_N_to_N, then passed in to
> core_calculate_stage_N, then *still* not used.
>

I checked quite a few signals that I know are critical for calculating the
correct result, such as the ra and rb signals in the *setup* stage, and the
dividend, divisor_radicand, and operation of DivPipeCore.

>
> this because of the inheritance tree DivCoreCalculateStage -> Base,
> CoreBaseData inheriting from DIVInputData, DIVInputData contains ra,
> rb, xer_so.
>
> so whilst it's correct that xer_so should be propagated right the way
> through the pipeline (for sticky-overflow processing *right* at the
> end - sigh) - ra and rb are not necessary and are thrown away.
>

true, but they're thrown away after where I checked. I looked through the
whole list of signals and I think all signals named ra and rb including
variants like ra$3 were 0 everywhere.

>
> > The vcd reader I used is: https://github.com/sgpthomas/vcdump/pull/1
> >
> > > honestly if we spend much more time on this it's time instead to
> convert
> > > microwatt DIV FSM to nmigen.
> >
> > Yeah, though with the way that nmigen and/or the pipeline is messed
> > up, we're highly likely to run into this problem on any new code too.
>
> there's nothing wrong with the simulation / pipeline: it's the
> calculation of overflow.  it's real simple to check: delete these
> lines
>

yeah, i got that. I was trying to get a working vcd trace so I could follow
the overflow computation, which is split between the setup stage and the
output stage.

If you have time, you could try to build a more minimal reproducer for
whitequark, since what we have is waay too complicated to be that useful
for finding the bug in nmigen. if it helps any, I'll put the git revs I am
on:
nmigen : 30e2f91176edcd1c8766c2cb11f413b9c77936b9
ieee754fpu : 610b4a381e70f45f5684cc281398ce77fb5441fa
nmutil : 3853df675a1e1db24950945f66b076266a7da409
soc : caceb716e9417ed8731ef08b7b260a4c077186b2

meanwhile, I'll be sleeping for a while.

Jacob