Simulating Serial Link Compliance

Author: Donald Telian, SI Guys - Guest Blogger

Simulating a serial link typically involves confirming compliance with one of the many Serial Link Standards. PCIe, SATA, XFI, CEI, SFP+, USB, KR4, and so on. With over a dozen common standards - each with their own compliance nuances - this feels like it could be a vast and complex topic. Indeed, it takes a full-day class to address only the most popular standards. While serial links is the clear winner in signaling methods, there is no clear winner in the realm of Serial Standards. Instead, we see a growing amount of application-specific specifications focused on various industry segments sourced by an array of standards organizations. But are there things all standards have in common at the electrical level? …and how is the SI simulation task similar, regardless of the standard? These are the questions I'll be addressing below.

In practice, I confirm "compliance" using the relevant Specification combined with a dash of experience. Over time I've developed a matrix of what works that juxtaposes data rate, length, and interconnect medium. This is helpful because Specifications are not perfect; some lacking important requirements while others have too many. This is the challenge of crafting a good standard: specify enough parameters to ensure performance and compatibility while not over-constraining the design space and hence product and market options. Sometimes unnecessary items creep in due to a compromise between competitors or a new feature in an oscilloscope. As such, confirming "compliance" is similar to all other Signal Integrity tasks: Engineering Judgment Required.

In the past six months I've done projects utilizing 15 different specifications covering a 30x variation in data rate. That's a lot of variation. And the challenge of the SI task does not track data rate because slower speeds that break the rules (e.g., too many connectors, too much length, etc.) introduce risk and complexity. Whatever the case, all projects want to know the answer to the same question: "Will it work?". And waiting until hardware is built is too late to find out.

Can Pre-Hardware Simulation Resolve Compliance?

If you've worked with a Serial Standard you have likely discovered "Compliance Testing" is primarily oriented towards physical hardware. It is important to understand this unstated assumption when you approach a Specification because hardware test uses tools and language that differ from simulation. With some standards you will wonder if it's even possible to confirm compliance using simulation but let me assure you it is. While it may not be feasible to use simulation for a few requirements in a specification, you will find the majority within reach.

Thankfully, the major SI simulations tools have helped automate the compliance task. Kits and Wizards guide you through the process, saving substantial time. Some tools gather up the relevant outputs and write the Compliance Report for you. Too good to be true? Perhaps. Learn to sift through the automation, leveraging whatever is helpful. Engineers must engineer; you wouldn't expect a Nascar driver to use a self-driving car, right?

Compliance Similarities

Despite the wide array of Standards, at the electrical/PHY level serial links are surprisingly similar. Data rates imply edge rates and equalization capabilities, and it is possible for a single SerDes to configure itself to support every standard. FPGAs do this every day. This fact alone suggests electrical compliance has similarities across the maze of specifications.

Every specification provides electrical parameters for the Tx (Transmitter), the Rx (Receiver), and the interconnect or "channel" between them. Unless you're working at an IC company, you will primarily be concerned with the channel - managing its loss and discontinuities. And, if at all possible, you'll engage in optimizing and configuring Tx and Rx equalization (Step 7). While some specifications offer decent guidance on the channel, I find many to be too brief - particularly since this is our primary concern. And so, again, it's important to leverage your experience and judgment.

100 Ohm interconnect is still the leader in channel differential impedance. While PCIe has dabbled with 85 Ohms, it has not found widespread acceptance. With most connectors centered on 100 Ohms, even many PCIe implementations choose to implement 100 Ohm interconnect. And with 8 mil drills becoming commonplace, via impedance has risen to 100 Ohms as well. Press-fit connector tails can be problematic, but improvements are happening there too.

Regarding equalization, actual devices do not implement what you find in a Specification and typically have much more than required. It may be the IC vendor borrowed a SerDes core from another interface, or they chose to differentiate their product by equalizing in ways their competitors do not. As such, view the equalization required by the specification as a minimum set. And if a specification, like SATA, is silent about equalization that doesn't mean it's not there; you will still find it in components.

Passive and Active Compliance, and COM

A good specification provides both passive and active metrics useful in the context of simulation. I believe both are important, so if I scour a specification and can't find one or the other I will borrow them from experience.

The most important passive metrics are masks for Insertion Loss (IL) and Return Loss (RL). Respectively, these bound the two problems found in every interconnect: Loss and Discontinuities (Steps 1 and 2). There's also Insertion Loss Deviation (ILD) that further bounds discontinuities. Masks overlay on your channel's S-parameters and indicate where and how your interconnect might be problematic. IL masks should have both a min and max, and RL masks should clearly state how they are meant to be tested. It's common to fail an RL mask if you fail to add the model for a compliance module assumed by the specification.

To illustrate the importance of examining both IL and RL masks, consider the five system characteristics (delineated by five colors) in Figure 1. Insertion Loss masks (black, at left) bound a min/max range in which the gold system does the best at finding the center, while the two shades of blue ride on the edges of the mask. Looking at Return Loss (right), both blues and even red sit right on the mask (black). How can that be when their IL characteristics are so different? This happened because in the physical system all three begin with a miss-matched (reflective) connector that dominates RL. This type of issue can easily be seen using TDR plots. RL could be improved by either using a different connector or adding some loss in front of it. For RL, the gold system again shows the best overall margin to the mask.

Figure 1: InsertionLoss (left) and Return Loss (right) for Five Systems, with Masks

Passive masks help calibrate and tune your interconnect, yet do not necessarily guarantee active performance. Significant effort has been put into developing a passive test that can do this, yet it remains the "holy grail" of serial link simulation methodology. It's important to understand the systems in Figure 1 that fail the masks may not fail in practice. While the blue systems are at the edge of mask ranges the only clear conclusion is that their loss is at the edges of the design space comprehended by the writers of the specification; and specifications cannot comprehend everything that might and can work in practice. Nevertheless, these reference points are helpful. If I was asked to work with the dark blue system's (low loss) IL I would work to minimize discontinuities because this system is less damped. And if my system had the light blue (high loss) IL I would think about swapping materials or put more thought into how the channel is equalized. I would not immediately discount even the red channel's IL because, as stated previously, the equalization capabilities in actual components typically far surpass a specification's expectations. An AMI model or even a good datasheet would show me to what extent that's true.

Passive metrics provide reference points you can use to tune your interconnect while active simulation provides better insight into link performance. Common active compliance metrics are eye masks and BERs. Eye openings are simulated using AMI models, and observed in physical devices by accessing internal IC eye capture features. Acceptable eye openings have shrunk from 100s to 10s of millivolts. Eye opening masks assume a waveform probability and BERs are a probability, and those numbers are changing too. For active testing, many standards specify an "Rx Tolerance Test" that sends a "stressed" signal to the Rx to test its ability to recover a noisy, minimal signal. Though these tests presume test equipment and physical hardware, they can typically be implemented using simulation.

COM is not short for "Compliance" or "Complicated" but is an acronym for "Channel Operating Margin". COM straddles the fence between passive and active compliance, looking like a passive metric while adding in an array of active parameters and assumptions. Based on a complex set of mathematics, COM strives to answer the "will it work?" question with a single number: 3 dB. If that sounds too good to be true, understand that much of COM's acceptance lies in the fact it dared to offer a figure of merit at a time when very few would. Today it has become a common compliance reference point, even though that was not its original intention.

Compliance and Modularity

At times your design ends at an industry standard connector; either you're designing a system another device plugs into, or you're designing a device or add-in card that plugs into a system. Now the SI task must resolve only half of a serial link. This is what "Standards" excel at, and I find they do a good job of bounding what is expected on both sides of the connector. Some specifications even offer SI models for the side of the link you do not control. Particularly for RL tests, it is important to add in the spec's interconnect assumption or model for what is on the other side of a connector. For active analysis, a conservative approach is to use your simulator's AMI template and build a "spec model" for the unknown part of the system. Set the model's parameters at the minimum Tx/Rx behaviors required by the specification - items such as impedance, rise/fall times, and equalization. If your analysis shows good performance with this type of model, confidence of success with open-market devices is high.

Examples of Corrections for Compliance

Simulating link compliance always reveals something to fix or improve. Work with your layout team to resolve the right trade-offs between performance and complexity. Perhaps some examples will be helpful? Here are some things resolved on recent projects:

• Interconnect does not have enough loss. Use Df/Lt of 0.01 instead of 0.003.
• Lengths are too long. Use other route layers to get to the connector in 7" max
• Via stubs are too long. Need to back-drill under components.
• Connector is too reflective. Enforce minimum length from IC to connector of 2.5".
• Tx is over-equalized. Turn off Tx EQ.
• Connector impedance too low. Lower route impedance on both sides from 100 to 90 Ohms.
• RL margin better than IL margin. Constrain max route lengths.
• Press-fit tails create stubs. Route on lower layers.
• Interconnect satisfies both passive and active metrics as is. Re-drivers are not needed.

Each of these changes showed improvement in simulation, and some corrected physical system failures.

In Conclusion

Resolving link compliance for the wide array of Serial Standards seems daunting yet doesn't have to be. At the Tx-Channel-Rx electrical level, all serial links are similar. It's important to leverage available tools and experience to confirm both passive and active link performance. Leverage Specifications to the best of your and their ability, expecting to apply engineering judgment along the way. Simulating serial links for compliance pre-hardware solves a myriad of issues, shortening schedules for product manufacturing and hardware test.