Can anyone suggest any websites, books, or papers on how a log is actaully
calcuated? So far, I haven't had much luck with google, and after looking
at the list archives for the FPU, it seems like it was decided that doing
logs and trigs in hardware wasn't worth the time and effort (I could be
wrong, I only took a quick glance through the source).

Thanks,
Mike

Hi Mike, I found the following algorithm: ln(x) ~ 6*(x-1)/ ( x + 1 + 4*(x^0.5)) on this page which discusses logarithms. There's a reference in there to one of the Knuth books, but I don't have that here to refer to. http://www.dattalo.com/technical/theory/logs.html I think that algorithm may be sensitive to number of digits, since on my machine it gave results that corresponded with the results of the built-in log function, but were not the same (first 2-3 digits the same). YMMV. - Guy

Hi Mike, Log can be calculated using the CORDIC algorithm. Ray Andraka has a paper: A survey of CORDIC algorithms for FPGAs http://www.andraka.com/cordic.htm You could also possibly consider using a ROM lookup table. The ROM doesn't necessarily have to be on-chip. Best regards, Tony Burch B U R C H E D Simple FPGA Boards, The Most Free I/O, Easy Prototyping http://www.burched.biz ----- Original Message ----- From: "Michael M Delaney" mmdst23+ at pitt.edu> To: "Discussion list about free open source IP cores" cores at opencores.org> Sent: Tuesday, 21 September 2004 6:41 Subject: [oc] Logs in hardware?

If you want to do it fast you might check out a CORDIC , it's a coordinate rotator algorithm, and I am quite certain that it might do log's as well, ( doen very close to everything :-) ). There is one on opencores, with some references. Otherwise there always newtons algorithm, ( which can be speed up a bit for a specific function as long as it's monotone), I think it's still the fastest as for square roots, don't know about logs, but I think a codic might be better in hardware. / Lars Segerlund. On Mon, 20 Sep 2004 16:41:41 -0400 (EDT) Michael M Delaney mmdst23+ at pitt.edu> wrote:

Hi, I did a log2 implementation a couple of years ago. This implementation is rather rough and not very accurate, on the other hand it is small and efficient. ;-) Lets look on a number with 8 bits: ex=0110_0000 (=96) we number the bits from 7 downto 0 (left to right) Lets assume we want the answer to be unsigned binary number with decimal point on the form nnn.nnnnnnn Start looking on the bits from left. Find the first bit='1' In this case ex(7)='0' but ex(6)='1'. This means that the integer part of the answer is 2^6. answer = 110.1000000 (=6+64/128=6.5) If you need log10 instead of log2 multiply with log10(2) log10(96)=6.5*log10(2)=1.957 Maybe not that accurate but efficient ... regards /Michael ----- Original Message ----- From: Michael M Delaneymmdst23+ at pitt.edu> To: Date: Mon Sep 20 22:41:41 CEST 2004 Subject: [oc] Logs in hardware?

I'd like to thank everyone who'se offered a suggestion so far. I think I
forgot to mention a couple of things initially, or I may not have looked
at everthing involved, but the unit I actually need to do is a log adder,
which involves both a log and raising a constant number to -d, where d is
some 32 bit floating point number. Also, this whole mess has to be 32 bit
floating point (they arn't actaully sure if even 32 bits is enough
precision). Also, we need to do at least 4200 log-adds in a 10 ms frame.

The good news is that my professor said after I got this done, he'd have
no problem with my putting the log adder on open cores. I don't know how
useful it'l be to anyone else, but it'l at least be an example of the hard
(but more precise) way of logs. (We've been told that for this semester
we can trade off as much space for speed as we need, as long as we can
synthesize it for some FPGA, most likley the biggest one the tools support :)

Mike

On Tue, 21 Sep 2004, Lars Segerlund wrote: