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

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Tue May 5 15:04:06 BST 2020


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

--- Comment #36 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Michael Nolan from comment #35)
> So I think I got the floating point cordic all the way working yesterday. It
> converts the floating point input to a fixed point 50 bit number, calculates
> the sine and cosine, then converts them back to floating point.

hurrah!

(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")


> However, for the conversion back to floating point I had to write my own
> class to do so, as none of the existing ones (used in fpadd for instance)
> support *two* outputs. 

yeah, keenly aware of that.

> I don't imagine we want to continue using my
> implementation, so what would be the best way of going about this?

hmmm hmmm well we will actually need double-output functions at some
point (and more): NORMALISE, DOTPRODUCT, they're all multi-output.

however for the plain "SIN" and "COS" operations - and others that
will use "General CORDIC" - we simply *drop* the output on the floor
if it's unused.

if however we do macro-op fusion, spotting two (commonly-used)
operations together, the two results *will* be needed.


> I also needed to write a module for counting the number of leading zeros in
> the fixed point number. 

ah goood.  actually i think... somewhere... very ineptly-named, there
is a class that does this.  probably "MultiShiftRMerge".

don't worry about it :)

> I don't imagine this would only be useful to the
> cordic; where would be the best place to put it? fpcommon?

on one hand i'd be inclined to suggest nmutil (because CLZ is pretty
useful, generally)

on the other, it's a basic "ALU" operation.

hmm hmm...  the decision would be based then on whether CLZ (count leading
zeros) has uses *outside* of an ALU, and my feeling is, it probably does.

actually, just looking at it, i really like it!  it reminds me of the
reference that Jacob put... what was it... "Common Task something"?

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


More information about the libre-riscv-dev mailing list