title: FPGA indexing of nonuniform spaced look up table
body: <p>We are trying to implement a fixed point nonlinear mathematical function on a FPGA. We want to be able to achieve very low latency (2-4 clock cycles max), have the computation pipelined in such a way that we can receive a new answer every clock cycle (no dropped inputs since they come in every clock cycle), have decent accuracy, AND have reasonable FPGA resource utilization. </p>
  
  <p>We performed the computation using a combination of CORDIC computers and DSP blocks for a pretty good solution, except the CORDIC computers required about 12 clock cycles for good accuracy.</p>
  
  <p>Using a LUT without interpolation would require way too many RAMs as we have 32 bits, so we threw that out. </p>
  
  <p>Our next option was using a look up table with interpolation. The latency was good because we could automatically index the LUT using the upper bits of the input value. The problem with this was that the accuracy wasn't very good in the non-linear sections.</p>
  
  <p>We are now trying to use a LUT with non-uniform spacing between the samples. Basically we sample the function more in the non-linear portions, and sample less when the function looks more linear. This should help out our accuracy problem a lot, but we now face the problem where we can't automatically index the LUT with the upper bits of the input value. We investigated ways of doing a binary search to find the index, but the latency suffered. Resource utilization wasn't great either, because in order to keep getting an answer on the output every clock cycle, we had to replicate our LUTs in different pipelined stages just to handle the binary searching. We tried a few tricks like using dual-port rams, but the latency is still killer. </p>
  
  <p>So we are wondering if anyone has had a similar problem and knows of a good indexing solution, or if there are special/smart ways to sample our function non-uniformly and build the LUT in such a way that indexing can still be computed fairly quickly.</p>