Testability of high-speed SerDes
The article is written by a group from Prism Circuits in Santa Clara, and briefly describes the measures taken to be able to test a 10Gbps SerDes block, including both digital and analog observability, automatic pattern generation and checking, error injection, loop-back modes and IEEE 1149.6 boundary scan.
Pretty good overview of a typical approach to SerDes test in the industry, in my opinion. Have a look – anybody see anything missing from their approach?
Stumble It!
The DFT features described in the article improve the SerDes design’s diagnosability but they don’t facilitate significantly easier or cheaper production testing of the IC (which is what DFT is supposed to do). For example, to test the transmitter’s jitter or to observe its internal high-speed signals, a high-performance oscilloscope or ATE is still needed. So the capital cost of the ATE is not reduced, and the test time is not reduced (especially if the IC contains many other functions). The technique of using the receiver’s phase interpolator to adjust “the phase of the recovered clock” so that it samples at chosen points in the signal eye is a widely used technique: its primary short-comings are that the delay steps are uncalibrated, and coarse relative to RJ, and measurements don’t filter out jitter below the golden PLL cutoff frequency (which does not affect BER). The filter that they built into the transmitter to stress the transmitted eye is handy for system reuse, but since it is uncalibrated, it can’t be relied upon for IC test. Of course, this DFT approach can only be used when designing a SerDes from scratch, and not for a completed design.
LogicVision’s purely digital DFT technique that I have described in various ITC and journal papers for parametric BIST of any SerDes has inherently calibrated time steps, with resolution verified down to 100 fs on silicon (from 2.5 to >10 Gbps), and it reduces test time, but it requires the receiver to use a reference clock that is slightly frequency-offset relative to the transmitter’s reference clock in a loopback connection – so it is less convenient for reuse in-system compared to the DFT technique described in the Prism Circuits article. However, the two techniques together provide the best of both worlds. The LogicVision approach can calibrate all the DFT circuitry described in the article, using only a low-cost ATE (or a laptop PC), and test the SerDes, so that everything can be used with confidence at system level.
Hey Steve! You were exactly the person I was hoping would comment on this thread, because this is what I see a lot when looking at different serdes design proposals – the lion’s share of the ‘testability’ is in designing different loop-back modes that loop the data back in different places, combined with some sort of data generator/checker scheme.
The big sticking point for the ETSerdeDes approach, it seems to me, is having the ability to provide that frequency offset. Resistance to separating the reference.
Does LogicVision deal more with IP vendors or IP users in implementing this approach?
Cheers?
JMF
Hi John,
Having an offset-frequency reference clock (offset by around 150 ppm from its nominal value) is proving to be not much of a “sticking point”, even for SerDes transceivers that have a single clock, as long as the IC has multiple transceivers. For example, if an IC has two quad transceivers, then one quad is connected to one reference clock and the other quad is connected to the offset reference clock (just in test mode), and the serial data is looped-back between quads. Our RTL design and test automation handles this configuration automatically. Generating an offset clock, compliant with a typical SerDes clock input’s jitter requirements, is also automated by using an off-the-shelf clock conditioner IC (eg. LMK03000 from National Semiconductor) on the loadboard so that the ATE performance is irrelevant – our WGL/STIL generation tool creates patterns for the clock conditioner too. This approach is very easy to implement for IC testing, but less easy in-system.
Regarding your question, LogicVision deals mostly with SerDes IP users, but this usually requires us to discuss details with the IP vendors so that the user can be assured that we’re not testing the IP in some way it was not intended to be used. I often find that the IP vendors think there is no need for additional DFT beyond what they already have in their IP (plus high-speed ATE) but the users think differently, especially for 5 Gbps and higher – perhaps a bit of the proverbial brick wall between design and test.
…/steve