Tektronix Technical Forums are maintained by community involvement. Feel free to post questions or respond to questions by other members. Should you require a time-sensitive answer, please contact your local Tektronix support center here.

"Psuedo real-time" data returning for PMU???

Post Reply
dhabersa
Posts: 33
Joined: November 3rd, 2010, 12:17 pm
Country: United States

"Psuedo real-time" data returning for PMU???

Post by dhabersa » October 15th, 2015, 8:29 am

The 4200-SCS Reference manual notes how one can read data into KITE by using either pulse_measrt or through code that queries pulse_fetch for new data. The Remarks for the pulse_measrt function state
Use this function to return and display test data in pseudo real-time. As measurements are performed, the data is automatically placed in the KITE Sheet tab.
This makes sense, but it doesn't match with what I typically see in practice. There seems to be a large discrepancy between when a measurement is actually performed and when the data is finally made available. There must be some sort of algorithm that can describe the behavior, right?

For example, I'll use SegArb to send a repeating square wave, fixed frequency signal to a DUT (switching a MOSFET on/off in this case). I can form the SegArb waveform such that it samples only on some of the pulses when the device is switched on. It's a long test, so I make these exponentially spaced (e.g., measure on pulse #1, 3, 10, 30, 100, 300, etc.). The vast majority of my data points will be measured very early in the sequence, so presumably it should be feeding me data quickly at first and then slowing down as time progresses. However, whenever I do this type of sequence what happens is there is no data made available until basically the very end of the test! This is becoming a problem because we are trying to run tests that can take many days to complete; with no data output in the interim, it's impossible to monitor the device status and I can't abort the test early because all of the data that hasn't been sent to the KITE sheet gets lost.

I'm using something like the code block below to fetch data during the test and post it to KITE. I've tried switching between this and using pulse_measrt, so far I haven't found much difference between the two. Any ideas on what I can do at this point?

Code: Select all

pulse_exec(PULSE_MODE_SIMPLE);
next_data = 0;
status=1;
while (status)
{
	Sleep(1000);
	status = pulse_exec_status(&t);
	
	// Fetch any new data
	pulse_fetch(InstId, 1, next_data, data_length, VMeasCh1 + next_data, IMeasCh1 + next_data, Time + next_data, StatusCh1 + next_data);
	
	// Find the last data returned
	for (i = next_data; i < data_length; i++)
		// Stop if channel has zero status
		if (StatusCh1[i] == 0) break;
		
	// New data received; post to worksheet and move next_data counter forward
	if (i > next_data) {
		PostDataDoubleBuffer("Time", Time + next_data, i-next_data);
		PostDataDoubleBuffer("IMeasCh1", IMeasCh1 + next_data, i-next_data);
		PostDataDoubleBuffer("VMeasCh1", VMeasCh1 + next_data, i-next_data);
		PostDataDoubleBuffer("StatusCh1", StatusCh1 + next_data, i-next_data);
		next_data = i;
	}
}
Thanks,
Dan

dhabersa
Posts: 33
Joined: November 3rd, 2010, 12:17 pm
Country: United States

Re: "Psuedo real-time" data returning for PMU???

Post by dhabersa » November 3rd, 2015, 10:18 am

No takers? Okay, here I will give a specific example that can be run using the built-in KITE libraries and highlights the trouble I am trying to address.

This zip file contains the files generated by KITE when I created a UTM test that runs the module PMU_SegArb_ExampleFull in library PMU_examples_ulib.
tests.zip
KITE test files (segarb.rtf, segarb.ktm, segarb.kta, segarb#1.ktp, segarb#1.ktm, and segarb#1.kdf)
(464.93 KiB) Downloaded 984 times
The UTM is configured to output a 10kHz switching waveform from -10V to +25V on PMU1 CH1 and a constant bias on PMU1 CH2 (e.g., for testing gate switching of a MOSFET) for nearly 10 seconds. Sometimes, waveform measurements of both channels are performed during the transition segments between pulse lo and hi. I've set a maximum # of data points to 10,000, and the graph below shows where each data point falls in time. This graph was generated from the actual data (by plotting the returned Time values against a data point index).
data versus time.jpg
data versus time.jpg (97.49 KiB) Viewed 8118 times
So, we can see that more than half of the data points are measured within the first second.

I ran the UTM and timed when the first data points showed up in KITE. This code uses pulse_fetch to read the data during the test. My first data shows up in KITE at the 10 second mark, right when the waveform has finished. The system then takes another 17 seconds to completely read all of the data. The entire sequence (including both waveform output and data collection) takes a total of 27 seconds to complete on my 4200.

Why does no data return until after the entire waveform has been output?
This seems antithetical to the very notion of returning data in "pseudo real-time" as the reference manual claims can be done...

NWeddeler
Posts: 3
Joined: January 11th, 2019, 12:19 am
Country: Germany

Re: "Psuedo real-time" data returning for PMU???

Post by NWeddeler » January 16th, 2019, 6:28 am

Hi,
I am facing the same problem. Despite using pulse_measrt() there is no update of measpoint until the very end of the test. Did you find a solution?

Regards,
Nicki

dhabersa
Posts: 33
Joined: November 3rd, 2010, 12:17 pm
Country: United States

Re: "Psuedo real-time" data returning for PMU???

Post by dhabersa » January 16th, 2019, 6:41 am

Never did find a solution to this, apart from learning to be patient. I haven't even gained further insight as to what causes some test sequences to return data sooner than others.

¯\_(ツ)_/¯

NWeddeler
Posts: 3
Joined: January 11th, 2019, 12:19 am
Country: Germany

Re: "Psuedo real-time" data returning for PMU???

Post by NWeddeler » January 16th, 2019, 7:53 am

First of all, thanks for the fast reply!

I was just wondering, why my old code did this properly which I had to change, because I learned that seg_arg_sequence allows only segments which are shorter than 40 s...
Fun fact: I already got strange time values from pulse_measrt when having segments longer than 20 s. E.g.: Typical NBTI setup meas after 20 s accumulated stress returned 20 s and after 50 s accumulated stress (additional 30 s stress segment) returned 28,xxxx s.

Now I changed no PMU/RPM settings exept how I create my waveform with segment_arb commands.

dhabersa
Posts: 33
Joined: November 3rd, 2010, 12:17 pm
Country: United States

Re: "Psuedo real-time" data returning for PMU???

Post by dhabersa » January 16th, 2019, 8:15 am

I understand! Depending on your interest, you might find it useful to look closely at how waveforms can function (that is, the construction through segment_arb commands). You can quickly build up to very long segments. We're testing BTI up to 100's of hours!

In short, here's what I do:
1) Choose three time units, say "S"hort, "M"edium, and "L"ong. An individual sequence requires a minimum of 3 segments. And each segment can be from 20ns to 40s long. I usually just go for the extremes; "S" sequence ends up being 60ns total, "L" is 120s total, and "M" I'll put somewhere in between, usually at the geometric mean (~2.7ms).
2) Construct sequences for each length. These are just holding the bias constant at the desired stress condition. That's important, because now we can repeat these sequences in a waveform.
3) Construct a waveform that uses these sequences to apply BTI for the desired time. Use the count parameter in seg_arb_waveform.

Just use some modular arithmetic to get an arbitrary stress time. So to get, say, 150s of stress using the numbers I gave above, do 1 "L" sequence followed by 11,800 "M" sequences and 15,200 "S" ones. (1x120s + 11180x2.7ms + 15200x60ns should equal nearly 150s). I'm probably being unnecessarily precise when I do these, but I use a routines to look at many different time scales and just wanted to use one procedure that could handle the entire gamut of stress times (we usually go from 1us out to >10^5s).

Took me awhile to figure out the waveform aspect, but we can do some amazing waveforms now with extended stress and recovery measurements...

NWeddeler
Posts: 3
Joined: January 11th, 2019, 12:19 am
Country: Germany

Re: "Psuedo real-time" data returning for PMU???

Post by NWeddeler » January 24th, 2019, 4:15 am

Hi Dan,

thanks for sharing your experience! I created my fast-BTI setup using seg_arb_waveform which consists of several sequences created by seg_arb_sequence. These sequences consist of at least 3 segements.
  1. Start: 0V to meas to stress level
  2. Stresslevel (min stresstime/4 inorder to have 4 segments in this sequence)
  3. Stresslevel to meas to stress
  4. Stresslevel to meas to relax
  5. same stuff for relax....
And the stresssequence is only repeated n-times wereby n = (time I like to stress between two measurements)/(time of stresssequence).

What really bothers me is that pulse_measrt() worked properly at the time, were my waveform consisted of only one sequence which contained all segments I needed (until I realized that one segment can only have a length of 40 s...). The big drawback is, that without seeing updates of the measpoints, I don't know whether the needles still have contact to the wafer. Which is quite inconvenient for measurements which last around 9 hours...

Any feedback from Keithley regarding problems with pulse_measrt?

Btw. I saw that you already asked the question regarding LLEC with RPMs... If I got it right, the only thing you can do, is to set the approx. resistance of the DUT by pulse_load(), since LLEC is not performed in the seg_arb_mode? Which is recommended for BTI measurements although the resistance = VDS/ID changes during measurements over time for the same bias point? Which leads to additional error...

Regards

dhabersa
Posts: 33
Joined: November 3rd, 2010, 12:17 pm
Country: United States

Re: "Psuedo real-time" data returning for PMU???

Post by dhabersa » January 25th, 2019, 2:01 pm

Yikes... I can see why getting data back during the test would be important for you if you're probing. I'm lucky enough that most of our measurements are done on packaged devices.

I have never gotten even an acknowledgement from Keithley about this issue. Which was odd to me because on every other issue they've been very responsive to my forum posts. I've tried various versions of KITE up through to, uhhh, 9.2 I think? and it's been the same issue throughout. If it bothered me more, I'd probably try reaching out to their support engineers directly but it hasn't been a priority to me.

Re: LLEC, I never got a great solution. I'm usually operating my MOSFETs in the linear region, which at least gives a nice Ohmic response, at least as long as RDS is mostly constant. Less useful when you're trying to do something like sweep VGS or monitor threshold drift. These are power devices, so I can't even set the DUT resistance since they are well below 1ohm when fully on. Usually, in practice what I'll do is set my VDS relatively high, say ~0.5V and set the DUT resistance on the channel at 1Mohm. VDS collapses when the device turns on but at least I get enough current to measure!

Post Reply

Return to “4200-SCS Semiconductor Parameter Analyzer”

Who is online

Users browsing this forum: No registered users and 2 guests