Now that we understand the architecture required to make synchronization happen, we must then look at methods to achieve synchronization in our application. The first method which is common with most basic synchronization tasks is to eliminate round trip delay (RTD) from the application. Take for instance the following application setup below:
Figure 2: Gen/Acq Synchronization Example Diagram - Stimulus Response
We can see that for stimulus/response applications, the time required for data to move from the digital tester, through the cable and DUT, and back to the tester can present a delay issue (RTD). The goal of this section is to provide a comprehensive, high-level overview of the tools we have available to compensate for this type of RTD; more details on each method can be found in the HSDIO help files, device specifications, or the many other HSDIO KnowledgeBase articles and whitepapers online.
A. DDC CLK OUT/STROBE, Data Active Event RTD Compensation
One way to do RTD compensation, and the method used in source-synchronous examples, is to export the sample clock/start trigger from the generation task, using DDC CLK OUT for the Sample Clock and PFI 1 for the Data Active Event (Start Trigger). The connections are then tied to the acquisition task via STROBE and PFI 2 input pins, respectively.
PFI1, PFI2, DDC CLK OUT, and STROBE are all on the DDC connector, and should be routed appropriately to the DUT via breakout board (such as the CB-2162) or with the flying lead cable.
The connections and process to program this procedure is demonstrated below:
Figure 3: Source Synchronous LabVIEW Example with Connection Diagram
Starting from the acquisition side, if we consider the diagram above for the 6556, the STROBE is routed through the same Digital Data and Control (DDC) connector as the rest of the Digital I/O (DIO) signals. From the Digital Waveform Generator/Analyzer Help:
“The advantage of using STROBE as the Sample clock source signal for the acquisition operation is that the acquisition session Sample clock and the data channels now travel together through the same cable and system delays, maintaining time correlation between them.”
For the generation task, the same process applies to the DDC CLK OUT line. Sending the clock signal along with the generation data ensures that the data channels have the same path delay as the clock signal internally to the HSDIO device. DDC CLK OUT is sent out synchronous with the data, so you are guaranteed to have data transitions occur at the clock transition points you have selected.
The Data Active event acts as the trigger for the acquisition and, since it is matched with the data, asserts at the right moment for acquisition to begin on the first sample correctly. A separate external connection does not have be made for the event since it resides in the DDC connector/cable path. In some situations, routing this signal out of PFI 0 may be necessary, which will require a different method for synchronization covered in the next section.
B. Other Methods for RTD Compensation
The method we described above is usually sufficient if the cables in use are length matched and the clock signal is able to be sent along the DDC connector. In the event that cables cannot be length matched, or a measurable delay is still noticed, there are a few other methods for RTD compensation. To use these methods, we must first know the total round trip delay, and figure out the number of clock cycles/fractional clock cycles of our generation clock this will take.
i. Data Delay/Data Position
Data Delay can be used to adjust the setup/hold time required for the application to improve the bit error rate (BER) of the application. Data delay is commonly used in synchronization applications.
Note: For details on delay resolution and allowed frequencies for each device, refer to the article on Advanced Features of High-Speed Digital I/O devices: Data Delay, or to the specifications manual for your device.
Data Position allows you to select rising edge or falling edge as the normal mode of sampling on your sample clock. This is commonly used to coarse adjust the data delay of a generation/acquisition. A great tip to use when building your application: set up the generation task for rising edge and the acquIsition task for falling edge data position. This means you will transition your generated samples on the rising edge, while sampling on the falling edge of the clock (presumably halfway in between rising edges). This works for most application that are cable length matched.
Note: For details on data positioning for each device, refer to the specifications manual for your device for a more detailed explanation and timing diagrams for generation/acquisition.
ii. Data Deskew (only supported on 6555/6556)
The Data Deskew property allows us to set the timing delay after the Sample clock edge when the device generates or acquires a new sample. This is applied independently of Data Delay, although it is the same circuit that performs the delay. The valid values, given in seconds, range between -2 to 3 sample clock cycles for both the 6555/56. The total combined delay from Delay and Deskew cannot exceed the range above. The idea behind Data Deskew is that the Deskew property can be used to cover any cable propagation delays measured, and the Data Delay property can be used for fine-tuned eye diagram and setup/hold time adjustments.
ViStatus = niHSDIO_SetAttributeViReal64 ( vi, channelName, NIHSDIO_ATTR_DATA_DESKEW, ValueOfDeskewInSeconds);
Figure 4: Data Deskew as Programmed in LabVIEW and C
An example of using Data Deskew properly would be when your test setup has to change its cabling requirements, but still stays the same in software. The new cabling will have a different propagation delay, which can be adjusted by the Data Deskew value. Setup and hold timing will therefore stay the same, making it easier to use when changing cables and/or applications.
iii. Internal Route Delay (IRD)
The Internal Route Delay property is a ‘coarse’ option that can be used for delay compensation when the Strobe/DDC CLK Out connections are not used. Setting this property allows us to delay the Data Active Event coming from our generation task by an integer number of clock cycles (refer to device specifications for valid values). Note that this property is only applicable in the acquisition session, and cannot be used in conjunction with the STROBE external clock source. The Data Active event will be automatically routed internally, so no routing configuration is necessary. However, the niHSDIO Configure Trigger VI on the acquisition should have the source parameter set to ‘Delayed Data Active Event’.
ViStatus = niHSDIO_SetAttributeViInt32 ( vi, channelName, NIHSDIO_ATTR_DATA_ACTIVE_INTERNAL_ROUTE_DELAY, ValueOfRouteDelayInSampleClockCycles);
Figure 5: Delayed Data Active Event and Internal Route Delay as Programmed in LabVIEW and C
iv. Sample Clock Offset
One final method for delay compensation that can be used in source-synchronous applications is the Exported Sample Clock Offset property. The exported generation sample clock will be delayed by a fixed time amount that varies depending on device.
ViStatus = niHSDIO_SetAttributeViReal64 ( vi, channelName, NIHSDIO_ATTR_EXPORTED_SAMPLE_CLOCK_OFFSET, ValueOfClockOffsetInSeconds);
Figure 6: Exported Sample Clock Offset as Programmed in LabVIEW and C
The following timing diagram should help to visualize how each of these properties will affect the data and clock positions of a generation session:
Figure 7: Clock and Data Position Timing Diagram
Note: more timing diagrams may be found in your device’s specifications manual.