Hsdio Pxie-6556 - Configure Data Position Delay

[engfpe]

Hi,

I am working with the Labview example ``Dynamic Gen and Acq With Per Pin Data Delay and Deskew.vi``

I changed the vi to use the onborad clock for acquisition and generation session.

This vi send a stimulus from channels 0-7 and read fron channels 8-15.

For the generation session the data delay is 0.5

For the acquisition session the data delay is 0

My understanding is that with this configuration the board will first read and after send the data.

But in the Data Acquired table it seems the acquisition and generation  are being doing in the same time. What is wrong

Please see the front panel vi picture attached.

I am using Labview 2013 and PXie-6556

[lferreira]

Hi,

At this example  the main propose is how to configure data position, data delay and data deskew per pin. For example, when you set 0.5 for data delay you want the Generation will start with a delay of 0.5  after sample clock rising edge. The both Acquisition and Generation seem to go on same time but the acquisition will always start once the data active event of the generation session is asserted.

I hope to help you to understand it.

Regards

Lincoln

[engfpe]

You are right. 

As I could observe the generation start at the first rising edge (+0.5 delay) and the acquisition will start into next sample clock rising edge.

There is one sample clock cycle delay between generation and acquisition

Please see the picture attached.

[Kyle_A.]

Hello,

How are you triggering the start of the acquisition? If you are using Data Active Event, it should start on that edge. However, it may start on the following edge due to skew in the system. Also consider if you are using a 1m cable that it takes time for signals to propagate up and down the cabling, which could also affect the timing in the system.

[engfpe]

I am using the SHC68-H1X38 High-Speed Digital Flying-Leads Cable Accessory, 1.5m and connecting PFI1 to PFI2 directly. Acquisition and Generation are using on board clock. The sample clock is 100kHz.

I executed the vi two times.

First time:         generation delay 0.25 and acquisition Data Position --> Rising edge  --> The value read for DIO0 is 0

Second time:  generation delay 0.25 and acquisition Data Position --> Falling edge  --> The value read for DIO0 is 1

With this results it seems the acquisition is in the second sample clock cycle.

I do not understand how a propagation delay can be a issue with a 100kHz sample clock.

Please see the picture attached

[Kyle_A.]

For 100 kHz, prop delay is not a factor, you are correct. Some tips on alignment:

• For HSDIO Generation, usually you set it to generate on the rising edge with no data delay, and this becomes your reference for all other functions. This is because generation tasks typically start slower from the engine to the front of the board than acquisition (which is pretty much instant).
• The most accurate synchronization is source synchronous. It requires exporting the onboard clock from DDC CLK OUT to STROBE, and also using the Data Active Event as your start trigger. Everything here is trace matched and propagates as much as data propagates.
• For HSDIO Acquisition, sample on the falling edge, or delay from rising edge to get in the middle of the window and have valid setup/hold times. This ensures you are never sampling on an edge where the data is transitioning. For instance, you do not want to sample on the rising edge of the clock because it is where the data is changing, and you would invalidate setup/hold time.

One thought is if your code is using onboard clock to sample, you are not passing that clock down the data line, so that will definitely introduce unknown skew into your system. I would recommend passing the clock out with the trigger and data and looping it back to the STROBE line on the flying lead cable. This should result in a stable, known, and repeatable synchronous digital system.

[engfpe]

Hi Kyle

Thank you for your assistance.

I already follow these tips my test system, but the problem is that I always need to shift my acquisition test vector one sample clock cycle to get the synchronization.

I was executing this vi at low frequency (to avoid propagation delays problems) and find out a way to fix this issue.

Even if I connect the Strobe pin as you mention the results are the same.

According what I can see in the oscilloscope, even if is not the expected result, the acquisition is one sample clock cycle delayed from generation for practical purposes.

[Kyle_A.]

In software, are you enforcing data flow and starting your acquisition session before your generation session? Is your start trigger set to a PFI line which takes in Data Active Event on your acquisition session? Are you using a shipping example to verify the behavior you are seeing?

[engfpe]

Yes

I am using the shipping example " Dinamic Gen and Acq with Per Pin Data Delay and Deskew.vi "