**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!

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
- :
- Forums
- :
- Intellectual Property
- :
- DSP IP and Tools
- :
- CORDIC 5.0 vector translation phase out incorrect...

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

Highlighted

ronnu

Observer

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

02-07-2019 11:46 AM

112 Views

Registered:
10-14-2017

Hi,

I've created a design where I've got samples from FFT core (8.0) coming into CORDIC 5.0 core which is configured for vector translation. In other words, I've got FFT complex number results which I want to convert into magnitude and phase. I've generated the bit files and done the simulation. In both cases magnitude calculation by CORDIC seems to be correct. However, the phase results are not. I should have a phase value of PI on one of the bins (42) and zeros on all the rest. But what I got is weird offset of approx. one on all the bins except the one which should have value of PI and some weird stuff right before that.

I've sampled the values going into CORDIC core doing the vector translation and verifyed that they are correct with matlab. Below are Matlab plots. The upper ones are of FFT output (input into vector translation CORDIC core) data converted into magnitude and phase vectors using Matlab built in functions. The bottom ones are plots of output data from the CORDIC core. It can be seen that magnitude is corretc, but phase vector has somethign weird going on.

To make sure that it's not some error with binary to decimal conversion in Matlab, I also inspected ISim trace. Below is a picture of that which shows that when input into CORDIC core is zero (both real and imaginary) it outputs magnitude value (CORDIC_OUTPUT 7 downto 0) of zero, but a phase value (CORDIC_OUTPUT 15 downto 8) of non-zero, although atan of zero should be zero.

Can somebody please explain to me what might be the issue and how to solve this?

1 Solution

Accepted Solutions

ronnu

Observer

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

02-07-2019 12:51 PM

95 Views

Registered:
10-14-2017

Okay, I think I found the answer to my question. I just now read from the datasheet that "The phase angle of a zero length vector, (0,0), is indeterminate and the output phase angle generated by the core is unpredictable."

I guess that is the reason why I'm seeing this weird stuff with phase out.

2 Replies

ronnu

Observer

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

02-07-2019 12:51 PM

96 Views

Registered:
10-14-2017

Okay, I think I found the answer to my question. I just now read from the datasheet that "The phase angle of a zero length vector, (0,0), is indeterminate and the output phase angle generated by the core is unpredictable."

I guess that is the reason why I'm seeing this weird stuff with phase out.

dgisselq

Explorer

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

02-07-2019 06:32 PM

70 Views

Registered:
05-21-2015

Re: CORDIC 5.0 vector translation phase out incorrect (has an offset)

One of the ugly realities of an FFT is that each individual bin tends to have a separate phase shift. For example, for 50% overlap, the phase shift alternates by 180 degrees from one frame to the next on every other bin. On one frame there will be no phase shift, on the next frame only the even numbered bins will have no phase shift, while the odd bins will all be shifted by 180 degrees. On the next frame the cycle repeats. If you overlap more, the phase shift will adjust as well. With no overlap, though, the phase from one FFT to the next should be reliable and usable.

In other words, if you have a CORDIC input to the FFT, with neither windowing nor overlap, you should get the same phase in that bin from one FFT to the next. If you want to relate the output phase to the phase of the CORDIC, though, you'll have to trace through the processing stages of the CORDIC. If that's of interest to you, you might find this CORDIC implementation valuable for your purpose.

If you want to know more about the FFT bin-dependent phase rotations, see the references on this page. Pay particular attention the Allen reference--if you are interested in reading further at all.