I am using TestStand 2017 with the TestStand Semiconductor Module. The goal of this post is for me to understand how to use the "Publish_Data.vi" from TSM to record (and yield to limits) the results of a PNA-X test for various parameters vs. frequency or power. For now, I am focusing on just S21 data for MAG and PHASE but in the future I will need to create software for NF, Power Compression, Intermod results, and S11/S22/S12.
I know that TestStand 2017 records its data in .STDF format, and I know that within the .STDF format (V4) itself the "Multiple-Result Parametric Record" is what I would most likely use to record the results of a single execution of a parametric test in the test program where that test returns multiple values e.g. a SPAR sweep over frequency.
However, looking at the "2D Array" choice for the "Publish_Data.vi" within TSM it looks like it only saves a single value for each parametric test for an array of channels and instruments for each channel, as opposed to an array of values for an array of channels and instruments of each channel.
My DUT is a MMIC with RF analog states controlled digitally via SPI. I am using NI-HSDIO for the digital control, NI-DCPower for DC/bias control, and a PNA-X using the Keysight LabVIEW Driver for RF Measurements. A pin map is definitely being used. There are multiple RF inputs and outputs to this MMIC and a special self-correcting switch is used that has its own driver and speaks both with the PNA-X and the computer itself. It's interesting stuff...
Here are some of my questions:
1) What does the STDF File Ordering look like when using the TSM "Publish_Data.VI"? An example of the file ordering I would use is in Page 70 of the STDF Specification V4 provided by Teredyne and attached to this post. I would like to know where the pin mapping records fit into the file ordering.
2) Is it possible with the current TSM VI's to save multiple values for each state defined by the channels for various instruments? E.g. Gain is set to one value, phase is set to another value, and an input/output switch is set to a specific path. I then measure S21 for each combination of gain/phase/path. How would this be recorded in the .STDF format that TSM uses?
3) How would I save, first, MAG, and then, PHASE, inside the STDF format for each S-PAR measurement if it all comes from a single channel? That would mean there are x8 arrays of data to save for a single digital state, and the states are a parametric combination of gain/phase/switch control all defined by channels defined in a pin map.
This gets more complicated as well but I'd figure I'd start with the basic thing I need to do which is just S21 mag/phase for now. There is also DC bias states (various VDD voltages to wiggle around +/- some %) that would be an outer loop while the digital control of the gain/phase/switch is looped inside of it. Temperature is even further out as an outer loop.
Perhaps I'll need to talk to an NI applications engineer on the phone.
I know how to control the digital, DC, and save individual results for testing things like the internal ADC/DAC, internal temperature sensor, and internal amplifiers for DC bias control on this MMIC, but when it comes to testing/storing/yielding to the results of a SPAR sweep using a PNA-X, I am at a loss. Will I have to just save this data in a .S2P file and do post-processing, and then convert to .STDF in the MPR record and add it into the STDF File Order appropriately? Sounds like a real pain.
I'll start with question 1 and try to draw it out similarly to the PDF:
Initial Global Data
Test Data with Wafer Settings Configured
For each wafer
Test Data without Wafer Settings Configured
For each part
Final Global Data
All of this mapped out, I have a couple of other answers for you:
Now I'd like to address the larger question of how to configure the tests. You may need to create a separate tests for the different configurations of MAG and PHASE. With that, you can set a custom Published Data Id for each test configuration, which you can then associate with the particular tests so that you can interpret the results.
Let me know your thoughts on this data. I'd like to know your thoughts/concerns to understand how well this fits with what you need.
Product Support Engineer
I appreciated the detailed response. Thank you for giving me the configuration of the STDF data format that TSM outputs as it is very helpful. Yes, I figured that the MPR record was not used by TSM. I am not sure if the DTR record and Publish Test ID method will work as wanted for our characterization because we will need to know the frequency, and whether it is magnitude or phase, associated with each test done. Another issue is there is a lot of other parametric information that needs to be saved with the frequency mag/phase information such as input power, amplifier gain settings inside the chip, signal path (there are multiple paths) etc. and the number of frequency points could be dynamic as well between tests. Because our frequency numbers could be dynamic throughout our testing, that would potentially require me to constantly change the TestStand tests. The key reason for this is that we are using this TestStand sequence and LabVIEW VI's to do both characterization and production test, all using the same NI test rack. The production test, I can certainly use the method you describe, but for characterization, it will be much more difficult due to having to save parametric results and knowing what state it was done in.
I've been talking with another software engineer coworker and we think we can probably do it using the "Value" in the Module tab where we set it such that it points to a variable in the "Locals --> ResultList" which would mean we point an output of the VI to a local variable in the Module tab. I've provided pictures showing the specific parts of TestStand I am referring to. I am still not sure how we will save the parametric results in those same variables, unless we pass them through each VI, or save an entire array of S2P information to a result in the result list, but it's a start. STDF formatting is not preferable for characterization, but is preferable for production results.
Very hard to explain over text, but luckily I have gotten into contact with an NI apps engineer who helps my company out and will be talking with him to figure this out!