Output wrapping on FPGA high-throughput sine & cosine function

[Andrew_P]

Hi,

I'm using the high-throughput sine & cosine FPGA vi, and i've noticed that the sin(x) output momentarily wraps from +1 to -1 or -1 to +1, but the cos(x) output doesn't do this. Also, this wrapping is intermittent. Since the help file says that the CORDIC algorithm uses a fixed point configuration with integer word length of 1 bit (range of (1,-1] ), it seems like this wrapping would be a problem internal to the vi. I tried using round-half-even mode, but this didn't help. This wrapping is not acceptable, since it creates a momentary 180 degree phase shift.

The High-Throughput Sine & Cosine vi is using a fixed point configuration of 20 bit internal word length (I increased it from the default of 16 bits). The theta input is a signed fixed point, 20 bit word length, 1 bit integer word length. I placed it in a single cycle timed loop (SCTL), and the SCTL is in a flat sequence structure where the SCTL gets called once every 4,000 clock ticks (100us). The SCTL stop command is issued once the chain of input/output ready is finished. I am sending the theta input, and sin(x) & cos(x) outputs to 3 channels of a 9263 AO module, and viewing them on an oscilloscope. Since this vi is inside a SCTL that is called once every 100us, I see that the sin(x) output goes from +1 to -1 for 100us.

I've attached a code snippet, and a oscilloscope trace. The oscilloscope trace shows theta on Ch1, sin(x) on Ch2, and cos(x) on Ch3. Theta is in pi radians, and wraps from 1 (pi) to -1 (-pi). 

Has anyone else encountered this? Any solutions? 

Btw, I'm using compactRIO: 9022 controller, 9114 chassis, 9263 AO module, and LV 2009.

Thanks,

Andrew

[Andrew_P]

I've changed some of the internal settings, such as decreasing the throughput setting to 16. This makes the wrapping occur less often, but doesn't get rid of it.

Do any of the applications engineers have any ideas about a solution, or info about the inner workings of the vi that might help?

Thanks,

Andrew

[JLewis]

Hi Andrew,

I don't see anything obvious in your code that would produce this behavior, so I've asked the developers to look into it. What LabVIEW version are you working with? Have you seen the wrapping behavior when executing on the development computer, or only in hardware?

Thanks,

Jim

[Andrew_P]

I'm using LabVIEW 2009 SP1, version 9.0.1. I've only tried it in hardware.

[JLewis · Accepted solution]

I just noticed that your test VI is passing the Sin/Cos outputs directly to the AO Outputs indicator without filtering out the invalid outputs. I can see wrapping similar to yours in that case, but if I only look at outputs where "output valid" is true, I am not seeing any wrapping. Since the throughput is 16 cycles/sample, most of the outputs are invalid and provide no guaranteed behavior between valid outputs. Is your actual AO VI setup the same way?

[Andrew_P]

That's a good point about possibly displaying invalid outputs, thanks. My AO's are in a while loop with no other timing/triggering, so I suppose if I triggered my AO loop once this sine/cosine SCTL loop is finished, then I would get a valid output (I've moved the theta increment portion to a separate section of the sequence, to make sure that theta is constant the entire time the sine/cosine vi is running), right? I'll give this a try. Otherwise I would have to create some sample & hold block for the sin(x), cos(x) outputs, triggered off the output valid signal.

The reason I set the throughput to be less than the word length, is that when the throughput is equal to word length, and there is no pipe-lining, the output was very discretized. It appeared as though it were coming from a ~4 bit DAC (only had about 16 or so discrete levels). I guess this is a separate issue though since I've moved the theta increment outside of the SCTL of interest.

[JLewis]

Making theta constant might be a little more clear, but shouldn't change any behavior--the node ignores any inputs that it isn't ready to receive. I would recommend using a case structure to ensure that you only write valid outputs. This will work for either FIFO or local variable loop communication, as the last written value will be held until you update it.

[Andrew_P]

Once I added a case structure to make sure I'm only passing valid inputs to my AO channels, the wrapping went away. Thanks!