[Libre-soc-bugs] [Bug 324] create POWER DIV pipeline

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=324

--- Comment #33 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #32)

> If I were to pick a replacement name for POWER9 when you meant the Power
> ISA, I'd probably just pick Power,

unfortunately, Power is a general english word.

> since are docs clearly state (or should
> state) that we're compatible with Power ISA v3.0B (or v3.1B). We can assume
> someone reading our code knows that since that's what we advertise (or at
> least knows that they should figure out which version we implement).

heck, *i* can't :)  or i do but not how to refer to it.  "Power" is far too
general.  i have conversations with ordinary people, i have to refer them to
PowerPC and mention "G4 Mac" and their eyes un-glaze at that point :)


> > > trunc_div is intended to be the equivalent of python's // operator, except
> > > that it rounds differently -- the same way Rust, C, C++, Java, x86, and
> > > Power do.
> > > 
> > > Similarly with trunc_rem.
> > 
> > ok right: then it's... (POWER 3.0B?) compatible, would that be ok to call it?
> 
> I was thinking we'd put it in nmutil, since it's useful for way more than
> the instruction simulator.

done.  nmutil.divmod.py - feel free to move it you think of a better name,
remember to update helpers.py though

> As an example, I wrote a very similar function as
> part of ieee754.div_rem_sqrt_rsqrt.algorithm.

ahhhh okaaay

> if you want something strictly compatible with IBM's POWER9 cpu, then
> translate (or create python bindings to) the code in:
> https://salsa.debian.org/Kazan-team/power-instruction-analyzer/-/blob/master/
> src/instr_models.rs

right.  ok.  so that is tending to suggest that... in decode/helpers.py,
we *do* need a function called power_trunc_div which does the detection
of overflow.

which is slightly different from the other cases (other arithmetic cases)
in that you can't really post-analyse the *result*.

ok i'll take care of that if you can concentrate on the hardware side.
i may need help with the unit tests in test_div_sim.py
(if you know what do to, there, do just throw some in and i will chew
through them making sure that the simulator code is "correct" against them)

somewhere in the middle of the hardware pipeline you'll need to generate
that overflow condition and pass it through.  whether that's a special
flag or whether you actually use the xer_ov/32 data structure is up to you,
but it has to come _out_ as xer_ov/32 and xer_ca/32 when it goes into
ALUOutputStage.

        self.dive_abs_overflow_32 = Signal(reset_less=True)
        self.dive_abs_overflow_64 = Signal(reset_less=True)

ahhh excellent, you're on the ball :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.