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

[bugzilla-daemon@libre-soc.org]

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

--- Comment #41 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Michael Nolan from comment #38)
> (In reply to Luke Kenneth Casson Leighton from comment #36)
> > 
> > (just running the tests, you forgot to commit cordic/renormalize.py.
> >  for future reference, use "git status" and you should spot missing
> >  files, fairly easily.  that's if we're properly maintaining ".gitignore")
> 
> Oops, fixed!

been there :)

> > if however we do macro-op fusion, spotting two (commonly-used)
> > operations together, the two results *will* be needed.
> 
> Ah ok, so maybe I should add an input that selects one or the other?

yes.  an "Op".  this is what the "Op" field is for... see... ahh.. 1sec...
DivPipeCoreConfig and DivPipeCoreOperation (etc.)

https://git.libre-soc.org/?p=ieee754fpu.git;a=blob;f=src/ieee754/div_rem_sqrt_rsqrt/core.py;h=fea59dce0c4f73d652985faa8181d5af97d5877c;hb=dd3919a0df8e1190f2fe985b0448701f164b392a#l54

which is set up as the "context" (ctx) here:
https://git.libre-soc.org/?p=ieee754fpu.git;a=blob;f=src/ieee754/div_rem_sqrt_rsqrt/div_pipe.py;h=d7b81729499b5d763eb1d150b031dceeefecbda9;hb=dd3919a0df8e1190f2fe985b0448701f164b392a#l42

and it is of type "FPPipeContext", declared here:
https://git.libre-soc.org/?p=ieee754fpu.git;a=blob;f=src/ieee754/fpcommon/getop.py;h=117d29223d23ab8176382e76b2dd129382735721;hb=dd3919a0df8e1190f2fe985b0448701f164b392a#l65

and if you look at lines 63 and 65 you can see that you can EITHER:

* specify just a bitwidth (in which case you get a signal and it's
  your responsibility to manage conversion from the "op" into that Signal)

OR

* specify an *actual class* as a parameter to FPPipeContext, and an instance
  *of* that class will be instantiated on your behalf.

it's actually really important to conform to this API because it's where
the "cancellation", identifier information etc. critically necessary for
the use of the pipeline in the scoreboard system is all placed.



> (kinda
> sucks that we need to calculate both for the cordic to work, oh well)

:)

divide is the same.  it produces two results: DIV and REM.

fascinatingly CORDIC and DIV (and SQRT and RSQRT) all use the same
core concept / algorithm, so it is no surprise that there are two results.


> (In reply to Luke Kenneth Casson Leighton from comment #37)
> > ah excellent!  you did a FSM-based version as well, that's superb.
> > if the pipelined version turns out to be insanely gate-hungry, or
> > just not that important, we can use it.
> 
> Unfortunately, that one isn't as complete as the pipelined one. It doesn't
> handle denormals or 0 well because I had to roll my own denormalization
> stage instead of using the existing one from the multiplier. And it doesn't
> (yet) support conversion back into floating point at the end. 

ok not a problem.  it got you bootstrapped to where you needed to go.
let's leave it for now, but do document that (briefly).

> > 
> > also as a "general-purpose library" it's extremely useful to have
> > because other developers might not want a full pipeline version.
> 
> Makes sense.

can you do that move?  the unit test as well.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev