**UPGRADE YOUR BROWSER**

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

- Community Forums
- Xcell Daily Blog
- Vivado Expert Series Blog
- About Our Community
- Announcements
- Welcome & Join
- General Technical Discussion
- Programmable Devices
- UltraScale Architecture™
- 7 Series FPGAs
- Virtex® Family FPGAs
- Spartan® Family FPGAs
- Xilinx Boards and Kits
- Configuration
- Serial Transceivers
- Design Tools
- Installation and Licensing
- Synthesis
- Simulation and Verification
- Implementation
- Design Entry
- Timing Analysis
- Vivado TCL Community
- HLS
- Design Methodologies and Advanced Tools
- SDAccel
- Design Tools - Others
- Embedded Systems
- Embedded Processor System Design
- Embedded Development Tools
- AXI Infrastructure
- Embedded Boot and Configuration
- Embedded Linux
- SDSoC Environment and reVISION Stacks
- OpenAMP
- Intellectual Property
- PCI Express
- Networking and Connectivity
- MIG
- Video
- BRAM/FIFO

turn on suggestions

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Community Forums
- :
- Xilinx Products
- :
- Intellectual Property
- :
- Video
- :
- I don't understand the output from the Complex Mul...

Topic Options

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page

Highlighted
# I don't understand the output from the Complex Multiplier

Options

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

05-19-2017 06:11 AM

Hi,

I have the complex multiplier IP (v6.0 with Vivado 2014.2) set up to have Operand A at 16-bits and Operand B at 17-bits. I was having trouble rounding and truncating to get the desired output where I wanted so I ran the core without rounding at full precision, which is 33-bits. I then tested the multiplier with different operand values to see what it was doing but got unexpected results.

For example:

Op A (16-bits) : 0x 1234

Op B (17-bits): 0x 0_2233

The expected output was (33-bits) : 0x 0_026E_885C

But my multiplier output gave (33-bits): 0x 0_0137_442E

If you look at this it means the result is shifted down by 1-bit, which almost certainly is wrong no matter how you round or truncate. Fortunately I am only interested in the upper portion of the output so I can truncate to get the result I want, even if I don't understand why I need to truncate to the number of bits I have to. I was careful to pick an easy example that doesn't push the limits of either operand, or the output, and uses all positive number to avoid complications form having signed operands.

What is going on here?

Thanks

Accepted Solutions

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

05-21-2017 12:18 PM

OK. I think I see the reason for 34 bits. The imaginary part of the result would need 34 bits for the worst case of all inputs being maximum negative value. However the real part of the result would fit in 33 bits regardless of the inputs. I guess the core is built to have symmetry in the result size.

-- Gabor

All Replies

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

05-20-2017 09:27 PM

I looked at this in 2017.1 and got the same results with the same settings. Interestingly, the output width box in the "Customize IP" window shows valid range of 2 to 34 bits. I used the default of 33 bits, but perhaps you need to set it to 34 to avoid the scaling issue.

-- Gabor

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

05-21-2017 07:17 AM

OK. I tried with output width of 34 bits and got the correct result, 0x26e885c. Now that I think of it, it makes sense that the result could grow by 1 bit because of the imaginary contribution to the result. However I still haven't convinced myself that a signed result would need 34 bits. In any case you need to select 34 bits to avoid truncation.

-- Gabor

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

05-21-2017 12:18 PM

OK. I think I see the reason for 34 bits. The imaginary part of the result would need 34 bits for the worst case of all inputs being maximum negative value. However the real part of the result would fit in 33 bits regardless of the inputs. I guess the core is built to have symmetry in the result size.

-- Gabor

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

05-22-2017 01:24 AM

gszakacs wrote:

OK. I think I see the reason for 34 bits. The imaginary part of the result would need 34 bits for the worst case of all inputs being maximum negative value. However the real part of the result would fit in 33 bits regardless of the inputs. I guess the core is built to have symmetry in the result size.

Ah, brilliant! Well 2014.2 only gives a valid output range of 2-33 bits, it goes red if I try to input 34. But, I think you're right that the imaginary part could lead to another 1-bit growth. It's a complex multiplier so it should do 4 multiplies and then add the two pairs of products to gives the real and imaginary outputs. This add will cause the 1-bit growth. In my case one of my operand is real and the other imaginary so my test case did not account for this...

I guess this was an oversight in Vivado that was corrected later. Annoyingly I am due to upgrade to 2017.1 next week so I will have to wait util then to do it properly. Thanks for your input..