# [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:

Code:

Thanks

##### Link to comment

still debating about it

##### Link to comment

still debating about it

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

##### Link to comment

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.

##### Link to comment

still debating about it

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

##### Link to comment

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.

thanks

## Join the conversation

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

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

Only 75 emoji are allowed.

×   Your previous content has been restored.   Clear editor

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

×
• ### Similar Content

• #### NI drags its feet...

By Sam Dexter,

• 7 replies
• 947 views
• #### labview Synchronization in FPGA with AO and DO

By mhsjx,

• 0 replies
• 464 views
• #### Best circuit board for LabView

By Ricardo de Abreu,

• 17 replies
• 8,630 views
• #### LabVIEW 2018 and sbRIO-9626

By grjgrj,

• 5 replies
• 2,539 views
• #### FPGA Image Convolution error

By prabhakaran,

• 3,782 views
×