From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Could someone explain this FPGA i/o timing issue?

Solved!
Go to solution

Hi Everyone,

I a trying to push my PXIe-7821R to its limits but there is something not clear to me.

I am running with FPGA clock of 40MHz.

Looking at the picture

Capture.PNG

With both "wait" set to '1' I was expecting that the duration of the two frames would be the same, i.e. once tick of the 40 MHz.

Instead, I see that the first frame takes two ticks. It seems that the operation of reading the I/O cannot be done in parallel with writing another one.

Do someone can explain me if it is possible to have the I/o reading and writing happen at the same time?

Thanks

 

 

 

 

 

 

and considering "1" as number of ticks for CLK high and low, I would have expected that the first frame duration would be exactly one 40MHz tick.

Instead, it seems theat

0 Kudos
Message 1 of 12
(2,986 Views)

Why even have the waits if they are just going to be 1?  The write alone will take 1 tick.  It might be another tick to write to the other node.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 12
(2,975 Views)

It is a portion of a sequence where I generate a clock and the on and off time of the clocks are configurable from host VI.

The point tis why the frame with write + read takes two ticks instead than 1.

 

Thanks

0 Kudos
Message 3 of 12
(2,966 Views)

Without seeing any of your project configuration, my guess is that the number of synchronization registers for your digital read is adding a tick.

 

If you right-click your I/O item in the LabVIEW project and select Properties, you will see Advanced Code Generation. The last item in the dialog should be Number of Synchronizing Registers for Read. The number of sync registers, plus the LabVIEW FPGA enable chain (and possibly your waits) are likely responsible for what you are seeing.

 

Note that there are good reasons for having multiple sync registers. Before changing this value, please click the Help button on the dialog and read about the different settings and why the defaults are chosen.

Donovan
0 Kudos
Message 4 of 12
(2,944 Views)

Hi Donovan,

your answer makes sense to me.. however I tried and set the registers number to 0 but I could not see improvements.

Then I tried to move the indicator that is used for the I/o reading out of the sequence and it seems to be solved:

Capture.PNG

 

Does this make sense to you?

 

Thanks


Francesco

0 Kudos
Message 5 of 12
(2,932 Views)

The value in the indicator has to be persisted, so it also gets a register. So, you have any synchronization/enable chain registers for the I/O node and an additional register (which consumes a clock tick to latch) when writing to the register. So, yes that would seem to make sense to me.

Donovan
0 Kudos
Message 6 of 12
(2,906 Views)

Hi Donovan,

So in principle any control or indicator in any sub-vi will have its cost in terms of ticks... Right?

Anyway thanks for your help it really helped me a lot.

 

Francesco

 

0 Kudos
Message 7 of 12
(2,890 Views)
Solution
Accepted by Effedipi

Hi Francesco,

 

Not exactly. Controls and indicators on the top-level FPGA VI do use registers to persist data because the FPGA Interface Read/Write Control needs to have a way to access those items, so you do have extra registers for those items.

 

However, the underlying thing you are seeing here is the Enable Chain. Since it looks like your VI is running outside of a single-cycle timed loop (SCTL), all of the code that is executing is subject to the enable chain. The enable chain is the mechanism that enforces dataflow on the LabVIEW FPGA block diagram. Basically, if the code is not in the SCTL, pretty much every node on your diagram will require a register to support the enable chain.

 

Inside the SCTL, the compiler guarantees the entire path of your code can execute within a single clock cycle, so the only time LabVIEW FPGA needs to latch the data is on the edge of the clock. This allows you to bypass the enable chain, but also means any code path in your loop must execute within that single clock cycle. If timing fails, you will need to do things like add feedback nodes to pipeline your design so everything will execute in a single cycle. SubVIs called inside the SCTL will not have registers for the controls/indicators in this case.

Donovan
0 Kudos
Message 8 of 12
(2,867 Views)

Hi Donovan,

I think I understand.... but I have one question: in SCTL I cannot use delays, so how can I implement a user programmable delay between one I/O set and another (to generate a variable frequency clock for example)?

Thanks

 

Francesco

 

0 Kudos
Message 9 of 12
(2,845 Views)

There are a few ways to accomplish this. The one I've found most useful is to have a counter that increments each loop cycle (clock tick) and a control on the front panel that a user can change to set the number of ticks for the delay. In the loop, compare the value of the counter to the set point for the delay. If the count has hit the set point, change your output. If not, keep the output the same. When the output changes, reset the counter to zero and start counting over again.

 

Or, if you just need a variable frequency square wave, you could also use the Square Wave Generator configured to run inside the SCTL. This function has inputs for frequency, among other configuration options.

Donovan
0 Kudos
Message 10 of 12
(2,817 Views)