digital comparison

[Dtayebi]

The issue I would like to ask the group advice on is concerning the Digital Waveform Compare for a large number of samples (1million).  I am using 4 HSDIO cards for simultaneous generation/acquisition it requires using the digital compare function (found palette: programming/waveform/digital wfm/comparison) 4 separate times (once for each card, only one card supports hardware compare).

I have noticed it takes about 7-9seconds to compare gen/acq data on one card, taking anywhere from 25-30seconds to complete all 4. For single runs this is not to bad but for a lot of our applications we need to run shmoo plots consisting of hundreds/thousands of ‘points’ meaning run-time is increased to hours in most cases.

Does anyone have any knowledge or experience with this function and optimizing it for large sample numbers?

I have attached a simple VI that compares 1M samples 4 times. It is important to note that Generation data will have X,H,L,Z states included in the expected response so using u32 compare will not work.

If any additional information is needed I will gladly provide it!

I thank you for your time!

-Daroosh

[Dtayebi]

Is it wrong to up something here?

[Marcus_M]

Hello,

It is not wrong to upload your example code to this site, which is encouraged so that other developers can see what you are working with.  I reviewed the example that you provided.  An area that I might suggest improvement in is the area in which you converted your data.  You convert your data from a U32 to a digital waveform.  In doing so you are requiring the program to remember more "features" of the data such as timing information.  If you convert your data in a for loop to binary using a number to Boolean array function your data should be in a smaller, more compact and less memory dependent state allowing for your program to run quicker.  

Regards,

Marcus 

[Dtayebi]

EDIT: The waveforms I am comparing have states such as X,H,L within them (for generation/expected response) and I do not think I can use boolean as the values are not simply 1 or 0. (It is not shown in the example for ease of understanding the issue).

I appreciate the advice. (I had previously used a simple '=' sign to compare boolean however I had the same issue with the other states.

I wish there was a way I could export the digital table to an array of binary values (if my table was: XX0011 then the array would be: 5,5,0,0,1,1) and then simply loop through, as this would enable me to pinpoint differences and their locations without using the diff table from the comparison vi (which if turned on takes even longer to complete)!! However this also requires a lot of looping and case structures and hence requires time.

-Daroosh

[Kyle_A.]

Hello Daroosh,

Which HSDIO devices are you using for this application?  Using software comparison to determine errors instead of hardware comparison will always be a slower process.  You mention one of your boards can do hardware comparison, but not all of them.  

For those devices which cannot, waveform comparison will be slow and processor intensive.  Making use of parallel programming and producer/consumer code architecture will increase processing speeds on the machine.  But inevitably, faster processing will be the biggest component to increase test speeds for this case.  

If you were able to do a custom comparison with the binary instead of using the VI provided, you may see a speed increase.  Having software determine how to handle the 6 states that come with comparison will take time, but if you can somehow determine your own masking scheme on the input data vs the compare data in binary form, then you wouldn't need the secondary conversion in your VI.  For example, using XOR on your response/compare bits to get 0 for match, and 1 for no match, and then having a third bit to determine if you care or dont care.

So say you expect 1 and get 0, but don't care, you see XOR results in a 1, but you have a care (1) or don't care (0) bit array along side it to determine if it counts as an error or not.  If 0, don't include the error into the final result.  If 1, include the error to an incremental count, increment array index, store array index as error location.  Something like that.

Anyways, I have not tested this or seen this in application, but I offer it as another way to do comparisons where software processing can be intensive and performing conversions and parsing through multiple states can be time consuming.  I hope your application ends up well, best of luck reducing your test times.

[Dtayebi]

Much appreciated for your feedback. I am currently using one PXI6547 (has hardware compare) and three PXI6541's.

I have tried to implement the hardware compare feature however I was getting all kinds of resource errors with TCLK and other things, I was in rather a rush to have something functional I decided to come back and look at it (seems like a good time!). 

I had narrowed the time taken to the 'get digital value' VI within the comparison VI. This conversion seems to be the bottle neck.

My Generation and Expected response waveform is saved as a binary file (parsed from vector file) and I am Acquiring the data as u32. As you suggested I am thinking it best to create a vi that compares the binary and use a simple case structure to either 'skip' over the don't cares or to actually compare. This will take some time, I do not think there is a way around it however as you have stated it should reduce processor time if done correctly.

I think the benefit is I will also have more control, keeping track of channels as well as cycle numbers of errors and then using that information to highlight the graph or output a report with more than just pass/fail, no. of fails and the diff table (you still have to cycle through the diff table to get the locations of error).

I will build my own comparison VI and let you know how it comes along 🙂

And thank you for the kind words, the tester I am building is moving along nicely and many features have been implemented, LabView and the combination of NI chassis and HSDIO cards and the SMU/DCPS cards makes for a very solid tester with very dynamic capabilities for development.

-Daroosh Tayebi