SN65LVDM050-Q1: tPLH, TPHL, tsk(p) TI production measurements

Hi Tim,

Can you share you test setup? Are you following figure 5 test setup and figure 2 measurement method?

Hi Malik,

I'll have to confirm exact test conditions later, but it is in my understanding we're testing to Figure 7 (SGLS128A - Timing test circuit and waveforms).

There's some pre-provided warning the testing equipment may induce a larger load capacitance than specified on the datasheet, so we're lenient towards small discrepancies in measurements.

However, regardless of exact test conditions, would like to know generically if tsk(p) limits should be within 0.1 ns, or we're chasing a non-issue. In my experience, typical values can be fairly unreliable sometimes, which is generally fine as a reference point.

Thanks,

Tim

Hi Tim, 

I believe this is a non-issue, tsk(p) limits are not limited to be 0.1ns within each other. 

Hi Malik,

I appreciate the feedback.

Although, I would agree we don't suspect it will be a major issue, I'd still like to confirm empirically with TI's internal results that this is expected behavior.

A 2-3ns pulse skew seems like it could definitely become a problem at higher bit rates, so would like to confirm if we should be accounting for this offset in the future.

Thanks,

Tim

Hi Tim,

I agree the tPHL numbers you have are higher than I would expect. I would like to see your setup to see if there is anything going on here. 

Hi Malik,

Attaching a snippet. Not much to look at.

Device is put into a socket, and the I/O's are mapped to channels for the tester.

The vendor provides the caveat the tester environment adds an unintended ~50pF of stray capacitance, which would serve as the CL, but would think any skew/offset that would cause from the CL=10pF test condition would be represented in both tPHL & tPLH measurements.

Thanks,

Tim

Hi Tim,

I agree here I would expect that any effect from increased CL in both measurements. Do you see these numbers across multiple parts? An waveform you can share? Can you try adding a weak pull down or get CL lower on Y/Z pins to see if tpHL measurement is effected? 

These measurements are just outputted by an automatic tester, so no waveforms. We have a larger planned sample size, but presently only characterizing 3 samples to develop test limits. Unfortunately, unable to experiment with the test setup. Especially given the rest of the device seems fine, and don't want to get too burdened chasing a typical parameter.

Why my preference is just getting indication from TI if our results are within family, or it's not, and we can just notate our results are skewed. For our purposes of evaluating pre/post life measurements; I think that's OK.

I do think it's interesting the tPHL measurement is around the 3.7ns typical limit set on the TI datasheet, so the device being much faster on the tPLH side being the issue is perplexing.

This is the raw data for SNs R001-R003:

Hi Tim,

Could you elaborate on the differences between each row? Are these just instances of teh same test? R0001-0003 are the three devices you mentioned correct? 

Sure. Each row represents one measurement in the test sequencing. I don't have it delineated by which receiver, and how many times each one was tested, but generally for the purposes of this conversation can just assume it's either/or.

R0001, R0002, & R0003 columns are the SNs of each device.

I see, I think what you are seeing here is expected for the receiver and the other half of the data is for the driver.

. 

Hi Malik,

Unfortunately, I don't believe that is the case. In-application, we're only using the receiver portion, which is why my focus on on resolving the perceived discrepancy. However, the driver portion is being measured and notated separately also (pasted below).

I do think that may be some assurance the test setup is fairly reasonable. I'm seeing averages of tPLH=1.32ns, tPHL=1.21ns resulting in a 0.11ns net average skew, which all seems reasonably within datasheet limits.

Really, the only "problem" seems to be is tPLH on the receiver being much faster than typical. I've requested some additional information on the timing measurement to see if possibly trigger conditions or whatever are incorrect.

Hi Tim,

Understood, I would also like to know how these measurements are done in the program. Any waveforms to help explain would be helpful.