Jump to content
Stormshadow

[FPGA] Discrete Delay not computing correctly?

Recommended Posts

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)

lPntOZT.png

 

Code:

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

4ZrBnMP.png

 

 

Thanks

Share this post


Link to post
Share on other sites

still debating about it

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

still debating about it

 

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

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.