[FPGA] Discrete Delay not computing correctly?

[Stormshadow]

Question:

How is 9*512 Discrete delays equal to ~410us?

 

Context:

We have found a solution to an offset problem between 2 sine waves, however we are unable to explain the delay calculations...

(Someone else did the work a long time ago, now we need to explain the fix).

 

There's 6us delay between the input Sinewave and the generated Sinewave from that input. Sinewave period is 416us (Figure 1).

 

The Code works with 9 blocks of 512 Discrete Delays. 9*512*(1/80MHz) = 57.6us, but why is this working?

 

Cannot Modify the code:

The project is set and no code can be modified.

 

Project Settings:

The FPGA derived is at 80MHz, but the project Top-Level Clock seems to specify 40 MHz.

The system automatically detects if there is an error greater than 5 degrees phase shift.

 

Problematic:

(http://prntscr.com/7ahhi5)

 

Code:

(http://prntscr.com/7ah2t3)

 

 

Thanks

[hooovahh]

Crosspost

[Stormshadow]

still debating about it

[hooovahh]

still debating about it

Sure but a crosspost helps give some context to those unfamiliar with the history of the issue.

[Neil Pate]

And it sure it an interesting thread if you care about things like absolute timing on FPGA.

 

Thanks for the crosspost hooovahh I don't browse ni.com nearly as much as I used to.

[shoneill]

still debating about it

 

You are still debating it. As far as I can see, everyone else is happy with the answers given.

[JamesMc86]

Hi,

 

The short answer is I don't think your loop is running as fast as you think.

 

On a standard LabVIEW while loop on the block diagram the loop time is the execution time of the code inside the loop. 

 

On a single cycle timed loop is where the loop time is equal to the clock rate, this would give you the calculations you expect.

 

To try and work it through, I'm unsure the execution time of the delay blocks off the top of my head but it seems possible it could run in one cycle.

 

Remembering that these are shift registers effective means:

 

1) They are not part of the calculation

2) The longest path is only one side of these

 

This makes the longest path (the U16 to I16 conversion should be free) 5 ticks (3 if not).

 

5 * 25ns = 100ns period.

100ns * 9 * 512 = 460.8uS, we are getting close.

 

Anyway the short version is that using standard while loops for specific timing is tricky because as soon as you change the code, you change the timing. I would do some reading around single cycle timed loops, they give you reliable timing and I think are closer to the behaviour you expect, but beware there are few gotchas in some unsupported functions and if you try and do to much the compilation will fail.

[Stormshadow]

thanks