Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
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 [email protected]
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!