cancel
Showing results for
Show  only  | Search instead for
Did you mean:
Explorer
1,316 Views
Registered: ‎10-14-2017

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

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
Explorer
1,299 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.

8 Replies
Explorer
1,300 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.

Scholar
1,274 Views
Registered: ‎05-21-2015

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.

818 Views
Registered: ‎06-04-2019
Hello,
How did you handle this. ? My input vector have some zeros in them. Atan(0/0) is unpredictable, so the translate phase output is 0.3048095703125 which is not desirable.
Thanks,
Bhavanithya Thiraviaraja
Explorer
791 Views
Registered: ‎10-14-2017

Hi,

These values have to be filtered out before inputting into the CORDIC core as dividing zero by zero gives undefined results (in mathematics generally, not just in this situation). You can also think of it like a dot in the center of the Cartesian co-ordinate system - what direction is this dot pointing to? The answer is undefined as it can actually point to any direction. In other words, this kind of input does not carry any information.

Alternative way is to do nothing and just not use the output (this particular bin) as it's invalid. In this situation it basically becomes noise which maybe disturbing visually, but if not used for displaying, but for further processing, then why not.

Scholar
780 Views
Registered: ‎05-21-2015

These values have to be filtered out before inputting into the CORDIC core as dividing zero by zero gives undefined results (in mathematics generally, not just in this situation).

Not quite.  You can send 0,0 into a CORDIC just fine, since 1) a CORDIC will have a fixed number of processing stages, and 2) it never actually does a divide internally.  A rectangular to polar CORDIC is more like an atan2 in operation--it is safe, even if y is zero.  You should get a resulting magnitude of zero, which will allow you to filter the results out after the CORDIC.

It's actually a bit better than that: since this is digital logic, and not mathematics, the output of the CORDIC when given a 0,0 input will always be the same (unless/until you reconfigure the CORDIC).  So ... it's usable enough.

The real answer to @bhavanithya is probably: how to deal with the undefined angles really depends upon your application.  Tell use how you want to use them, and perhaps an answer can be more helpful.  For example, you could add a flag to the values to mark them as unknown, and then use a filter, applied to the rest of the data, to construct what they "should" be.  Alternately, you might find working in the non-FFT space easier for dealing with things like this.  (Part of my Ph.D. was comparing time delay estimators, and so ... I got to examine lots of phase estimation approaches both in the frequency domain and in the time domain--but that's a much longer story.)

Dan

778 Views
Registered: ‎06-04-2019
Hi Ronnu & Dan, thanks for your responses.

I am also dealing with phase estimation for a sequence. I want to monitor how the phase changes from one sample to the next.

And Dan you are right, as the number of iterations inside the CORDIC is the same, the estimated atan2(0,0) is also constant. So it is easy to find them. I had a control logic where I check my real and imag, when both zero, I use a multiplexer to make the phase zero. (Alternatively I can also check the magnitude as you said)
I was curious if there is any other way inside CORDIC itself to deal with this. But I guess I am satisfied with what I have now. Thanks for the input!

And what do you mean by non FFT space?
Thanks,
Bhavanithya Thiraviaraja
Scholar
771 Views
Registered: ‎05-21-2015

Estimating phase transitions in a sequence ...

Well, let me back up and share the application I was working with.  I was working with estimating the time delay between two signals.  Let's call them x_1(t) and x_2(t).  The general algorithm involved FFT'ing both sequences, conjugate multiplying them together, and then taking an inverse FFT to get: x_12(tau) = FFT^(-1){FFT{x_1}^{*} FFT{x_2} H(f)} where H(f) was a filter stuffed into the middle of the operation.  Much of the literature discussed what the best filter would be to perform this operation.  Once the operation was done, the maximum value of x_12(tau) would be at a location related to the delay between the two signals.

If I rephrased this problem, I might say I was "dealing with phase estimation for a sequence" (the values prior to the inverse FFT).  Hence, taking an FFT, or in this case an inverse-FFT, of such a sequence is often the easiest way to estimate the most common phase progression within the sequence.  It's also the basis of a maximum likelihood statistical estimator (one that works *really* well), but that's another topic for another day.

Hopefully that makes some more sense.  If not, feel free to check out the references I linked to earlier.

Dan

Explorer
757 Views
Registered: ‎10-14-2017

Yeah, you're right, it is possible to input 0/0 values into CORDIC. I'm sorry if I made it seems like it is not. What I meant is that you won't get a valid answer at the output, so one of two options would be to filter the input and the other would be to filter the output.

Anyways, I think he got his answer.