PXI

cancel
Showing results for 
Search instead for 
Did you mean: 

Synchronizing clock edge with data position

Happy hollydays everyone
 
I have a PXI 6562 and I am using it to acquire digital data from output terminal of a simple counter. I am also using strobe to import an external clock and use it to sample the input signal. Since I am using the same clock to exite the counter and acquire data, I expect perfect synchrinocity.
 
The expected digital wave form should be ulternating from high to low at the frequency of (from the LSB to the MSB) the same as , half, quarter, eigth, sixteenth ... rate of the clock. Further more every signal should have a duty cycle of 50%.
 
However, the duty cycle of all the acquired signals, except for the LSB one, are following the pattern 0.25, 0.125, 0.0625, 0.03125 ...
 
Questions:
 
a. When I use the niHSDIO Configure Sample Clock.VI  and select STROBE as clock source, do I need to specify the clock rate
        if I do need to, then does the PXI 6562 use the clock rate I had specified or that it had detected from the external clock?
b. How can I read digital patterns of varying frequency but 50% duty cycle with out losing or distorting the duty cylce of every signal?
0 Kudos
Message 1 of 12
(3,527 Views)
What's an...


Questions:
 
a. When I use the niHSDIO Configure Sample Clock.VI  and select STROBE as clock source, do I need to specify the clock rate
        if I do need to, then does the PXI 6562 use the clock rate I had specified or that it had detected from the external clock?


This is a good question.  The short answer is that if you program the device to use STROBE, it will clock the hardware at the rate you input to the STROBE line.  However, when you program the device to use STROBE, you still need to specify the frequency at which that signal will be toggling.  There are certain software features that require a frequency component in the math.  The value you input to these clocking functions will NOT overwrite the frequency you input to STROBE, it only makes sure the hardware is set up correctly to receive a clock at that rate.  For example, if you tell the software you want to run at 25MHz but input a signal at 2.5MHz, the hardware will not be setup ideally for 2.5MHz and may produce errors.  Does this make sense?


b. How can I read digital patterns of varying frequency but 50% duty cycle with out losing or distorting the duty cylce of every signal?


I don't think I completely understand your question.  The channel electronics don't distort duty cycle.  As the data passes through the front end the data is sampled using the clock you specify.  If you are providing a source synchronous clock from your DUT to the 6562 and telling the HSDIO driver to use STROBE then all channels will be sampled on either the rising edge, falling edge, both edges, or on a delayed version of the rising edge of the signal you input STROBE.  There are specifications that deal specifically with a signal input to STROBE which you may want to verify, especially if you are operating at high frequency.  A copy of the specification should have been installed with HSDIO and can be found under:

Start>>Program>>National Instruments>>NI-HSDIO>>Documentation>>Specifications>>NI 656x Specifications

in the  Timing>>STROBE(DDC Connector) section

Based on your explanation, it seems that your LSB channel matches your expected data but your other channels do not.  Are you certain that your dut is generating 50% duty cycle signals?  If there were a problem with setup/hold or minimum pulsewidth violations (as specified in the above document) then I might expect no channels to be sampled correctly.  However, the fact that your slower toggling signals are the ones that do not match expected would suggest that the DUT may not be correctly generating data.

One thing you could try would be to open up a test panel to the 6562 from MAX.  Start a generation task with a count at some frequency close to the one you are trying to run at.  Next, start an acquisition task using the on board clock and grab an acquisition.  You should see a typical count pattern where the LSB toggles most frequently.  This would verify that you can receive a count pattern.

If this was not much help, please include some screenshots or a more detailed description of your observed behavior.

Thanks.
Message 2 of 12
(3,516 Views)

Thanks for replying promptly.

I probed the output terminals of my DUT using oscilloscope and they seem to meet the expected digital pattern.

The acquired data using my application agrees with that of the device's test panel.

I can safely assume that the VI's used in both my application and test panel come from the same set.

So the niHSDIO Read Waveform.VI is so primitive that I only have its parameters to play with.

Is there any other way of acquiring data than the above mentioned VI?

Is there a significant propogation delay resulting from the difference in the strobe and data channel traces inside the PXI 6562?

Perhaps the signal coming through the strobe may pass through more or less logic circuits than that of the channel lines.

 

0 Kudos
Message 3 of 12
(3,513 Views)
The propagation delay from channel to channel is specified as "Channel-to-channel skew" on page 12 of the specifications.  For applications below 25MHz, the typical skew would be +-600ps.  For applications > 25MHz, the typical skew is +/-330ps.  Also, STROBE is not significantly skewed from data through the hardware.  If you meet the required "Set-up time to STROBE"  and "Hold time to STROBE" (page 12 again) from you sampling edge, you are guaranteed to sample the data correctly. 

Set-up time to
STROBE
(tSUS)
f ≥ 25 MHz = 1.1 ns
f < 25 MHz = 1.8 ns
Note: At 25 MHz and higher, STROBE duty cycle is corrected
to 50% while maintaining rising edge placement.
Maximum;
includes
maximum
data
channel-tochannel
skew


Hold time to
STROBE (tHS)
f ≥ 25 MHz = 0.8 ns
f < 25 MHz = 2.1 ns
Note: At 25 MHz and higher, STROBE duty cycle is corrected
to 50% while maintaining rising edge placement.
Maximum;
includes
maximum
data
channel-tochannel
skew


Again, these values will change if you are running above or below 25MHz so make sure you are inputting the correct frequency into your code.  If you are not providing enough of either of these parameters then we cannot guarantee that you will get the correct sample.  If this is the case, I would suggest changing your sample position using the "Data Position" attribute.

However,  if you were violating one of these timing parameters you would have an increased probability in missing your LSB since it is toggling faster so you have an increased number of edge to edge timing comparisons.  With a slower toggling signal, the data remains stable through clock edges extra margin to setup and hold.  Since you are not sampling the slower signals correctly I would say that it is not a timing margin issue.

Could you attach your code, a screenshot of the channel that passes and a the channel that fails and STROBE with a description of how you probed the signal so that we know we are comparing apples to apples?

In general, though, if you provide the sufficient timing margins and adequate voltage levels as specified in the 656x documents then the 656x should have no problem sampling a counting pattern.
Message 4 of 12
(3,505 Views)
What's an...

I'm sorry, I neglected to answer your other question.

The niHSDIO Read Waveform VI is a higher level acquisition VI that will configure hardware and start an acquisition when called.  A lower level vi called niHSDIO Fetch Waveform can be used to only fetch data out of memory.  Using this VI requires that you properly commit all of your settings and start the task on your own but gives greater freedom and flexibility in fetching data from the on board memory.

For both of these VI's, though, the hardware acquires data and places it into memory in exactly the same way.  Their only differences are in how the software executes.

For examples using either, please see "Dynamic Acquisition with Fetch.vi" and "Dynamic Acquisition with Read.vi"
0 Kudos
Message 5 of 12
(3,504 Views)

I have a custom cable adapter build to present the signals from the DUT to the PXI. At the same time there is a break out point where every signal in the infiniband connector is routed to access points. so I am capable of probing all data channels, triggers and clock input and output pins.

The Mictor to infiniband adapter is characterized and properly terminated and tested to work correctly.

I am attaching a copy of my labview code. The NI-HSDIO Express (Acquisition) VI is used to compare acquired data with what the niHSDIO Read Waveform.VI gives me.

 

0 Kudos
Message 6 of 12
(3,500 Views)
Henok,

The code as written with defaulted inputs from your front panel uses an on board clock of the 6562 to run the acquisition.  The hardware is setup to run at 48MHz using an onboard clock.  Since the onboard clock must be an integer divisor of 200MHz, this 48MHz will be coerced to 50MHz.  Your code then exports this 50MHz clock to the DDC CLK OUT terminal on the bulk connector.  Does your DUT use this clock to drive data?  If so, and you are using the onboard clock to sample the data, you are no longer sampling the data source synchronously. 

Though you are sampling at the same frequency, there is a delay between when the edge of the clock hits the acquisition hardware (clocked flip-flops) and in how long it takes to be output on the DDC CLK OUT pin, through cabling, to your DUT, and Data to get back to the 6562 (Round Trip Delay, RTD).  You may need to play with the Data Position attribute in order to meet those Setup and Hold time requirements. 

Also, when the code first executes, there is no clock being exported.  When the niHSDIO Read Waveform vi is called, the clock is started and data is acquired.  If you have a significant (ms) round trip delay then the DUT may not have presented data to the acquisition yet to be sampled.  This would be apparent in the first samples of the acquisition data.  You can alleviate this problem by first calling the niHSDIO Commit function which will setup the clocking, followed by the ReadWaveform vi.  This would provide additional timing between the two events.

However, since you mention STROBE in your previous threads, I assume that you are changing the value of "clock source" control to STROBE.  The 6562 does not allow exporting the STROBE signal.  If you look at the clocking diagrams in the help file:

Devices>>NI 656x>>Hardware Architecture>>Clocking

there is no path for STROBE to be routed to DDC CLK OUT unlike when using an on-board clock source.  You should receive an error if you try to export STROBE.

Also, where in your analysis is the data found to be corrupted?  Does your "Digital Waveform Graph" display the error?  Have you tried changing the niHSDIO Read Waveform to output a "Single Record: 1D U16"?
Message 7 of 12
(3,489 Views)

I understand that I can't export the clock when I am using strobe and I learned from your last posting that 48MHz frequency is coerced to 50MHZ when using on board sampling clock. That answered a lot of questions.

None the less, if there was a timing issue between when the sampling gets to the acquisition logic circuitry when it gets to my DUT and the data propagates to the PXI interface, then shouldn't I see the duty cycles trend closer to 50% as I observe the plots from the LSB to the MSB channels?

0 Kudos
Message 8 of 12
(3,474 Views)
If this were a timing issue then the violations would show up as "digital" duty cycle error.  That is, if the transition occurs too close to the edge, it may occur a sample early or a sample late (see attached drawing).  Referring to the drawing, if CH1 is violating the setup or hold time requirements then the apparent duty cycle could be +/-1 sample.  That is, CH1 would have a pulsewidth of 1 , 2, or 3 samples; CH2 would have a pulsewidth of 3, 4, or 5 samples, etc.  However, your MSB's (plot 3 and higher in your vi) do not exhibit this behavior, they seem to only have a single pulse rather than a +/-1 sample error.  You could try sampling on the falling edge rather than the rising edge to see if that has any effect .

Since the test panel acquired the same results as your test code I am disinclined to say it has anything to do with your coding.  To verify that the 6562 is working, can you remove all cabling and run the generation tab in the test panel followed by the acquisition tab?  The generation tab will let you output a count ("ramp") pattern on all channels of the device.  Select all of the channels then select a ramp pattern then hit the play button.  Make sure it is generating continuously.  Now, goto the acquistion tab, select all of the channels then hit the play button.  This procedure is doing a wrap back type test where each channel writes and reads to itself.  You should see the same count pattern in the digital graph of the acquisition tab that you generated from the generation tab.  Since the two operations are not synchronized, they will start at the same point but you should see the same pattern.

If that works out then there may be an issue with the connectivity or with the DUT's pattern generation.  Is it possible that you may be double driving the lines?  If you run another piece of code that is generating data from the 6562 then you may be corrupting the data coming into the device.  Try adding a "niHSDIO Tristate" vi into your code prior to the "Read Waveform".  This vi will turn off any output channels just in case they were left active in another test.

While your test is running, would it be possible to probe (differentially) on your STROBE, CH0, CH1 signals at the same time and attach a screenshot?

Message Edited by Ryan M on 12-30-2005 09:11 AM

0 Kudos
Message 9 of 12
(3,457 Views)

Ryan I've good news,

Al along it was my conncetion between the DUT and the 6562, there was a tremedous crosstalk between each differential pair. I was using single ended signaling and had the unused pair suspended. So any noise on the inactive link was causing the active one to switch state, hence preferring to stay high than low most of the time. To fix the problem, i am sending the compliment of each intended signal on the unused pairs. so the two signals are transitioning at the same time but when one goes high the other one is going low, that cancels out the contribuition of each signal to the other and vise versa.

Now that I have cleared that issue, is there an accessory cable I can buy that allow me to establish single ended communication channel. that is to say ribbon cables or parallel lines instead of twisted pairs?

Thanks for every thing.

0 Kudos
Message 10 of 12
(3,445 Views)