/technologies/fpga-group/b/blog/posts/the-art-of-fpga-design---post-29The DSP48 Primitive - Complex multipliers Traditionally a complex multiplication can be decomposed into four real multiplications and two additions: x+i·y=(a+i·b)(c+i·s)=(a·c−b·s)+i·(a·s+b·c) where i=√−1 ...en-USTelligent Community 12https://community.element14.com/technologies/fpga-group/b/blog/posts/the-art-of-fpga-design---post-29Tue, 23 Jul 2024 20:53:25 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:a87ca903-c270-44d7-acd4-7a1a819a127ahcommin0<p>The &quot;lifting&quot; technique sounds very interesting, but I can&#39;t imagine storing (1+s)/c in a LUT (directly) because that&#39;s going to explode towards +/- infinity around pi/2. There might be some clever trick to avoid needing to store the huge values, but it&#39;s not immediately obvious to me how to do it.</p> <p>I also wonder about the memory requirement. Assuming the full sine period is needed (like in a mixer, but not an FFT), sine and cosine can be easily generated from just 1/4 of a sine period (or, less elegantly, from 1/8 of a sine and 1/8 of a cosine) stored in a LUT. Do&nbsp;similar symmetries exist in the &quot;lifting&quot; method, which could be exploited to reduce the memory requirement?</p> <p>And, of course, I wonder about the numerical accuracy. How does the fixed-point error of &quot;lifting&quot; compare with an ordinary sine LUT (with the same word width)?</p> <p>My gut feeling is that there is a heavy price to pay in order to save a couple of adders. I really hope I&#39;m wrong because it&#39;s a fascinating idea.</p><img src="https://community.element14.com/aggbug?PostID=7226&AppID=19&AppType=Weblog&ContentType=0" width="1" height="1">