Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

Errors introduced using ConfigureSampleClock

Solved!
Go to solution

 

I have a small PXI system with 3x PXI-6552 HSDIO cards plus 1x PXI-6652 Timing card clocking them over the PXI-STAR interface.
I wanted to find out how low of frequency I could run my PASSING HWC vectors to see when they first start failing.  (Normal test frequency is 32MHz DUT clock created with 64MHz vectors 10101010 pattern.)  The problem I am having is when I set clock frequency too low (54MHz) and yield HWC FAILURES, then vectors will no longer PASS when I set the vector frequency back to 64MHz.
Here is my software revisions:
 NI-HSDIO 1.6
 NI-HWS 1.4.6
 NI-Sync 3.1
 NI-TClk 1.7
(I have lots of other software, but these seemed the relevant ones.)
I am using DLL functions called from Python.  Here is some of my code that shows what DLL functions I call when I change vector frequency:
def SystemTimingSettingsUpload(self, DRC_freq, Gen1_del, Gen2_del, Gen3_del, Acq1_del, Acq2_del) :
    """Updates HSDIO system frequency and digital timing settings based on passed values"""

    self.SYS_DDC_freq = 2.0 * DRC_freq

    DLL_DIO.niHSDIO_ConfigureDataPosition(self.SYS_DIO1_gen_session, c_char_p('0'), self.NI_NIHSDIO_VAL_SAMPLE_CLOCK_RISING_EDGE)
    DLL_DIO.niHSDIO_ConfigureDataPosition(self.SYS_DIO2_gen_session, c_char_p('0,1'), self.NI_NIHSDIO_VAL_SAMPLE_CLOCK_RISING_EDGE)
    DLL_DIO.niHSDIO_ConfigureDataPosition(self.SYS_DIO3_gen_session, c_char_p('0-18'), self.NI_NIHSDIO_VAL_SAMPLE_CLOCK_RISING_EDGE)
    DLL_DIO.niHSDIO_ConfigureDataPosition(self.SYS_DIO1_acq_session, c_char_p('1-14,19'), self.NI_NIHSDIO_VAL_SAMPLE_CLOCK_RISING_EDGE)
    DLL_DIO.niHSDIO_ConfigureDataPosition(self.SYS_DIO2_acq_session, c_char_p('0-19'), self.NI_NIHSDIO_VAL_SAMPLE_CLOCK_RISING_EDGE)

    DLL_Sync.niSync_SetAttributeViReal64(self.SYS_Sync_session, self.NI_VI_NULL, self.NI_NISYNC_ATTR_DDS_FREQ, c_double(self.SYS_DDC_freq))
    DLL_DIO.niHSDIO_ConfigureSampleClock(self.SYS_DIO1_gen_session, c_char_p('PXI_STAR'), c_double(self.SYS_DDC_freq))
    DLL_DIO.niHSDIO_ConfigureSampleClock(self.SYS_DIO2_gen_session, c_char_p('PXI_STAR'), c_double(self.SYS_DDC_freq))
    DLL_DIO.niHSDIO_ConfigureSampleClock(self.SYS_DIO3_gen_session, c_char_p('PXI_STAR'), c_double(self.SYS_DDC_freq))
    DLL_DIO.niHSDIO_ConfigureSampleClock(self.SYS_DIO1_acq_session, c_char_p('PXI_STAR'), c_double(self.SYS_DDC_freq))
    DLL_DIO.niHSDIO_ConfigureSampleClock(self.SYS_DIO2_acq_session, c_char_p('PXI_STAR'), c_double(self.SYS_DDC_freq))
        
    DLL_DIO.niHSDIO_ConfigureDataPosition(self.SYS_DIO1_gen_session, c_char_p('0'), self.NI_NIHSDIO_VAL_DELAY_FROM_SAMPLE_CLOCK_RISING_EDGE)
    DLL_DIO.niHSDIO_ConfigureDataPositionDelay(self.SYS_DIO1_gen_session, c_char_p('0'), c_double(Gen1_del))
    DLL_DIO.niHSDIO_ConfigureDataPosition(self.SYS_DIO2_gen_session, c_char_p('0,1'), self.NI_NIHSDIO_VAL_DELAY_FROM_SAMPLE_CLOCK_RISING_EDGE)
    DLL_DIO.niHSDIO_ConfigureDataPositionDelay(self.SYS_DIO2_gen_session, c_char_p('0,1'), c_double(Gen2_del))
    DLL_DIO.niHSDIO_ConfigureDataPosition(self.SYS_DIO3_gen_session, c_char_p('0-18'), self.NI_NIHSDIO_VAL_DELAY_FROM_SAMPLE_CLOCK_RISING_EDGE)
    DLL_DIO.niHSDIO_ConfigureDataPositionDelay(self.SYS_DIO3_gen_session, c_char_p('0-18'), c_double(Gen3_del))
    DLL_DIO.niHSDIO_ConfigureDataPosition(self.SYS_DIO1_acq_session, c_char_p('1-14,19'), self.NI_NIHSDIO_VAL_DELAY_FROM_SAMPLE_CLOCK_RISING_EDGE)
    DLL_DIO.niHSDIO_ConfigureDataPositionDelay(self.SYS_DIO1_acq_session, c_char_p('1-14,19'), c_double(Acq1_del))
    DLL_DIO.niHSDIO_ConfigureDataPosition(self.SYS_DIO2_acq_session, c_char_p('0-19'), self.NI_NIHSDIO_VAL_DELAY_FROM_SAMPLE_CLOCK_RISING_EDGE)
    DLL_DIO.niHSDIO_ConfigureDataPositionDelay(self.SYS_DIO2_acq_session, c_char_p('0-19'), c_double(Acq2_del))


def TestPatterns(self)
    DLL_DIO.niHSDIO_Initiate(self.SYS_DIO1_acq_session)
    DLL_DIO.niHSDIO_Initiate(self.SYS_DIO2_acq_session)
    DLL_TClk.niTClk_Initiate(c_ulong(3), self.SYS_DIO_session_arr)

    # digital vectors should now be running...

    DLL_DIO.niHSDIO_WaitUntilDone(self.SYS_DIO1_acq_session, c_long(20000))
    DLL_DIO.niHSDIO_WaitUntilDone(self.SYS_DIO2_acq_session, c_long(20000))

    DLL_DIO.niHSDIO_GetAttributeViInt32(self.SYS_DIO1_acq_session, self.NI_VI_NULL, self.NI_NIHSDIO_ATTR_HWC_NUM_SAMPLE_ERRORS, byref(error_count))
    DLL_DIO.niHSDIO_GetAttributeViReal64(self.SYS_DIO1_acq_session, self.NI_VI_NULL, self.NI_NIHSDIO_ATTR_HWC_SAMPLES_COMPARED, byref(num_samp))
    DLL_DIO.niHSDIO_GetAttributeViInt32(self.SYS_DIO1_acq_session, self.NI_VI_NULL, self.NI_NIHSDIO_ATTR_HWC_SAMPLE_ERROR_BACKLOG, byref(samp_err_backlog))
    print 'Total Samples Compared = ', num_samp.value
    print 'Total Errors Found = ', error_count.value
    print 'Sample Error Backlog = ', samp_err_backlog.value


# calling above functions:

    self.SystemTimingSettingsUpload(32.0E6, 0.52, 0.48, 0.28, 0.8, 0.1)
    self.TestPatterns() => PASS

    self.SystemTimingSettingsUpload(31.0E6, 0.52, 0.48, 0.28, 0.8, 0.1)
    self.TestPatterns() => PASS

    self.SystemTimingSettingsUpload(30.0E6, 0.52, 0.48, 0.28, 0.8, 0.1)
    self.TestPatterns() => PASS

    self.SystemTimingSettingsUpload(29.0E6, 0.52, 0.48, 0.28, 0.8, 0.1)
    self.TestPatterns() => PASS

    self.SystemTimingSettingsUpload(28.0E6, 0.52, 0.48, 0.28, 0.8, 0.1)
    self.TestPatterns() => PASS

    self.SystemTimingSettingsUpload(27.0E6, 0.52, 0.48, 0.28, 0.8, 0.1)
    self.TestPatterns() => FAIL  (OK, I know where my lower limit is)

    self.SystemTimingSettingsUpload(32.0E6, 0.52, 0.48, 0.28, 0.8, 0.1)
    self.TestPatterns() => FAIL  (but this passed in step #1 above...why does it fail now?)

 

What conditions could change in the cards each time that I call my "SystemTimingSettingsUpload()" method that do not get changed back when going from a lower clock speed to a higher clock speed?  Could it have something to do with the pins that I am not delaying?
PS: 
I wanted to verify frequency and delay settings, but when I request the delay values, the DLL issues a windows exception:
    DLL_DIO.niHSDIO_GetAttributeViReal64(self.SYS_DIO1_gen_session, self.NI_VI_NULL, self.NI_NIHSDIO_ATTR_SAMPLE_CLOCK_RATE, byref(temp_val))    <= This works
    DLL_DIO.niHSDIO_GetAttributeViReal64(self.SYS_DIO1_acq_session, self.NI_VI_NULL, self.NI_NIHSDIO_ATTR_DATA_POSITION_DELAY, byref(temp_val))  <= This bombs
So I think there must be a bug in the DLLs for my version HSDIO for the DATA_POSITION_DELAY attribute. Here are the values assigned to those constants:
    self.NI_NIHSDIO_ATTR_SAMPLE_CLOCK_RATE = c_ulong(1150014)
    self.NI_NIHSDIO_ATTR_DATA_POSITION = c_ulong(1150056)
    self.NI_NIHSDIO_ATTR_DATA_POSITION_DELAY = c_ulong(1150057)
Thank you,
Brian

 

0 Kudos
Message 1 of 12
(4,384 Views)

Hey Brian,

 

Have you tried resetting the board in between the one that fails and the one that is supposed to pass? Have you aborted the session and restarted the session between each change of the rate? Also, which sample errors are you fetching? Do you fetch all of the sample errors from the sample error backlog before going to the next rate? Could you be fetching some of the old sample errors that are still in the error fifo? Try some of these things out to pin point down what might be causing the board not to get back to the state you want it to.

 

Also, I am not sure how you have your signals connected and where your triggers are coming from, etc. But it sounds like you are doing a system synchronous type of application where the clock is coming from one source and the data is not necessarily aligned with the clock when you sample the data. Is this why you are getting sample errors at the lower frequencies? Are you expecting to get errors at the lower frequencies, or are you trying to eliminate those errors as well? Are you generating out one some boards, and acquiring on those same boards, or other boards? It looks like you have 22 data generation lines, and 35 data acquisition lines, but I am not sure how these are connected to your dut or each other, etc. One thing that I would recommend if you are doing a source synchronous type of application is to route out the generation clock (source still is PXI Star) out to the DDC Clk Out to whatever you are connecting it to, then use Strobe as the clock input on the Acq sessions instead of PXI Star, so that the data and clock are now in synch. Check out the following doc that explains this. Or if you cannot route the clock out and back in on strobe, you can use the internal route delay of the 655x to account for and possibly eliminate the Round Trip Delay of the data. Here's a little video that discusses all of this as well.

 

Hope this helps. Let us know if you have further questions or concerns. If you do, it would be good to know more about what is connected to what, and where the signals are going, to help understand what you are trying to do, and what signals we can recommend you connect to best do what you want. Thanks, and have a great day.

 

Regards,

DJ L.

0 Kudos
Message 2 of 12
(4,381 Views)

Thanks for replying D.J.

 

Most of the digital logic is synchronous. My DUTs have sample & holds built in that will stop working at certain clock speeds, but most likely the test vectors stop PASSING at low clock speeds due to the location that I have placed the strobes no longer being valid, but I currently don't have any adjustments to accomodate that.  (I am using PFI lines to START acquisition sessions based on SOME of the round-trip-delay, but the PFI routes don't travel the full distance that most of the DUT signals do, and they don't account for prop. delays within the DUTs.)

 

Regarding card "resets": 

I never call either of the "RESET" functions normally.  (I have an "executive" that allows me to test multiple DUTs during a session.)  When I exit a session (and CLOSE the cards), then start my session again, they work correctly at 32MHz again.  So CLOSE and OPEN clear the problem.

 

Regarding "sample error backlog":

Ah!  This is probably it!  I assumed when I issue the "niHSDIO_Initiate(aqc_session)" function, that this would blow away any previously stored samples and previously captured error results.  Sounds like that is not the case.  I will run a trial on this now... I'll report more later.

 

Thank you,

Brian

 

0 Kudos
Message 3 of 12
(4,375 Views)

Hey Brian,

 

Actually, the Initiate function should clear out the error FIFO. Are you doing a Stimulous and Response HWC, or just a Response Only? Is there a chance that your dut gets in a bad state after it fails, and then the next time you write to it the data is off? Also, you can check the data that does get returned on the fail after the first fail, and see what the dut is sending. Also, how are you handling any driver errors? Do you check to see if you are getting other errors that might make the test code fail, like a clocking error that still might be there from the first fail? If there is a driver error that is hanging around, then the opening and closing the session will clear that out, but if you don't then when you initiate again that error would still be there. So make sure there are not driver errors occurring, and your code is failing just because the data is not matching up. As a test, you could also try doing a software compare in your code somewhere that will see if you are matching up with the HW Compare results. All things you can try to troubleshoot what is causing this issue. Keep us updated on any progress. Thanks.

 

Regards,

DJ L.

0 Kudos
Message 4 of 12
(4,370 Views)

The issue is definitely not associated with error backlog.

 

I have a working application using all test vectors at 64MHz.  This application has been in place for over a year.

 

I tried to write a "Continuity" test using the programmable drivers and comparators of my 6552 cards.  The problem is, the diodes I want to measure for continuity are connected to ground (so I need to drive and compare down to -1V or so to measure them).  The 6552 would not let me program these negative voltages at a vector speed of 64MHz.  So, I want to change the vector speed down to something smaller during the continuity test (something that will allow me to program -1V driver voltages) and then switch it back up to 64MHz for all my other tests that are already working there.

 

I created the "SystemTimingSettingsUpload()" function so that I could easily move the 6652 and 6552 clock speeds back and forth.

 

Calling my function and passing a clock speed of 32MHz (which runs the 6652 at 64MHz) works fine.  I can call this procedure, passing 32MHz at any point in my program and it does not upset the existing PASSING code.  I added a 10x loop at one section in my code, calling "SystemTimingSettingsUpload(32MHz)" and then testing a set of working vectors and it passed every time.

 

If I call this function at any time with a number smaller than 27MHz or so (54MHz 6652 speed), and then immediately call it again with 32MHz, nothing will pass.  Lots of HWC errors and the captured records make no sense.  So:

 

  SystemTimingSettingsUpload(20MHz, ...)  # try to set the clocks slow 

  SystemTimingSettingsUpload(32MHz, ...)  # immediately set the DUT clock BACK to known-good 32MHz

  Now NONE of my patterns pass.

 

Perhaps my strobe delays are getting railed or moved incorrectly when I pass the low clock frequency?  I tried querying the cards for the strobe delay settings, but the DLL gave me an exception.  I _CAN_ request the card clock frequency and this responds correctly without crashing my code, but it won't give me the strobe delays.  Perhaps the header file that I pulled these values from were in error for DATA_POSITION_DELAY?

 

 

self.NI_NIHSDIO_ATTR_SAMPLE_CLOCK_RATE = c_ulong(1150014)
self.NI_NIHSDIO_ATTR_DATA_POSITION = c_ulong(1150056)
self.NI_NIHSDIO_ATTR_DATA_POSITION_DELAY = c_ulong(1150057)

 

0 Kudos
Message 5 of 12
(4,368 Views)

I am pretty sure there is no pent-up error, as my test program continues to run and execute lots of scripts and tests, pulling lots of records out of the cards (all of it bad data).  Nevertheless I called niHSDIO_GetError() on all 3 Generation and both Acquisition sessions after each call to my set timing procedure and it never once replied with any text at all.

 

(Usually I call this GetError procedure only in response to a WindowsException...)

 

Thanks for helping me think about this problem D.J.

I have to get off the system so manufacturing can use it again 😞

 

 

0 Kudos
Message 6 of 12
(4,363 Views)

Hey Brian,

 

Regarding your measurement of your diodes down to -1V, here are the specs of the 655x which aligns with what you are seeing:

Generation voltage range restrictions (into 1 MOhm):

–0.5 V to 5.5 V (up to 50 MHz clock rate)

–2.0 V to 3.7 V (up to 50 MHz clock rate)

–0.5 V to 3.7 V (50 to 100 MHz clock rate; NI 6552 only)

Acquisition voltage range:

–2.0 V to 5.5 V

 

Now when you say you go from fail on 27MHz (54 MHz coming in on PXI_Star), and then go to 32MHz (64 MHZ in), nothing passes, and you get lots of HWC errors and the captured data (records) make no sense, does it look like the data is off by 1 sample or maybe a couple of samples? Or does the acquired data just random?

 

Also, when you change the clock rate, have you tried resetting the 6652 and not the 6552 to see if that has any affect, or does it still fail when doing that. With this test we can try to see if the 6652 clock has any affect on the system.

 

As for the Data Position and Data Position Delay attributes, you should be able to read from these values. Are you using some kind of wrapper around the functions? If so, maybe check to see if the wrapper is using the correct value in its calls.

 

What version of the HSDIO driver are you using? But before updating the driver, let's see if we can narrow down the issue with more troubleshooting.

 

Finally, you mention that you are taking in a 64 MHz clock but then creating a clock using a data line, which is your 32 MHz clock from the 6552. I was just curious why you are using a data line to generate the clock and not just routing the sample clock out to the DDC Clk Out? Is this so that you can use the Data Delay feature, which requires a clock at or above 25 MHz? Again, just curious.

 

Regards,

DJ L.

0 Kudos
Message 7 of 12
(4,362 Views)

D.J.

 

Thanks again for your time.

 

I cannot find a pattern in the bad captured data.  I really don't think it is a single cycle shift, unless perhaps the data is shifted to the point where it is transitioning during strobe...(because it looks totally bogus.)  

 

Here is my software revisions: 

NI-HSDIO 1.6 

NI-HWS 1.4.6 

NI-Sync 3.1 

NI-TClk 1.7

(I have lots of other software, but these seemed the relevant ones.)

 

Also note that I have tried to update these but there are compatibility problems with some very old legacy code that I link to (for my test executive environment) that uses ancient versions of NIDAQ and 488.2.  I have a support contract and we documented the compatibility issues in a call Reference# 7278393.  The newest versions of NI-488.2, NI-HSDIO, and NI-DCPower issue a "Microsoft Visual C++ run-time error to occur (R6030 - CRT not initialized) as soon as I link in the old software.

 

My DUT is a multi-chip mixed-signal (ADC) module that requires 2 different clocks (one 1/2 speed of the other), with two sets of data-busses running (one 1/2 speed of the other), and I have a high speed DAC on my test fixture with its own clock and data-bus.  In order to minimize clock and data noise during the DUTs ADC sampling phase, I am using DATA DELAY to manipulate all the edges to very specific locations within the DUT's clock period.  In the end I have:

 3x 6552 cards

 I am using all 60 channels

 The majority of channels on each card should have data aligned with RISING EDGE of the internal system clock.

 I have used an O-scope to position specific drive channels (at a 64MHz system clock) on each card to very specific locations:

 Card #1, pin 0 is driving the DUT's data-bus clock

 Card #2, pins 0,1 are driving the DUT's differential ADC clock

 Card #3, pins 0-18 are driving my fixture's high speed DAC data and clock

 All the other pins on all 3 cards should be driving data at the same time -- with the rising edge of the internal system clock.

 

I have not yet tried a reset function on the 6652 to solve this problem.  Time for more disclosure:

 

I finished writing a NEW application for another DUT on my 6552 system.  That particular application does not need the DATA DELAY positioning to only apply to a few pins per card.  I am using DATA DELAY, but on all 20 channels per card.  During the development of this new application I created my Continuity test for diodes to ground (tested down to -1V).  That application runs different DUT patterns at different speeds (12MHz, 16MHz, and 46MHz).  I created my "SystemTimingSettingsUpload()" function as part of that application... and everything works great for that application.  The continuity test works and all my DUT patterns work.

 

When I tried to port the Continuity test into my old application, it complained that it could not set the drive levels down to -1V unless I dropped the system clock down.

 

When I tried to port the SystemTimingSettingsUpload function into my old application it creates the problem I am describing.

 

The key differences:

The new application only goes up to 46MHz 6652 rate (vs. 64MHz on the non-working application)

The new application applies DATA DELAY to all 20 pins on each card (vs. only a few pins on each card on the non-working app.)

 

Please note that I can use SystemTimingSettingsUpload many times in my old application with no problems, as long as the system clock rate stays above 54MHz or so... As soon as I call it with a system clock frequency of 54MHz or lower, SOMETHING gets changed that doesn't get changed back when I call it again with the correct higher system clock frequency.

 

It took me an hour to type this and it still reads confusing to me... I think I should call in and start a support request?

 

 

0 Kudos
Message 8 of 12
(4,351 Views)

With regard to the Windows Exception that I get trying to read the DELAY values, I am using the following include file to specify the address of those attributes:  C:\Program Files\IVI Foundation\IVI\Include\niHSDIO.h

 

I am using MANY of the attribute addresses from within that file.  All of them are working so far, except DATA_POSITION_DELAY.

 

For example, this attribute I am using with no problems:

#define NIHSDIO_ATTR_SAMPLE_CLOCK_RATE                       (IVI_SPECIFIC_PUBLIC_ATTR_BASE + 14L)   /* ViReal64 */

 

In my code it looks like this:

self.NI_NIHSDIO_ATTR_SAMPLE_CLOCK_RATE = c_ulong(1150014)

 

But this attribute does not work:

#define NIHSDIO_ATTR_DATA_POSITION_DELAY (IVI_SPECIFIC_PUBLIC_ATTR_BASE + 57L) /* ViReal64 */

 

In my code it looks like this:

self.NI_NIHSDIO_ATTR_DATA_POSITION_DELAY = c_ulong(1150057)

 

 

0 Kudos
Message 9 of 12
(4,349 Views)

Hey Brian,

 

Sorry for the delay in getting back to you. So I have an update on one of the issues that you are running into, with regards to the following function call you are making:

DLL_DIO.niHSDIO_GetAttributeViReal64(self.SYS_DIO​1_acq_session, self.NI_VI_NULL, self.NI_NIHSDIO_ATTR_DATA_POSITION_DELAY, byref(temp_val))

 

The reason that this is erroring out on you is because this is a channel based attribute, and therefore you need to pass which channels you would like to get the delay value on. Currently you are passing a Null value into the channel list, where you need to pass your channel list into that parameter of the function. Here is the help page on the GetAttribute function, and here is the text on the channel parameter:

"If the attribute is channel or instance based, this parameter specifies the name of the channel or instance on which to set the value of the attribute; if the attribute is not channel or instance based, pass VI_NULL or an empty string."

The reason those other attributes were working is because they are not channel or instance based, and they can accept Null in that part of the GetAttribute function.

 

Still looking into your other issue of why the board gets into a weird state when using the lower frequencies and erroring, then going to a higher frequency. Do you have any updates on other troubleshooting that you have done with the clock issue?

 

Regards,
DJ L.

0 Kudos
Message 10 of 12
(4,273 Views)