[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