PXI

cancel
Showing results for 
Search instead for 
Did you mean: 

Hardware Comparison not working properly with PXIe-6548

Solved!
Go to solution
Highlighted

Hi all,

 

Recently I developed an application that accesses memory of DUT using PXIe-6548. I was able to load an HWS vector file and obtain result as 'passed' or 'failed' based on the hardware comparison.

 

For some reasons, the PXI card writes into the address correctly, reads back correctly but does not show correct result for 'number of sample errors'. I can see the expected data on an oscilloscope. But at the same time the VI shows more than 0 sample errors and thus concludes that device did not read what was expected.

 

Please help in solving this issue.

 

0 Kudos
Message 1 of 12
(2,624 Views)
Highlighted

I am attaching an image of the block diagram. I think the VI is correct as I can see the expected samples being acquired on an oscilloscope. But the 'number of sample errors' shows more than 0 errors which is not expected.

 

The data position is set at falling edge of the clock.

 

Please help me guys...

 

 

0 Kudos
Message 2 of 12
(2,605 Views)
Highlighted

Hello,

 

Since you are getting the right data, but not seeing that there are no errors, this leads me to believe that the timing is slightly off.  If you try clocking on your rising edge, do you get different results?

Kyle A.
National Instruments
Senior Applications Engineer
0 Kudos
Message 3 of 12
(2,578 Views)
Highlighted

Hi Kyle,

 

I am sampling the gen data at falling edge of the sample clock. The DUT samples the data on rising edge of the same clock. While reading back, DUT provides the valid data on the immediate next falling edge for almost all frequencies from 1kHz to 10MHz. So, I generate address bits and other control bits in one sample and DUT provides data at the start of next immediate sample. The PXI card however, does not compare the same data in this sample but next sample. Why is that so?

 

Thank you for your help.

0 Kudos
Message 4 of 12
(2,549 Views)
Highlighted

Hi,

 

I looked over your code again, and I noticed you have not set up the Hardware Compare Mode that you wish to use.  This is an actual property node that must be set for both sessions.  You can find more information with pictures in this Developer Zone article over Hardware Compare.  To answer your question about the sampling done on the next sample, look at the section labeled 'Verifying Response Data' which shows how the Stimulus/Response works on the board.  For more information on the property you have to set, you can find more information on this help page for the Hardware Compare Mode property node. 

 

Also, the example Error Rate Test.vi under Example Finder shows example code for the hardware compare feature on some HSDIO boards.  This can be found under Hardware Input and Output » Modular Instruments » NI-HSDIO » Measurements » Error Rate Test.vi.  This will give you a lot of information on setting this up correctly.

 

 

Kyle A.
National Instruments
Senior Applications Engineer
0 Kudos
Message 5 of 12
(2,541 Views)
Highlighted

Hi, viaheaven.

 

Is your expected response data always one sample off from what you expect?  If so, it sounds like you have an off-by-one sample error triggering your acquisition session.  You can read back the acquired data from a Hardware Compare session and check.

 

Can you give that a try and see if you're getting back expected data but are triggering wrong?

 

Thanks,

 

Keith Shapiro

National Instruments R&D

0 Kudos
Message 6 of 12
(2,538 Views)
Highlighted

Hey Keith,

Good to hear from you.

 

I checked the response data as you suggested. I took multiple observations and every time got one-sample-off-data. I am triggering the acquisition session on rising edge of PFI 1 and sampling at falling edge of sample clock.

 

 

0 Kudos
Message 7 of 12
(2,536 Views)
Highlighted

That's promising.  Are you triggering too early or too late?

 

My guess is you're triggering early -- you're getting a sample of garbage data before you get all of your good data.  If that's true, we just need to delay the start trigger to the acquisition.  The easiest way to do this at this point is to use a marker.  If you're triggering a sample early, put a marker on sample 1, and export that to PFI1 instead of data active.

 

If you're triggering too late -- you're missing your first sample of data, then you need to change the start trigger position for acquisition to the falling edge.

 

One of those should clear up the issue.  Give it a try and let me know.

 

-Keith

0 Kudos
Message 8 of 12
(2,532 Views)
Highlighted

Interesting!

 

I am triggering early. But I never realized it might be too early. I will keep you posted.

 

Thanks!

0 Kudos
Message 9 of 12
(2,530 Views)
Highlighted

hi Keith,

 

I tried to export Marker on PFI 1. Is that what you suggested me to do? I coud not find a way to place a marker on sample 1. Please help me understand this.

 

Thanks for your time.

0 Kudos
Message 10 of 12
(2,497 Views)