Scribd
Upload
90 views

Worklog 5761 Sync

This document describes testing and modifying code for synchronizing acquisitions across two NI 5761 devices using the FIDL Sync API. Key points: 1) A test was developed using an NI 5450 to source identical signals to both 5761s. Measurements showed the reported "synchronization delay" was longer than actual by 21 samples. 2) Previous examples were modified to account for this offset, and support acquiring from four channels on each 5761 instead of two. 3) Testing of the modified code showed synchronized 250M sample acquisitions across both devices with minimal DRAM usage. Resetting the FPGA too frequently was found to cause issues.

Uploaded by

tuanhai1989
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
90 views

Worklog 5761 Sync

This document describes testing and modifying code for synchronizing acquisitions across two NI 5761 devices using the FIDL Sync API. Key points: 1) A test was developed using an NI 5450 to source identical signals to both 5761s. Measurements showed the reported "synchronization delay" was longer than actual by 21 samples. 2) Previous examples were modified to account for this offset, and support acquiring from four channels on each 5761 instead of two. 3) Testing of the modified code showed synchronized 250M sample acquisitions across both devices with minimal DRAM usage. Resetting the FPGA too frequently was found to cause issues.

Uploaded by

tuanhai1989
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 14

References:

 RH on SFDC
https://natinst.my.salesforce.com/a1A31000006dOJC

 Previous Request
 Resource locations
 Internal root directory for this RH
1. Define Task Scope and Environment
1.1. Write Overview
In this work, two sets of 5761+7975R are synchronized at their start of streaming
acquisition, lasting one second.

1.2. Define Specifications


 One set of 5761+7975R acquires signals from all four channels
 Once acquisition starts, it continues until pre-entered number of samples
have been acquired.
 Length of one acquisition is supported up to 250M samples, which equals to
one second acquisition at sampling speed of 250MSps.
 Start of the two sets of 5761 + 7975R are given by external digital trigger.
The digital trigger is routed to only one set out of the two sets of 5761 +
7975R.
 Two boards synchronously start acquisitions at the rising edge of external
digital trigger. Acquired data on host PC should be available from the very
moment of the rising edge of external trigger.
 the maximum phase offset between the master and a slave is 2/3rds of a
sample clock.
1.3. Describe SW Environment
 LV 2015 SP1
 LV FPGA 2015
 FlexRIO 16.0
2. Do some preparations
2.1. Check latest API for Synchronization
Queried to FlexRIO R&D about Latest APIs for multi-module synchronization.
The answer was that FIDL Sync API is the latest. So, I need to keep using
FIDL Sync API.

2.2. Regenerate IPIN of TDC VI


Back in two years ago, LV 2014 was used. This time, LV 2015 is used and IPIN
have to be regenerated for TDC VIs. Error was returned during regenerating
IPIN. After a research, following NI-Talk discussion helped to resolve the error:
NGC IPIN 2015 Error XSIM 43-3238.

2.3. Modify Previous Example for 5761 and Failed


For the first time, I assumed just some simple modifications would make the
previous example work for 5761. However, it did not work as expected, having
trigger offset (“synchronization delay”) fluctuated for some reason.

3. Back to Basic Test with FIDL Sync API

3.1. Set up HW
REQ_3_1_HW_DIAGRAM
Two sets of 5761 + 7975R are used to be tested for synchronization capability.
As a signal source, 5450 is used, because it can generate same signals at same
timing from two different channels. Signal connections are as follows. If
one signal source is split into two directions for a purpose of sourcing the same
signal to two 5761s, it does not work as expected, because 5761s are designed
to have some bias voltages at its signal inputs. (Refer to documents linked
at NI 5761 Offset Issue)
 5450 Generates Analog Waveform from its CH0+
 At 1st sample of generated Waveform, 5450 exports data marker0 from its
PXI Trigger 1 and marker1 from PFI 0. (At the same sample index of 0,
marker0 and marker1 are generated to route same event to two different
output ports.)
 Marker 1 from PFI 0 is connected to AI0 of Master or Slave of 5761
 Analog signal from CH0+ is connected to AI0 of the other 5761
3.2. Reuse Example for 5450 Signal Gen
REQ_3_2_5450_CODE
Almost just copied an example of Arbitrary Waveform of FGEN driver. The
copied code is located under project, nasmed “Test Signal From 5450.vi”.
Below is an image of two waveforms acquired on both AI0 (5761 Master) and
AI0 (5761 Slave). As shown in the image, rising edge of trigger signal (maker
event) and generated square waveform are matched.

REQ_1_4_2_WFM_ON_GRAPH
3.3. Review Theory of Op. of Sync Mechanism
I re-drew timing diagram of synchronization mechanism for two purposes: 1 to
re-check my understanding about the sync mechanism, 2 to have a diagram to
explain the mechanism,. There are two citations for drawing the diagram: 1
“FIDL Synchronization Theory of Op.pdf”, 2 “about the behavior of
“synchronize signal.vi””

REQ_3_3_TIMING_DIAGRAM
Based on this review, synchronization mechanism is accomplished by followings.
1. Before synchronized acquisition starts, buffer the in-coming samples in a
circular buffer. The amount of buffered samples should be larger than the
amount of tick counts with longest delay between actual and synced
triggers.
2. Acquisition starts in a synchronized manner.
3. For the first fetch on host PC, the number of samples to be fetched is
equal to (one reading sample) + (buffered samples). For fetches after 2nd,
the number of samples to be fetched is equal to just (one reading sample).
4. On host-side, discard the extra samples from buffered samples. The
amount of discarded samples will be (buffered samples) – (synchronization
delay)
5. For the rest of all fetches, do some array operations.
3.4. Test by Simple Code
REQ_3_4_TEST_FIDL_SYNC_HOST
REQ_3_4_TEST_FIDL_SYNC_FPGA
Based on multiple test, the amount of "synchronization delay" measured by
"Synchronize Signal.vi" is found longer than actual value by about 21. Below
is FPGA VI named “tc-Test Sync API 5761 (FPGA).vi”.

In this VI, following items are implemented.


 right timing for latching “synchronization delay”.
 “synchronization delay” value has a linear relationship with the timing of
rising edge of acquired signal.
 CPTR signal is measured for its HIGH and LOW time.
Below is Host VI named “tc-Test Sync API 5761 (host).vi”.

Below is UI of the host VI. As seen below, actual edge location does not
match with calculated edge position, whose value should be 2*(pre trigger
length) – synchronization delay. In below, synchronization delay is returned
34 and 2*25-34 = 16 should be the expected edge position of acquired signal.
However, based on multiple tests, it is found that the actual edge of acquired
signal is off by 21 clocks.

Therefore, I decided to add a constant value of 21 as shown in the diagram


below.
4. Re-modify Prev. Example
Based on the test results above, modified previous examples. For FPGA, the
difference from the previous example is mainly the increase of channel count
from two 16bit channels to four 16bit channels. Due to this, the amount of data
per second gets higher from 1GB/sec (250MSps * 2Byte/sample * 2Ch) to
2GB/sec (250MSps * 2Byte/sample * 4Ch). The DRAM bandwidth is a bit
concerned at this moment.
Below is the modified FPGA example named “tc-acq engine + Sync mechanism
5761 (FPGA).vi”.
REQ_4_MODIFIED_EXAMPLE_FPGA

As in the red dotted rectangular below, buffer for pre-trigger has U64 data type
for its data type, because 5761 has four channels and 16bit * 4 is 64bit wide.
4.1. Show Project
Below is project explorer view of modified example.

4.2. Re-modify Fetch VI


REQ_4_2_RE-MODIFIED_FETCH_VI
1. For 1st fetch after acquisition is started, the number of samples to be
fetched is equal to (L1) + (L2) + (Samples per read)
2. After 1st fetch, read “synchronization delay” given by FIDL “Synchronize
Signal.vi”. This value is “L1” in diagram above
3. Cut out 1st fetched samples so that the top of “L2” is start index and its
length is “Samples per read”. This gives 1st effective set of fetched
samples
4. The residual of 1st fetched samples will be the first part of 2nd effective
set of fetched samples.
5. After 2nd fetch, samples to be fetched is (Samples per read)
6. Cut 2nd fetched samples at index of (Samples per read) – (L2)
4.3. Test Re-modified Example
REQ_4_3_MODIFIED_EXAMPLE_HOST
Below is host code named “tc-acq engine + Sync mechanism 5761 (host).vi”.
Tested that 250M record length is properly acquired, using almost full depth of
DRAM on 7975R. The graph below shows the eight channel waveforms of last
fetch.

One thing to note is that FPGA should not be reset at all times, because DRAM
seems to require some time for its stable operations after a reset. This is found
by timeout error which has frequently occurred due to the hesitation of DRAM
ready for write. So, FPGA “reset” method should not be called even at the
beginning of VI run. Also, “reset” at close FPGA reference should be un-
checked, so that FPGA is not reset.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy