On Tue, 08 Feb 2005 17:07:35 +0100, Alexander van Heukelum <[EMAIL PROTECTED]> wrote: > On Tue, 8 Feb 2005 09:28:50 -0500 > Timothy Miller <[EMAIL PROTECTED]> wrote: > >We need a table and an algorithm that produces good results. Even > >with a fixed implementation, the table will be accessible in case > >someone comes up with better numbers. > > Hi everyone, > > Just as a remark: would it not be better to tabulate bits of x+0.5/x > instead of 0.5/x itself. The range of 0.5/x in [0.5, 1) is (0.5, 1], while > x+0.5/x is in [sqrt(2)=1.414..., 1.5]. Also, the derivative of 0.5/x lies > between -2 and -0.5 in the given x-range, while the derivative of > x+0.5/x lies between -1 and +0.5. I think it should therefore be > possible to compute a few of the highest bits in random logic, and > tabulate differences in a block-ram, with only one bit of overlap. > The additional cost is of course that you have to subtract x from > the result of the interpolation... > > Is there anything against using a block-ram in 36x512 mode > as 12x1536? If the reciprocal is implemented with the first few > bits computed in random logic, then 18 bits is overkill, but 9 bits > is not enough. > > Just some ideas that popped up. Where's the catch? ;)
If we use a block RAM in 18-bit mode, that's better because we don't disable the associated multiplier. It wouldn't be a big deal to treat the RAM as a single-ported unit, 36x512 (which is using both 18-bit ports together) and just treat the output as 3 12-bit numbers. The problem then comes down to being able to look up two at a time. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
