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

[Jacob Lifshay <programmerjake@gmail.com>]

On Fri, Jul 10, 2020, 05:33 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> On Fri, Jul 10, 2020 at 10:54 AM Jacob Lifshay <programmerjake@gmail.com>
> wrote:
>
> > 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.
>
> so let's track that with the yosys graphvis (show setup).  i can see
> ra going in to dividend_neg and abs_dividend (this is visually, not
> looking at the code), and i can see rb going in to divisor_neg and
> abs_dor (i shortened the name abs_divisor).
>
> however what i *don't* see is ra or rb going into *output* signals
> from the setup stage.
>

yes, I know and expected that. I'll repeat myself until you get that I was
looking at the ra and rb *inputs* in *this stage* as well as the previous
stage. those *inputs at the beginning of the pipeline* were zero.

at no point is either ra or rb in being copied into ra or rb *out*.
> there's no self.o.rb.eq(self.i.rb)
>
> basically what i'm pointing out is that there may not be a bug in nmigen
> at all.
>
> > 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.
>
> yes, because once the chain is broken (and it looks like it's broken
> in DivSetupStage) that's it, zeros will obviously get propagated from
> that point onwards in the pipeline.
>
> adding this, the signals are no longer zero, right the way throughout
> the entire pipe_N_to_N chain:
>

we don't actually want to do that because it's 128 extra wires.  those
> have to go.  there's currently something like.... 600 wires being
> passed between each stage right now.
>

completely agreed.

>
> > > 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.
>
> i've found it necessary to have *all* the files open on-screen (jobs |
> grep vi | wc --> 48 *in one terminal*), have the yosys graphviz open
> on a second virtual desktop (full screen, 3840x2160), the vcd trace
> open in 1/3 of the screen, *and* do print statements from the
> simulation.
>
> the combination - reinforcement of information from multiple sources -
> gives the picture in a way that a single tool flat-out cannot.
>
>
> > If you have time, you could try to build a more minimal reproducer for
> > whitequark,
>
> that would take longer than it would to turn the microwatt FSM into
> nmigen.



plus, given that the break in the pipeline has been
> identified i don't believe it necessary to raise the bugreport.
>

it *is* necessary to report (unless fixed meanwhile), since you got
distracted by the wrong thing and completely missed that the signals that
shouldn't have been zero since they *are* connected to the pipeline inputs
-- those signals *are* zero in the vcd file.

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