[libre-riscv-dev] [Bug 208] implement CORDIC in a general way sufficient to do transcendentals

[bugzilla-daemon at libre-soc.org]

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

--- Comment #19 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #18)
> (In reply to Michael Nolan from comment #17)
> > I'm working on converting the floating point input to the fixed point value
> > needed by the cordic. I've got my module decoding the float into sign,
> > exponent, and mantissa with FPNumDecode, and the mantissa is missing the
> > (implied) leading 1 bit. I'm also looking at the modules of fpdiv (div0.py
> > and nmigen_div_experiment.py), and they don't seem to add that bit back in.
> > Is there a way to have FPNumDecode generate a mantissa with the leading 1
> > bit?
> 
> I think that's done in ieee754.fpcommon.denorm:
> https://git.libre-soc.org/?p=ieee754fpu.git;a=blob;f=src/ieee754/fpcommon/
> denorm.py;h=350f413ede9858ae490059f6709b3454ea8a7f1e;hb=HEAD

like 41, yes.

ok.

i only sort-of "understood" IEEE754 FP retrospectively, through long exposure,
having started initially from jon dawson's "working" verilog code and making
absolutely damn sure, throughout the entire six months of morphing it, that
it passed the unit tests *at all times*.  this made for a bit of a mess at
times.

i therefore substituted "unit tests pass 100%" for "understanding what the
hell is really going on".

line 41.

https://git.libre-soc.org/?p=ieee754fpu.git;a=blob;f=src/ieee754/fpcommon/denorm.py;h=350f413ede9858ae490059f6709b3454ea8a7f1e;hb=HEAD#l41

here you can see that the top bit of a (and later b) are, yes, set to 1
if and only if the exponent is not equal to -126 [for FP32]

back-track a little: the data structure FPSCData has had one *extra* bit
already allocated at the top (m[-1]) which is *specifically* allocated
for the purpose of allowing that extra implicit mantissa "1" to be
inserted *if it is needed*.

the reason why it is sometimes not needed is this:

when the exponent is "-126" (on FP32), this is "ridiculously small number"
but it is not the limit of the range of IEEE754.

what they allowed was: when exp=-126, you can express smaller and smaller
numbers by simply having less bits in the *mantissa*.  obviously, those
numbers become less and less accurate however this is an acceptable tradeoff.

however when you do that, you have to go from "implicit 1 in the top digit"
to "explicit 1 in the mantissa itself".

thus, we have that Mux detecting the transition condition between these
"implicit 1" and "really small numbers with explicit 1 *ALREADY* in
the mantissa".

the whole process is called "de-normalisation".

so basically, you can just "trust" that after the number has gone through
FPAddDeNorm, it *will* have the mantissa and exponent correctly set, such
that you can treat that "expanded mantissa" as just "A Fixed Integer".

btw i don't recommend trying multiplying or dividing either the input
or the output by pi inside the FP CORDIC code. we can use micro-coding for
that (and in the unit tests do the divide and/or multiply using import math
or import bigfloat).

so let us assume that we're implementing cospi and sinpi, here, *NOT*
actual cos or actual sin, ok?

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