Test Modes: Why Do We Care?

As device complexity increases and development times shorten, there is a growing need to be able to test and characterize chips in their final packages.  At the same time, system integrators are faced with the need to vet and compare more products to be included in their designs.  Integrators find it imperative to homogenize test procedures, comparing ‘apples to apples’ when examining different products.

To accommodate these needs, many standards bodies have been incorporating mandatory ‘built-in’ test modes into their recent high speed serial interface specifications.  As always, the goal is to get as much utility as possible out of these test modes, while not increasing design complexity or cost.

When looking at built-in test modes across multiple unrelated serial interface technologies, we often find the same actors popping up in similar roles.  Over the next few weeks, we’ll discuss some of the overriding principles of these test modes, and what engineers can expect to see in upcoming serial standards. The most common test modes, and therefore, the test modes we will highlight, are loopbacks, pattern checkers and error counters, and pattern generators.

We’ll examine the nuances of each test mode, so that engineers are prepared, and understand the principles behind the test modes for when they are encountered in the lab.  We’ll start off by taking a look at loopbacks.

Loopbacks

In principle, loopbacks are straightforward; a device receives a signal on its receiver, and repeats it (loops it back out) on its transmitter.  This is a simple way to verify the integrity of a device’s receiver.  A problem arises if the device is repeating something out other than what it’s receiving.  Often, a loopback can be used with a Bit Error Rate Test (BERT) tool, which can both send a known signal or pattern (i.e. PRBS) into a device’s receiver, and compare that to the signal coming out the device’s transmitter, counting any discrepancies.  The BERT has a count of bits transmitted and errored bits, which is what the tool derives its name from.  The contents of those test patterns could be the subject of an entirely new blog post, but it’s worth mentioning that some standards bodies have put in the effort to make those test patterns adhere to the protocol being tested.  A PRBS pattern is just a stream of bits that doesn’t adhere to a protocol.  But SATA and Fibre Channel (FC) have defined test patterns in their specifications that actually look like ‘legal’ SATA or FC packets. The advantage here is that instead of checking every bit, only the packet CRC needs to be checked.

Even within the realm of loopback test modes, there are various features that can be implemented depending on the application.  Is the loopback a pure analog loopback, or is it re-timed? Is it protocol aware? How does it handle Spread Spectrum Clocking? Does the device exit the loopback test mode when nothing is being received? If not, what should be transmitted by the loopback if nothing is being received? (A chicken and egg paradox for you to think about). All of these are nuances to the loopback that need to be defined in the specification, and that the designer will need to pay attention to.

Next week, we’ll discuss pattern checkers and error counters and the nuances they present.

David Woolf, Research and Development