Debugging to Find the Root Cause of Compliance, Limit or...

Debugging to Find the Root Cause of Compliance, Limit or Mask Test Violations

January 30, 2013 Dr. Alan Blankman Product Manager, Signal Integrity Teledyne LeCroy alan.blankman@teledynelecroy.com

Biggest Takeaway -

Make sure to unleash the full power of your oscilloscope’s analysis software when

searching for the root cause(s) of failures

Debugging Can’t be Avoided “Get it right the first time” “Learn from your mistakes” “Third time’s the charm”

(do your best to) Get it Right The First Time

Always the goal, but how often is this goal met? Not usually the case for cutting edge, state-of-the-art designs What does “Get it Right” mean, anyway?

Avoid going “back to the drawing board” Avoid costly and time-consuming re-spins Avoid making your boss look bad Manage the risk

Models, simulation, etc. only go so far toward meeting the goal However, sometimes the unimaginable failure occurs – and we need

to deal with it.

The Perilous Product Development Process

Flowchart from Rachel Phillips, et al, (1999) "A comparative study of six stage-gate approaches to product development", Integrated Manufacturing Systems, Vol. 10 Iss: 5, pp.289 - 297

The Perilous Product Development Process

Product Certification • Specification verification • In-house “pre-compliance” testing • Formal compliance testing

• EMI • Logo

Flowchart from Rachel Phillips, et al, (1999) "A comparative study of six stage-gate approaches to product development", Integrated Manufacturing Systems, Vol. 10 Iss: 5, pp.289 - 297

Unfortunately, the Certification Test shows a Failure

XYZ Corp USB 3.0

#*%@#*%(^#& !!

Mask Test Issue

OK. We have a failure. What now?

Step 1: (attempt to) Soothe the fears of your manager(s)

Step 2: Implement your debug plan Obviously you cannot plan for all circumstances Ensure that you will have access to the right equipment

Ensure that company-owned equipment is available to you Budget should be pre-approved if you need a rental

Understand the debug capabilities of your instruments “Design for Debug”

Test points, interposers, fixtures, S-parameter models, etc

Debugging issues with Jitter, Noise and Crosstalk

To find the root cause of failures/problems: You need to dig deeper than Eye diagrams, Tj, Rj, Dj, … These are aggregate results

Understand jitter/noise sources using “multi-domain analysis” Time domain Frequency domain Shape of jitter distribution Data dependent effects

Your oscilloscope has additional views of jitter in addition to Tj/Rj/Dj

Equipment Used for this Presentation

WaveMaster 830Zi Real-Time Oscilloscope 30 GHz (15.5ps 10-90 risetime) Up to 120 GS/s

SDAIII-CompleteLinQ Serial Data Analysis Software PSPL Pattern Pro Generator Example DUT

aka “demo board” with higher than desired crosstalk

Teledyne LeCroy’s SDAIII-CompleteLinQ

Simultaneous serial data analysis on up to four lanes Jitter & eye analysis – (tracks, spectra, histograms, pattern analysis…..)

Unique “Reference Lane” and LaneScape Comparison Mode Facilitates easy comparisons between lanes

Noise measurements Tn, Rn, Dn, Pn, ISIn, (noise tracks, spectra, histograms)

Crosstalk analysis The unique “Crosstalk Eye”

Equalization, de-embedding, emulation features Emphasis, CTLE, FFE, DFE

Single CompleteLinQ dialog that puts ties everything together.

But instead see this :

Today’s Scenario to Debug

Expect eye diagram to look like this:

Today’s Scenario to Debug

Inconsistent results from lane to lane:

Jitter results out of whack

Hypothesis: Crosstalk

The “lumped” shape is consistent with crosstalk

Images courtesy Eric Bogatin, Signal and Power Integrity Simplified

What is Crosstalk?

Caused by fringe fields that couple nets Near-end crosstalk: “NEXT” Far-end crosstalk: “FEXT”

The capacitive and inductive coupling between two nets that provides a path for unwanted noise from one net to the other.

NEXT

FEXT

1V incident signal

Near end Far end

Debugging Process

1.Configure scope, look at signals qualitatively 2.Perform aggressor on-off analysis:

A. Acquire with one lane transmitting “aggressor-off” scenario

B. Save this data and analysis to the “Reference lane” C. Acquire with both lane transmitting “aggressor-on” scenario

D. Analyze both acquisitions – side-by-side E. Interpret and compare results

Aggressors and Victims

Coupled lanes crosstalk onto each other: remember that both lanes are aggressors and victims

Aggressor signal

Victim signal

Blue trace is with “aggressor-on” Pink is with “aggressor-off”

Aggressors and Victims

Coupled lanes crosstalk onto each other: remember that both lanes are aggressors and victims

Aggressor signal

Victim signal (5x vertical zoom) Big waveform: agg on Noise: agg off

Let’s dig in and Analyze these Waveforms

SDAIII-CompleteLinQ Dialog

1: Acquire with One lane Transmitting

2: Store to Reference Lane

“Store Lane to Ref lane” stores lane data and configuration for ongoing comparisons

More than just a “memory trace” Acts as a “fifth analysis lane” Users can change its configuration

e.g.: Apply equalization, modify the clock recovery parameters (PLL)

The Reference Lane is the key to performing multi-scenario analysis

After Storing Lane 1 to the Reference Lane:

3: Acquire with both Lanes Transmitting

Add third lane

Now Let’s Dig Deeper

Switch to a single-lane view Enable a single “LaneScape”

Turn on additional analysis views of jitter and noise

See what we can learn about the amount of crosstalk Some avenues of investigation will not be too interesting

We’ll find that noise analysis provides more insight than jitter

when noise is present at the “Sampling Strobe Phase”

Jitter and Noise in the Time Domain

But first: Just what do we mean by Jitter and Noise?

Jitter: variation in the edge timing wrt expected arrival times Example: 10 Gbps signal has a unit interval (UI) that is ~100 ps wide Perfect signal has edges that arrive at exact multiples of 100ps

(good luck with that!)

Jitter is caused by a variety of sources: Transmitter imperfections Channel imperfections Laws of Physics

Jitter Basics: Time Interval Error is the Key Measurement

Early arrival Late arrival Late arrival

Expected arrival times (aka “clock”)

Late arrival

Crossing detection level

Jitter Measurement Basics

Difference between actual and expected arrival times = TIE TIE = Time Interval Error: the fundamental measurement of jitter

Ways to look at TIE:

vs. time: TIE Track With pattern-dependent effects removed: RjBUj Track

RjBUj = Random and Bounded-uncorrelated jitter (BUj includes Pj, OBUj) Distribution of TIE values TIE Hist, RjBUj Hist Frequency analysis RjBUj Spectrum

Analyze this for periodic jitter separation Data dependent jitter analysis DDj plot, ISI plot Last but not least: dual-Dirac analysis to get Tj, Rj, Dj

Noise Measurement Basics

Newcomer to the industry for real-time scopes, not as well known Noise: variation in the “1” and “0” levels due to interference

from external sources EMI Crosstalk

Our analysis, in a nutshell: Determine the “noiseless” version of the signal via pattern averaging Subtract actual signal from noiseless version, sample at

Pattern-dependent noise is subtracted out Random and Bounded-Uncorrelated noise remain: “RnBUn”

Separating the Noise from the Signal

Perform pattern analysis to determine the “noiseless” or “ideal” signal

Input signal:

Subtract: (input signal - “noiseless” version) = noise trace:

Determining “RnBUn Track”

Keep 1 point on noise wform for each unit interval, at the selected “Sampling Phase” This waveform is the noise seen by the receiver when it strobes the waveform

This is “RnBUnTrack”, and is the data used to determine Tn, Rn, Dn.

Jitter analysis in the Time Domain: (ie. TIE,RjBUj Tracks)

Noise Analysis – Time Domain

Jitter – Distribution of TIE Track, Rj BUj Track

Noise – Distribution of Noise Track (RnBUnTrack)

Jitter Spectrum (with data dependant jitter removed - RjBUjSpecr

Crosstalk Destroys your Spectral Rj Measurement

Tj, Rj, Dj determined by fitting to the dual-Dirac model Involves fitting tails of RjBUj histogram Industry “standard” method uses the Jitter Spectrum to determine the

sigma for the tail fit Crosstalk is broadband, and raises the spectral noise floor Be on the lookout for this problem! Teledyne LeCroy uses our NQ-Scale

method to avoid the spectral problem. For this example, Rj is off by factor 2

when using Spectral method

Impact of Using Crosstalk-Immune Jitter Method NQ-Scale

Moving on to the Noise Spectrum

Putting it all together: Aggressor On-Off Analysis

Lane-lane skew changes the picture -

Let’s Compare Lanes 1 and 2

Crosstalk Eye: Extrapolation of the Vertical Noise

Which Lane has the better…..

Jitter? Eye opening?

Review

Be prepared to do debugging when encountering problems in product certification

Know the capabilities of your oscilloscope for understanding the sources and degree of jitter and noise

Crosstalk will corrupt jitter measurements that use spectral techniques to establish Rj

Use both jitter and noise measurements in order to understand eye closure and

Consider Teledyne LeCroy’s solutions for multi-lane serial data analysis

Come visit us in the exhibit hall.

Thank you for attending!