6536 synchronisation

[barkusmaximus]

Hi,

I have an application that has been in production and working for a couple of years that has suffered from a timing issue that now needs to be looked at more closely.

The production test is to follow a sequence of LEDs and press the corresponding switches on the device under test (DUT). All of this is performed using the DIO lines on the PCIe-6536 as both LED and Switch data are serially clocked in/out.

The test program drives the LEDs in a predefined sequence by changing the correct couple of data bits in a steam of clocked serial data (one for each half of DUT CLK_IN cycle). The data being clocked in is continously repeated in a loop at 1MHz 6536 on-board clock rate. The LED DIO line requirement is something like LED_CLK, LED_DATA, LED_LOAD, LED_OUTPUT_ENABLE (all outputs from the 6536). This bit is always OK and works fine with the correct LED selected from an enum being translated into the correct bits of the DATA_IN and correctly lit up.

The SWITCH DIO line requirements are SW_CLK, SW_LOAD (outputs from 6536) and SWDATA_OUT (input to 6536).

The problem comes where I have an additional DIO line on the 6536 which I use to trigger the PFI0 line (SW_DATA_TRIGGER) so that I can be sure to synchronise the SW_CLK with the SWDATA_OUT line.

What is supposed to happen is that the waveform pattern, generated using the NI Digital Waveform editor (6536 outputs), is continously repeated with the PFI input being re-triggered at the beginning of each loop iteration (from the additional 6536 output line in the waveform) and the SWDATA_OUT serial data being fed into a queue to be interpreted - synchronised with the CLK_IN line.

I am sure that there is more than one way of accomplishing the same thing but this does work and reliably bar the problem I will explain....... The problem is that every now and again (frequency can be once a day) the switch data being clocked out becomes unsynchronised - or at least in the way intended - and is out by half a clock cycle (one bit of the waveform).

My guess is that this is all due to the fact that its being run under windows and not a real-time system so that the waveform doesnt always trigger the PFI input immediately. The only way to get it working again when this happens is to reset the PC.

Could anyone cast their thoughts on this and how I could possibly rectify the issue without major re-work!?

I have attached a JPEG of the clocking data loop to give an idea of the core looping code and the looping waveform. (I realise that I am probably unnecessarily re-setting up the DIO each time but I have never got around to modifying this...so please overlook these minor things for now - the frequency is so fast that the delays here are unnoticable to the user. The main concern is the synchronisation between the 6536 line output SW_DATA_TRIGGER being physically fed back into the PFI input terminal......)

 

Many thanks in advance

Kyle

[Eric_L]

Hello,

I just wanted to confirm a couple aspects about your application.

SW_DATA_TRIGGER is being used to Trigger SW_CLK

What is connected to PFI0 (SW_DATA_TRIGGER), output from DUT?

SW_CLK is outputting to your DUT and SWDATA_OUT is inputting to the 6536 from the DUT.

Is SW_CLK being used to clock the DUT transmission of SWDATA_OUT to the 6536?

Eric

[barkusmaximus]

Hi Eric,

The SW_DATA_TRIGGER is one of the 32 digital lines on the 6536 which is hardwired to PFI0. I use this SW_DATA_TRIGGER in the waveform with the rest of the data IO to trigger the PFI0 (input) so that I determine where I start reading the SW_DATA_OUT coming out of the DUT.

SW_CLK is indeed coming out of the 6536 into the DUT and the SW_DATA_OUT  is coming out of the DUT into the 6536. The SW_CLK causes the SW_DATA to be clocked out of the DUT (ie one SW_DATA bit per two halves of the SW_CLK) .

Many thanks for your response

Kyle

[Eric_L]

Hello,

I assume that the signal going into PFI0 is an output from the DUT and is also tied to an input channel (DI on pin 31) on the 6536. It is unclear since the code does not show the pin configuration.

Currently you have a falling edge on PFI0 trigger a finite acquisition task. The DUT is clocked on the rising and falling edges. (6536 is clocked to twice the clock rate) Currently the trigger may not start the acquisition quick enough where you lose the first sample on the first falling edge.

This is my interpretation of the problem so far; correct me if I interpreted something incorrectly.

Eric

[barkusmaximus]

Hi Eric,

The 6536 PFI0 is fed from one of the 6536 digital lines (ie. its fed back into itself).

Thanks

Kyle